Message-ID: <alpine.DEB.1.10.0808180524110.12859@asgard.lang.hm>
Date:	Mon, 18 Aug 2008 05:34:29 -0700 (PDT)
From:	david@...g.hm
To:	tvrtko.ursulin@...hos.com
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Adrian Bunk <bunk@...nel.org>, capibara@...all.nl,
	Casey Schaufler <casey@...aufler-ca.com>, davecb@....com,
	Eric Paris <eparis@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-security-module@...r.kernel.org,
	malware-list@...ts.printk.net,
	malware-list-bounces@...sg.printk.net,
	Mihai Don??u <mdontu@...defender.com>,
	Peter Dolding <oiaohm@...il.com>, Pavel Machek <pavel@...e.cz>,
	Rik van Riel <riel@...hat.com>, rmeijer@...all.nl,
	Theodore Tso <tytso@....edu>
Subject: Re: [malware-list] scanner interface proposal was: [TALPA] Intro to
 a linux interface for on access scanning (fwd)

On Mon, 18 Aug 2008, tvrtko.ursulin@...hos.com wrote:

> david@...g.hm wrote on 18/08/2008 12:44:12:
>
>> On Mon, 18 Aug 2008, tvrtko.ursulin@...hos.com wrote:
>>
>>> David Lang wrote on 18/08/2008 02:25:44:
>>>
>>>> what is not covered by this design that is covered by the threat
> model
>>> being
>>>> proposed?
>>>>
>>>> what did I over complicate in this design? or is it the minimum
> feature
>>> set
>>>> needed?
>>>>
>>>> are any of the features I list impossible to implement?
>>>
>>> One more thing - this proposal does not work where there are no
> extended
>>> attributes (whether at all or they are disabled at mount time). I
> think
>>> that is a serious flaw or at least disadvantage compared to the posted
>>> implementation.
>>
>> good point. I should have listed that.
>>
>> I don't see it as a serious flaw, people who care about this feature can
>
>> just pick an appropriate filesystem to use.
>
> You mostly cannot pick not use vfat, isofs and udf.

two options come to mind

1. unionfs with a ramdisk

2. add xattr simulation code to the filesystem

but in any case, most of your system is not going to be on those 
filesystems. I'm far more worried about optimizing away the need to scan 
the bash binary every time it's invoked by the system then I am having to 
scan files on a CD each time they are opened.

>> but if extended attributes are not found a strict implementation could
>> fall back to scanning on every file access (the extended attributes are
>> being used to cache the results of the scans)
>
> Performance impact may or may not be acceptable

well, some people are arguing that the scans are fast enough that nothing 
other then on-access scanning should be done. you can't both be right ;-)

> but I dislike the concept of core security interface which is not really 
> core.

people differ significantly on how 'core' this is. this goes back to the 
threat model and how much you are trying to defend against. if you are 
trying to defend against root or already running malware, then you are 
absolutly right, this is nowhere close to being bulletproof agaist those 
types of threats, but neither were the other proposals listed. with the 
threat model that was outlined those threats are being dealt with 
seperatly (by people useing SELinux or other LSM)

I'm seeing this as more a solid file scanner support interface of which 
security is just one of the users.

David Lang

P.S. thanks for looking over the proposal, it's nice to actually deal with 
issues with it instead of with what people think it may have been :-)
--
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