scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[david]

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

Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[tvrtko.ursulin]

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.

Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[david]

On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com 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

Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[tvrtko.ursulin]

david@lang.hm wrote on 18/08/2008 12:44:12:

> On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com 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.

Re: [malware-list] scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[david]

On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com wrote:

> david@lang.hm wrote on 18/08/2008 12:44:12:
>
>> On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com 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 :-)

Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[Enrico Weigelt]

* david@lang.hm <david@lang.hm> 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/
---------------------------------------------------------------------

Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[Alan Cox]

> 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

Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[Enrico Weigelt]

* Alan Cox <alan@lxorguk.ukuu.org.uk> 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/
---------------------------------------------------------------------

Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[david]

On Mon, 1 Dec 2008, Enrico Weigelt wrote:

> * Alan Cox <alan@lxorguk.ukuu.org.uk> 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
>

Re: scanner interface proposal was: [TALPA] Intro to a linux interface for on access scanning (fwd)

[Alan Cox]

On Mon, 1 Dec 2008 01:51:42 +0100
Enrico Weigelt <weigelt@metux.de> wrote:

> * Alan Cox <alan@lxorguk.ukuu.org.uk> 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.