Message-ID: <48A8C58C.7030208@schaufler-ca.com>
Date:	Sun, 17 Aug 2008 17:42:52 -0700
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	david@...g.hm
CC:	Pavel Machek <pavel@...e.cz>, Eric Paris <eparis@...hat.com>,
	Theodore Tso <tytso@....edu>, Rik van Riel <riel@...hat.com>,
	davecb@....com, linux-security-module@...r.kernel.org,
	Adrian Bunk <bunk@...nel.org>,
	Mihai Don??u <mdontu@...defender.com>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon
 access scanning

david@...g.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

Sorry, I must have missed it. My bad.

> 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.
>

One xattr, multiple xattrs, all would work. It's simpler to clear the
"scanned" attribute on open than on dirty, a your scheme means looking
at writes, seeks, ioctls, fcntls, and so on.
 
>> P.S. - Library based security doesn't work.
>
> why not? (with the appropriate kernel support)

If you have kernel support it aint library based.

> 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.

I'm old school. I say that all policy decisions regarding objects that
the kernel maintains belong in the kernel. That's why I say that any time
a file is closed with scanned unset (or unscanned set) the scanner should
be invoked or notified. The scanner can choose to ignore or queue the
notification, but the kernel will be done at that point. The kernel have
done all that it can and it's up to the scanner from then on.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists