[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0808142149030.12859@asgard.lang.hm>
Date: Thu, 14 Aug 2008 22:05:15 -0700 (PDT)
From: david@...g.hm
To: Arjan van de Ven <arjan@...radead.org>
cc: Theodore Tso <tytso@....edu>,
Christoph Hellwig <hch@...radead.org>,
Eric Paris <eparis@...hat.com>, tvrtko.ursulin@...hos.com,
alan@...rguk.ukuu.org.uk, andi@...stfloor.org,
linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
malware-list-bounces@...sg.printk.net, peterz@...radead.org,
viro@...IV.linux.org.uk
Subject: Re: [malware-list] TALPA - a threat model? well sorta.
On Thu, 14 Aug 2008, Arjan van de Ven wrote:
> On Thu, 14 Aug 2008 22:04:00 -0400
> Theodore Tso <tytso@....edu> wrote:
>
>> On Thu, Aug 14, 2008 at 06:44:33PM -0700, david@...g.hm wrote:
>>> could you do something like defining a namespace inside posix
>>> attributes and then setting up a mechanism in the kernel to alert
>>> if the attributes change (with the entire namespace getting cleared
>>> if the file gets dirtied)?
>>
>> According to Eric Paris the clean/dirty state is only stored in
>> memory. We could use the extended attribute interface as a way of not
>> defining a new system call, or some other interface, but I'm not sure
>> it's such a great match given that the extended attributes interface
>> are designed for persistent data.
>>
>> I agree that doesn't actually work very well for the tracker use case,
>> where you the clean/dirty bit to be persistent (in case the tracker is
>> disabled due to the fact you are running on battery, for example, and
>> then you reboot).
>>
>
> but we need a "give me all dirty files" solution, not a "is this file
> dirty" solution.
>
> I do not want a virus scanner to constantly have to poll the whole fs
> for dirty files ;-)
I'm not sure.
there are two situations (with the transition between them)
1. unscanned system, we want to do everything. (this happens immediatly
after a new signature file is deployed)
here you do just want to filter out the files that have been scanned from
the list of everything, and you probably want to check at the time of
scanning the file in case it was opened (and scanned) in the meantime.
2. mostly scanned system, we only want to scan files that have been
dirtied.
here you don't need to scan everything, you only need to scan in two cases
2a. the file was dirtied (you learn about it and add it to the queue of
files to scan when you get around to it)
2b. an unscanned file is opened (the library detects that the file was not
marked approved by all the current scanners, so it invokes the scanners on
this file before completing the open, or copy for mmap, or whatever)
In the first case the attributes work "don't bother scanning me".
In the second case they also work (becouse you aren't trying to scan
everything)
the only time there is a headache is in the transition between them when
you have scanned a lot of the system, but not all of it, and the machine
was rebooted so you lost track of what you had scanned.
it shouldn't be too hard to deal with this. even if you never resume the
scan you are still safe (becouse of the scan-on-open), but it's also
possible to either do a find f(or equivalent) or files without the
attribute and store the results (similar to updatedb) and then updating
the file to mark the files as being scanned (update in place, change the
first character or something to be fairly crash safe). after the full list
of files has been scanned shift to the second mode.
the sweep scan should be a background task, possibly disabled when on
battery power.
why would this not satisfy the requirements?
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