trying to resend again due to tripping L-K anti-spam filtering
since many people apparently missed this writeup I'm re-sending it.
please try to seperate disagreement with the threat model this is addressing
with disagreement with the design.
comments since I sent this out on friday seem to fall in three catagories
1. people didn't read it
this is why I'm re-sending this
2. disagreement with the idea that the on-access part can be triggered in
userspace
this is a valid debate to have, but it's tied to #3
3. (and the biggest batch) statements that this won't protect against problem X
(where X was not in the threat model)
arguing againt this design is the wrong thing to do. argue against the threat
model instead, preferrably by proposing a different threat model and allowing
for a debate of which is appropriate.
the threat model that was sent out (by others, not by me) basicly boils down to
"don't allow programs to access/execute 'unscanned' data. don't try to defend
against actions of programs already running or malicious user actions" there
were further comments listing things it's not trying to cover.
David Lang
On Fri, 15 Aug 2008, Arjan van de Ven wrote:
> The implementation idea (have a flag/generationnr in the inode for
> 'known good', block on read() and mmap(), and schedule async scans in
> open or on dirty) seems to be quite solid although several details
> (async queueing model for example but also the general dirty
> notification system) need to be worked out.
I really think that we need to avoid trying to have a single 'known good'
flag/generationnrwith the inode.
while that will work for the TALPA use-case of a single anti-virus scanner, it
can't cope with multiple scanners, and since there are very different types of
scanners that are interesting (anti-virus and indexing to just name two), and
the fact that some people will want to run more then one anti-virus program on
a machine, you don't have a 'known good' condition, you have 'known good
according to program A/B/C' conditions, and the file should only be considered
'good, nothing to do' if it has a full set of flags.
and these flags really should live on disk. many types of scans really are
still relavent across reboots, and even where you can make arguments that "the
user may have booted into another OS and infected the file" the counter
argument "you don't want to waste battery power scanning something every time
you boot when you don't use another OS" can be applied.
if you store generation numbers for individual apps (in posix attributes to
pick something that could be available across a variety of filesystems), you
push this policy decision into userspace (where it belongs). users who are
paranoid can have the AV software incrament it's generation number on every
boot so that all of the prior tags are considered worthless, while users who
are more worried about battery power can completely disable background scanning
while on battery, and trust to the fact that most of the files are already
flagged as safe to minimize the amount of new scanning that needs to be done.
(and don't tell me about how frequently the signatures are updated, if someone
is on a 12 hour flight without Internet access they are not going to be having
new virii hitting them, let alone downloading new signature files)
so I propose the following approach (mentioned at least in pieces over the last
couple of days, but consolodated and cleaned up a bit)
1. define a tag namespace associated with the file that is reserved for this
purpose for example "scanned-by-*"
2. have an kernel option that will clear out this namespace whenever a file is
dirtied
3. have a kernel mechanism to say "set this namespace tag if this other
namespace tag is set" (this allows a scanner to set a 'scanning' tag when it
starts and only set the 'blessed' tag if the file was not dirtied while it was
being scanned. without this there is a race condition that could cause a file
to be marked as good incorrectly, the initial threat model ruled out worrying
about race conditions, but this seems like a fairly easy one to close
4. have a mechanism (netlink?) where multiple programs can connect to receive
near-real-time notification that a file changed state from partially/fully
scanned to dirty. (don't try to report what has changed, just that it is
changed status to dirty). This report should contain the filesystem, inode,
path, and namespace information needed to access and identify the file
5. define a "must pass" 'policy file' path that the various scanner programs
can set the "scanned-by-*" flags on that the 'libmalware' library will look at
to see what needs to be set for a file to be considered 'good', along with a
path for a program that should be called if the flag is not set. (this path
could be a directory with one symlink per scanner, the name of the file being
the flag name)
6. create a library that replaces open/read/etc with versions that imlement a
pam-style stack of hooks that scanning programs can be configured to use. like
pam these programs can return "I say this is bad", "no comment/looks good", or
"I say this is safe". config files can then set the order of these scanns and
Scanning software can use the hooks above to implement every behavior that I've
seen mentioned in this thread.
A. filesystem indexing programs can subscribe to the notification mechanism and
set a "scanned-by'*" flag as they touch files, but not register themselves as
something that needs to be checked when a file is opened.
B. tripwire type programs can set flags as they scan the system, subscribe to
the notification mechanism, register with the "must pass" list, and when
invoked give a quick "I know this is safe", or "this wasn't supposed to change,
something is wrong" response if the file is something it knows about, or "no
comment otherwise
C. anti-virus scanners can subscribe to the notification mechanism, register
with the "must pass" list, and when invoked do their checks and report "I found
something bad, deny access" or "no comment/looks good" depending on what they
find.
D. anti-virus scanners could choose to ignore the notification mechansim,
register with the "must pass" list, and only scan files that are being
accessed, never do any background scanning (appropriate for software who's
signature files change very frequently where you don't want to try and scan
everything between updates)
E. most people will have a default allow module loaded at the end of the "must
check" chain, but _really_ paranoid people could instead have a module that
determines if the file was expected to exist, and if not deny access to it
F. becouse the checking is a userpace library, distros can choose any balace
between 'every binary does the checks' to 'only the Samba binaries do checks',
and could add an option to open/read/etc to allow a program to say "I don't
need you to scan the file" (for example, why would "wc" need it's input
scanned?). this also provides a solid mechanism to avoid recursive calls to the
scanning programs, they just choose not to do the scanning checks.
G. becouse the scanners are userspace, they can get configured to run as the
user who called them (nessasary if they are to scan files only available to
that user) or they can be configured to run as root (suid or other mechanism)
H. becouse the scanners are userspace, all decisions of how to schedule the
bckground scanning are up to the software and administrator.
I. becouse there are hooks at each of the commands (open/read/etc) the
userspace can choose what to do at each step (it may schedule a async scan for
'right now' on open, and then block on read until the file is scanned)
J. becouse the "scanned-by-*" namespace is deliberatly not defined scanners can
set flags as needed for intermedate status (register "scanned-by-macafee1234"
on the "must pass" list, but set a "scanned-by-macafee1234-in-progress" flag to
avoid multiple scanners from working over the same file (as well as avoiding
the race of the file being modified as it's being scanned)
K. becouse the scanner and checks are in userspace and initally are called in
the context of the user running the program trying to do the access, it's
possible for them to do things like 'do you want to' pop-ups, progress bars,
etc
L. the fact that knfsd would not use this can be worked around by running FUSE
(which would do the checks) and then exporting the result via knfsdw
M. becouse the checks are in userspace, it's easy to create 'whitelist'
scanners (either by name "never bother scanning /var/lob/messages, no matter
how many times it gets marked dirty" or by SELinux tags "never bother to scan
anything unless it has the SELinux tag that says it came from a untrusted
source)
N. becouse the checker/scanners start in the context of the program trying to
do the access it's possible to access the fd being accessed, even if the file
no longer exists on the filesystem (closing the hole of opening a file that
wasn't scanned, unlinking it, then reading the resulting file). This is outside
of the threat model that was proposed, but still possible to do with this model
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?
David Lang
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.
--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos
"Views and opinions expressed in this email are strictly those of the
author.
The contents has not been reviewed or approved by Sophos."
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
On Mon, 18 Aug 2008, [email protected] 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.
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)
David Lang
[email protected] wrote on 18/08/2008 12:44:12:
> On Mon, 18 Aug 2008, [email protected] 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.
> 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 but I dislike the concept
of core security interface which is not really core.
--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos
"Views and opinions expressed in this email are strictly those of the
author.
The contents has not been reviewed or approved by Sophos."
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
On Mon, 18 Aug 2008, [email protected] wrote:
> [email protected] wrote on 18/08/2008 12:44:12:
>
>> On Mon, 18 Aug 2008, [email protected] 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 :-)
* [email protected] <[email protected]> wrote:
<big_snip />
Hi folks,
I've just battled through the tons of text in this thread and
really wonder why this is a kernel issue at all.
You want to keep track if certain files are changed ?
Any you want to block/delay access to unchecked or
considered-malicous files ?
Fine. Why not just putting this into a userland filesystem ?
Coding an 9P server is quite trivial. So why messing up the
kernel with stuff clearly belonging into userland ? ;-o
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
> Fine. Why not just putting this into a userland filesystem ?
1. Performance
2. Networked file systems
3. Ioctls
and probably a few others in the thread too.
Alan
* Alan Cox <[email protected]> wrote:
> > Fine. Why not just putting this into a userland filesystem ?
>
> 1. Performance
Does it really hurt so bad, compared with all actual AV stuff ?
It has to go to userland anyway, in case you don't intend to
put the scanner into the kernel ;-o
> 2. Networked file systems
What's the problem ?
(btw: 9P already *IS* an network filesystem ;-P)
> 3. Ioctls
Ah, just forgot a while that this crap still exists ;-o
BUT: do the affected dirs have to contain devices ?
Is there any point for pulling /dev through the AV scanner ?
cu
--
---------------------------------------------------------------------
Enrico Weigelt == metux IT service - http://www.metux.de/
---------------------------------------------------------------------
Please visit the OpenSource QM Taskforce:
http://wiki.metux.de/public/OpenSource_QM_Taskforce
Patches / Fixes for a lot dozens of packages in dozens of versions:
http://patches.metux.de/
---------------------------------------------------------------------
On Mon, 1 Dec 2008, Enrico Weigelt wrote:
> * Alan Cox <[email protected]> wrote:
>>> Fine. Why not just putting this into a userland filesystem ?
>>
>> 1. Performance
>
> Does it really hurt so bad, compared with all actual AV stuff ?
> It has to go to userland anyway, in case you don't intend to
> put the scanner into the kernel ;-o
if you have to scan every file then you are right, the userland overhead
would be swamped by the scanner overhead. but much of the time you will be
accessing files that are already scanned or that you aren't going to scan,
but you would still be paying the userland penalty for the filesystem.
David Lang
>> 2. Networked file systems
>
> What's the problem ?
> (btw: 9P already *IS* an network filesystem ;-P)
>
>> 3. Ioctls
>
> Ah, just forgot a while that this crap still exists ;-o
>
> BUT: do the affected dirs have to contain devices ?
> Is there any point for pulling /dev through the AV scanner ?
>
>
> cu
>
On Mon, 1 Dec 2008 01:51:42 +0100
Enrico Weigelt <[email protected]> wrote:
> * Alan Cox <[email protected]> wrote:
> > > Fine. Why not just putting this into a userland filesystem ?
> >
> > 1. Performance
>
> Does it really hurt so bad, compared with all actual AV stuff ?
> It has to go to userland anyway, in case you don't intend to
> put the scanner into the kernel ;-o
That depends on the scanning and what you are using it for - at least
part of the interest is in asynchronous indexing systems in which case
the answer appears to be no, the scanner doesn't trash your performance.
>
> > 2. Networked file systems
>
> What's the problem ?
> (btw: 9P already *IS* an network filesystem ;-P)
Try 9P with an NFS backing store. Try a cluster file system.
> > 3. Ioctls
>
> Ah, just forgot a while that this crap still exists ;-o
>
> BUT: do the affected dirs have to contain devices ?
> Is there any point for pulling /dev through the AV scanner ?
Lots of ioctls apply to files. Please think about what is involved rather
than just assuming.