lkml.org 
[lkml]   [2008]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectscanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)
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


\
 
 \ /
  Last update: 2008-08-18 03:29    [W:0.077 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site