Cc: <david@...>, Eric Paris <eparis@...>, Theodore Tso <tytso@...>, Rik van Riel <riel@...>, <davecb@...>, <linux-security-module@...>, Adrian Bunk <bunk@...>, Mihai Don??u <mdontu@...>, <linux-kernel@...>, <malware-list@...>, Arjan van de Ven <arjan@...>
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.
P.S. - Library based security doesn't work.
--
