Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon access scanning

[david@lang.hm]

On Mon, 18 Aug 2008, Peter Dolding wrote:

> On Mon, Aug 18, 2008 at 10:17 AM,  <david@lang.hm> wrote:
>> On Sun, 17 Aug 2008, Casey Schaufler wrote:
>>
>>> Pavel Machek wrote:
>>>>>>>
>>>>>>> And I still don't get this 'mmap problem' that I don't solve that
>>>>>>> libmalware magically solves.  What?  don't use mmap?  I certainly hope
>>>>>>> not.
>>>>>>>
>>>>>> Don't use mmap, it is as simple as that. AFAICS mmap(MAP_SHARED) --
>>>>>> which is basically shared memory -- is fundamentally incompatible with
>>>>>> reliable virus scanning.
>>>>>>
>>>>>> ...or do you have a reasonable solution for mmap?
>>>>>>
>>>>> mmap has a few different problems
>>>>>
>>>>> 1. intercepting reads and writes to take action at that time
>>>>>
>>>>> 2. the fact that two programs can use it as an inter-process
>>>>> communication mechanism.
>>>>>
>>>>
>>>> ...can and will use it as an IPC. So we need to modify some
>>>> applications.
>>>>
>>>> Rather than modify all the applications using mmap (you can't tell if
>>>> the other side is going to use it for shared memory... right?), we
>>>> could simply modify all the Windows-facing applications using mmap.
>>>>
>>>>
>>>>> if you are worried about the IPC aspects, all you can do is forbid it,
>>>>
>>>> Can you automatically tell if applications are using mmap for IPC?
>>>>
>>>> BTW in another mail you wanted to include /var/log/syslog from
>>>> scanning. You should not be doing that if syslog is exported to
>>>> Windows systems. Of course, you can get away with scanning syslog when
>>>> Windows client tries to read it, which should be acceptable...
>>>>
>>>>  Pavel
>>>>
>>>
>>> There is a solution to this whole scanning thing, but I've been
>>> reluctant to suggest it, and it will be pretty obvious why y'all
>>> probably don't want to try it. Just to be sure the options are
>>> out on the table, here goes.
>>>
>>> Define an xattr, let's call it "UNSCANNED", which has as its value
>>> a timestamp. A regular file with this attribute cannot be executed
>>> or opened,(exec or open hangs or fails, either behavior has merit
>>> and downsides) and it requires privilege (perhaps CAP_MAC_ADMIN)
>>> to remove the attribute. File creation attaches the attribute. Any
>>> open for write attaches the attribute.
>>>
>>> Your scanner runs with privilege (say CAP_MAC_OVERRIDE) and passes
>>> judgment on files with this attribute, removing either the file, if
>>> it is Evil, or the attribute, if it is Good. The scanner is invoked
>>> when a file that was open with write access is closed. This can be
>>> done using mechanisms already discussed on this thread.
>>>
>>> If you like, you could use a "SCANNED" attribute instead of an
>>> "UNSCANNED" attribute, and reverse the sense of the test. The
>>> major difference will show up on filesystems that don't support
>>> xattrs. The implications should be obvious.
>>>
>>> Now at the beginning I said that you wouldn't like this scheme,
>>> and it shouldn't take a security expert to see the usability problems.
>>> This is how an old school trusted systems junkie (like me) would do
>>> it, and I don't see a better way that would actually achieve the
>>> stated goals. If you wanted you could implement an LSM to do the
>>> labeling bit in a day or two, the notification in about the same
>>> time, which would leave the scanner as the long pole in your
>>> development schedule.
>>
>> did you read the proposal I wrote up? it's similar to (but more flexible
>> than) what you are saying
>>
>> it would allow for multiple 'scanned' tags (to allow for multiple scanning
>> programs). the kernel would clear the tags when the file is dirtied (not
>> when it is closed, the file may not be closed for weeks after all), there is
>> a mechanism to tell the scanner(s) that a file was modified (rather then
>> having to scan the entire filesystem), and if the scan was not done yet when
>> a file is opened the scanner(s) can be invoked at that time.
>>
>>> P.S. - Library based security doesn't work.
>>
>> why not? (with the appropriate kernel support)
>>
>> it actually wouldn't be hard to have the kernel check the xattr, what would
>> be hard is hving the kernel know when it should then invoke the scanner(s)
>> and when it shouldn't. This is a policy decision that doesn't belong in the
>> kernel.
>>
> Because of syscalls  and you don't need to use LD.so to run a program.
>
> Programs can embed there own LD.so and avoid using the system core
> one.   This kind of function is being developed for LSB applications
> for platforms that don't support LSB.
>
> syscalls you can run programs by passing all .so files and directly
> talk to kernel.
>
> Two aways around LD Preloads there are a few more.

you seem to be disagreeing with the threat model. If so, rather then 
arguing agains this implementation of a defense, you need to be arguing 
against the threat model.

you are arguing that this solution doesn't work in some conditions. you 
are correct, but the threat model that was proposed (and nobody has 
proposed any different ones) is not trying to defend against code running 
on the system, even if that code is trying to bypass the protection. I 
even think that this is a good thing. it allows the distros to use the 
protection where appropriate and disable it where it's not (which is a 
surprisingly large number of places).

David Lang