Message-ID: <alpine.DEB.1.10.0808171708230.12859@asgard.lang.hm>
Date:	Sun, 17 Aug 2008 17:17:49 -0700 (PDT)
From:	david@...g.hm
To:	Casey Schaufler <casey@...aufler-ca.com>
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

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.

David Lang
--
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