[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080813205906.559d3f37@lxorguk.ukuu.org.uk>
Date: Wed, 13 Aug 2008 20:59:06 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: Eric Paris <eparis@...hat.com>
Cc: linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
andi@...stfloor.org, riel@...hat.com, greg@...ah.com,
tytso@....edu, viro@...IV.linux.org.uk, arjan@...radead.org,
peterz@...radead.org, hch@...radead.org
Subject: Re: TALPA - a threat model? well sorta.
> > I don't think you need to be blocking if you passed up a file handle ?
>
> Without blocking and waiting how do you deny access? Maybe I needed
> another thing they do. "They do file scanning and deny access to bad
> files."
Denying access is easy enough - chmod it or set an SELinux label on it.
There are a limited number of useful arrangements I can see here
'opened for write deny [some set of] access until verified'
Thats an selinux state transition on open for write, and one from the
user space end on the other
'run around after things'
Which is simply a notifier and a relabel as 'contaminated' or similar (or
a chmod or mv ...) by the daemon end of things.
Now I can see why you might want a 'has been open for a write and dirty
for a while' notifier - again for indexing as well as virus scanners and
the like.
What other semantic do you have in mind given that you have to deal with
open by me, open by writer, content modified.. after I have it open
anyway ? It seems the rest is a discussion about time intervals ?
--
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