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

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

[David Collier-Brown]

tvrtko.ursulin wrote:
>>Huh? I was never advocating re-scan after each modification and I even 
>>explicitly said it does not make sense for AV not only for performance but 
>>because it will be useless most of the time. I thought sending out 
>>modified notification on close makes sense because it is a natural point, 
>>unless someone is trying to subvert which is out of scope. Other have 
>>suggested time delay and lumping up.

Alan Cox wrote: 
> You need a bit more than close I imagine, otherwise I can simply keep the
> file open forever. There are lots of cases where that would be natural
> behaviour - eg if I was to attack some kind of web forum and insert a
> windows worm into the forum which was database backed the file would
> probably never be closed. That seems to be one of the more common attack
> vectors nowdays.

  I suspect we're saying "on close" when what's really meant is
"opened for write". In the latter case, the notification would tell
the user-space program to watch for changes, possibly by something as
simple as doing a stat now and another when it gets around to 
deciding if it should scan the file. I see lots of room for
user-space alternatives for change detection, depending on how much
state it keeps. Rsync-like, perhaps?

--dave
-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb@sun.com                 |                      -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#

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

[Theodore Tso]

On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com wrote:
> Then there is still a question of who allows some binary to declare itself 
> exempt. If that decision was a mistake, or it gets compromised security 
> will be off. A very powerful mechanism which must not be easily 
> accessible.  With a good cache your worries go away even without a scheme 
> like this.

I have one word for you --- bittorrent.  If you are downloading a very
large torrent (say approximately a gigabyte), and it contains many
pdf's that are say a few megabytes a piece, and things are coming in
tribbles, having either a indexing scanner or an AV scanner wake up
and rescan the file from scratch each time a tiny piece of the pdf
comes in is going to eat your machine alive....

						- Ted

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

[tvrtko.ursulin]

Theodore Tso <tytso@mit.edu> wrote on 18/08/2008 15:25:11:

> On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com 
wrote:
> > Then there is still a question of who allows some binary to declare 
itself 
> > exempt. If that decision was a mistake, or it gets compromised 
security 
> > will be off. A very powerful mechanism which must not be easily 
> > accessible.  With a good cache your worries go away even without a 
scheme 
> > like this.
> 
> I have one word for you --- bittorrent.  If you are downloading a very
> large torrent (say approximately a gigabyte), and it contains many
> pdf's that are say a few megabytes a piece, and things are coming in
> tribbles, having either a indexing scanner or an AV scanner wake up
> and rescan the file from scratch each time a tiny piece of the pdf
> comes in is going to eat your machine alive....

Huh? I was never advocating re-scan after each modification and I even 
explicitly said it does not make sense for AV not only for performance but 
because it will be useless most of the time. I thought sending out 
modified notification on close makes sense because it is a natural point, 
unless someone is trying to subvert which is out of scope. Other have 
suggested time delay and lumping up.

Also, just to double-check, you don't think AV scanning would read the 
whole file on every write?

--
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

[Alan Cox]

> Huh? I was never advocating re-scan after each modification and I even 
> explicitly said it does not make sense for AV not only for performance but 
> because it will be useless most of the time. I thought sending out 
> modified notification on close makes sense because it is a natural point, 
> unless someone is trying to subvert which is out of scope. Other have 
> suggested time delay and lumping up.

You need a bit more than close I imagine, otherwise I can simply keep the
file open forever. There are lots of cases where that would be natural
behaviour - eg if I was to attack some kind of web forum and insert a
windows worm into the forum which was database backed the file would
probably never be closed. That seems to be one of the more common attack
vectors nowdays.

> 
> Also, just to double-check, you don't think AV scanning would read the 
> whole file on every write?

So you need the system to accumulate some kind of complete in memory set
of 'dirty' range lists on all I/O ? That is going to have pretty bad
performance impacts and serialization.

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

[tvrtko.ursulin]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote on 18/08/2008 16:31:48:

> > Huh? I was never advocating re-scan after each modification and I even 

> > explicitly said it does not make sense for AV not only for performance 
but 
> > because it will be useless most of the time. I thought sending out 
> > modified notification on close makes sense because it is a natural 
point, 
> > unless someone is trying to subvert which is out of scope. Other have 
> > suggested time delay and lumping up.
> 
> You need a bit more than close I imagine, otherwise I can simply keep 
the
> file open forever. There are lots of cases where that would be natural
> behaviour - eg if I was to attack some kind of web forum and insert a
> windows worm into the forum which was database backed the file would
> probably never be closed. That seems to be one of the more common attack
> vectors nowdays.

Yes, I agree that modification notifications are needed in some cases.
 
> > Also, just to double-check, you don't think AV scanning would read the 

> > whole file on every write?
> 
> So you need the system to accumulate some kind of complete in memory set
> of 'dirty' range lists on all I/O ? That is going to have pretty bad
> performance impacts and serialization.

No, I was just saying scanning is pretty smart, it's not some brute force 
method of scan all data that is there. It has a file type detection and 
what and how to scan is determined by that. If a file does not resemble 
any file type I don't think it gets scanned. For example take couple of 
gigabytes of zeros and try to scan that with some products. I don't think 
they will try to read the whole file.

--
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

[Alan Cox]

> On async notification we fire a message to everything that registered
> 'simultaneously.' On blocking we fire a message to everything in
> priority order and block until we get a response.  That response should
> be of the form ALLOW/DENY and should include "mark result"/"don't mark
> result."

No can do - you get stuck with recursive events with the virus checker
trying to stop the indexer from indexing a worm.

> read -> we have the ALLOW/mark result bit in core set so just allow.

Don't think we need this - SELinux can do that bit

> mtime update -> clear ALLOW/"mark result" bit in core, send async
> notification to userspace

Why via the kernel ?

> The communication with userspace has a very specific need.  The scanning
> process needs to get 'something' that will give it access to the
> original file/inode/data being worked on.  My previous patch set does

file handle. Really you need to give the handle of the object because it
may not have a name or a meaningful inode number

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

[Eric Paris]

On Mon, 2008-08-18 at 16:31 +0100, tvrtko.ursulin@sophos.com wrote:
> Theodore Tso <tytso@mit.edu> wrote on 18/08/2008 15:25:11:
> 
> > On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com 
> wrote:
> > > Then there is still a question of who allows some binary to declare 
> itself 
> > > exempt. If that decision was a mistake, or it gets compromised 
> security 
> > > will be off. A very powerful mechanism which must not be easily 
> > > accessible.  With a good cache your worries go away even without a 
> scheme 
> > > like this.
> > 
> > I have one word for you --- bittorrent.  If you are downloading a very
> > large torrent (say approximately a gigabyte), and it contains many
> > pdf's that are say a few megabytes a piece, and things are coming in
> > tribbles, having either a indexing scanner or an AV scanner wake up
> > and rescan the file from scratch each time a tiny piece of the pdf
> > comes in is going to eat your machine alive....
> 
> Huh? I was never advocating re-scan after each modification and I even 
> explicitly said it does not make sense for AV not only for performance but 
> because it will be useless most of the time. I thought sending out 
> modified notification on close makes sense because it is a natural point, 
> unless someone is trying to subvert which is out of scope. Other have 
> suggested time delay and lumping up.
> 
> Also, just to double-check, you don't think AV scanning would read the 
> whole file on every write?

Make this a userspace problem.  Send a notification on every mtime
update and let userspace do the coallessing, ignoring, delaying, and
perf boosting pre-emptive scans.  If someone designs a crappy
indexer/scanner that can't handle the notifications just blame them, it
should be up to userspace to use this stuff wisely.

Current plans are for read/mmmap to be blocking and require a response.
Close and mtime update and going to be fire and forget async change
notifications.  I'm seriously considering a runtime tunable to allow the
selection of open blocking vs async fire and forget, since I assume most
programs handle open failure much better than read failure.  For the
purposes of an access control systems (AV) open blocking may make the
most sense.  For the purposes of an HSM read blocking makes the most
sense.

Best thing about this is that I have code that already addresses almost
all of this.  If someone else wants to contribute some code I'd be glad
to see it.

But lets talk about a real design and what people want to see.

Userspace program needs to 'register' with a priority.  HSMs would want
a low priority on the blocking calls AV Scanners would want a higher
priority and indexers would want a very high priority.

On async notification we fire a message to everything that registered
'simultaneously.' On blocking we fire a message to everything in
priority order and block until we get a response.  That response should
be of the form ALLOW/DENY and should include "mark result"/"don't mark
result."

If everything responds with ALLOW/"mark result" we will flip a bit IN
CORE so operations on that inode are free from then on.  If any program
responds with DENY/"mark result" we will flip the negative bit IN CORE
so deny operations on the inode are free from then on.

Userspace 'scanners' if intelligent should have set a timespace in a
particular xattr of their choosing to do their own userspace results
caching to speed up things if the inode is evicted from core.  This
means that the 'normal' flow of operations for an inode will look like:

open -> async to userspace -> userspace scans and writes timestamp

read -> blocking to userspace -> userspace checks xattr timestamp and
mtime and responds with ALLOW/"mark result"

read -> we have the ALLOW/mark result bit in core set so just allow.

mtime update -> clear ALLOW/"mark result" bit in core, send async
notification to userspace

close -> send async notification to userspace

If some general xattr namespace is agreed upon for such a thing someday
a patch may be acceptable to clear that namespace on mtime update, but I
don't plan to do that at this time since comparing the timestamp in the
xattr vs mtime should be good enough.

******************************

Great, how to build this interface.  THIS IS WHAT I ACTUALLY CARE ABOUT

The communication with userspace has a very specific need.  The scanning
process needs to get 'something' that will give it access to the
original file/inode/data being worked on.  My previous patch set does
this with a special securityfs file.  Scanners would block on 'read.'
This block was waiting for something to be scanned and when available a
dentry_open() was called in the context of the scanner for the inode in
question.  This means that the fd in the scanner had to be the same data
as the fd in the original process.

If people want me to use something like netlink to send async
notifications to the scanner how do I also get the file/inode/data to
the scanning process?  Can anyone think of a better/cleaner method to
get a file descriptor into the context of the scanner other than having
the scanner block/poll on a special file inside the securityfs?

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

[douglas.leeder]

malware-list-bounces@dmesg.printk.net wrote on 2008-08-18 15:25:11:

> On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com 
wrote:
> > Then there is still a question of who allows some binary to declare 
itself 
> > exempt. If that decision was a mistake, or it gets compromised 
security 
> > will be off. A very powerful mechanism which must not be easily 
> > accessible.  With a good cache your worries go away even without a 
scheme 
> > like this.
> 
> I have one word for you --- bittorrent.  If you are downloading a very
> large torrent (say approximately a gigabyte), and it contains many
> pdf's that are say a few megabytes a piece, and things are coming in
> tribbles, having either a indexing scanner or an AV scanner wake up
> and rescan the file from scratch each time a tiny piece of the pdf
> comes in is going to eat your machine alive....

What size is a tribble? :-)

If we assume that the bittorrent client is closing and re-openning the 
file 
each time it's got a nice piece of the file? (Otherwise I don't think
we'll have a performance problem)

Then there maybe room for a optimisation of the following form:
For a file X.
If X is only a local disk.
If X was written from empty by process A and only process A.
Then don't scan attempts to open by process A.

But that sort of optimisation can either be done in user-space, or in a 
future 
kernel modification.

I haven't fully analysed this - it assumes that reading data into process 
A, that
process A wrote out is safe, regardless of the data. 

-- 
Douglas Leeder

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

[Alan Cox]

> When you register at Level N, you are excluded from all blocking/scanning 
> at Levels >= N,
> but your ops are still passed to Level < N.

Something like that would do the trick for any simple dependencies yes.

Alan

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

[douglas.leeder]

malware-list-bounces@dmesg.printk.net wrote on 2008-08-18 17:15:00:

> > On async notification we fire a message to everything that registered
> > 'simultaneously.' On blocking we fire a message to everything in
> > priority order and block until we get a response.  That response 
should
> > be of the form ALLOW/DENY and should include "mark result"/"don't mark
> > result."
> 
> No can do - you get stuck with recursive events with the virus checker
> trying to stop the indexer from indexing a worm.

And the opposite approach can't work because the AV scanner + the index 
scanner 
need the HSM to do its work before they can scan.

I guess the only way it could work is to have levels:
e.g.
HSM agent is Level 1
AV scanner is Level 2
Index scanner is Level 3

When you register at Level N, you are excluded from all blocking/scanning 
at Levels >= N,
but your ops are still passed to Level < N.

An example is a little hard to craft because HSM and indexing catch 
different operations. :-)
 
-- 
Douglas Leeder

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

[david]

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

> Theodore Tso <tytso@mit.edu> wrote on 18/08/2008 15:25:11:
>
>> On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com
> wrote:
>>> Then there is still a question of who allows some binary to declare
> itself
>>> exempt. If that decision was a mistake, or it gets compromised
> security
>>> will be off. A very powerful mechanism which must not be easily
>>> accessible.  With a good cache your worries go away even without a
> scheme
>>> like this.
>>
>> I have one word for you --- bittorrent.  If you are downloading a very
>> large torrent (say approximately a gigabyte), and it contains many
>> pdf's that are say a few megabytes a piece, and things are coming in
>> tribbles, having either a indexing scanner or an AV scanner wake up
>> and rescan the file from scratch each time a tiny piece of the pdf
>> comes in is going to eat your machine alive....
>
> Huh? I was never advocating re-scan after each modification and I even
> explicitly said it does not make sense for AV not only for performance but
> because it will be useless most of the time. I thought sending out
> modified notification on close makes sense because it is a natural point,
> unless someone is trying to subvert which is out of scope. Other have
> suggested time delay and lumping up.
>
> Also, just to double-check, you don't think AV scanning would read the
> whole file on every write?

if it doesn't read the entire file and only reads the parts that change, 
out-of-order writes (which bittorrent does a _lot_ of) can assemble a 
virus from pieces and the scanner will never see it.

as for Ted's issue, the scanner(s) would get notified when the file was 
dirtied, they would then get notified if something scanned the file and it 
was marked dirty again after that. If nothing got around to scanning the 
file then all the following writes would not send any notification becouse 
the file would already be dirty.

David Lang

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

[david]

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

> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote on 18/08/2008 16:31:48:
>
>>> Huh? I was never advocating re-scan after each modification and I even
>
>>> explicitly said it does not make sense for AV not only for performance
> but
>>> because it will be useless most of the time. I thought sending out
>>> modified notification on close makes sense because it is a natural
> point,
>>> unless someone is trying to subvert which is out of scope. Other have
>>> suggested time delay and lumping up.
>>
>> You need a bit more than close I imagine, otherwise I can simply keep
> the
>> file open forever. There are lots of cases where that would be natural
>> behaviour - eg if I was to attack some kind of web forum and insert a
>> windows worm into the forum which was database backed the file would
>> probably never be closed. That seems to be one of the more common attack
>> vectors nowdays.
>
> Yes, I agree that modification notifications are needed in some cases.
>
>>> Also, just to double-check, you don't think AV scanning would read the
>
>>> whole file on every write?
>>
>> So you need the system to accumulate some kind of complete in memory set
>> of 'dirty' range lists on all I/O ? That is going to have pretty bad
>> performance impacts and serialization.
>
> No, I was just saying scanning is pretty smart, it's not some brute force
> method of scan all data that is there. It has a file type detection and
> what and how to scan is determined by that. If a file does not resemble
> any file type I don't think it gets scanned. For example take couple of
> gigabytes of zeros and try to scan that with some products. I don't think
> they will try to read the whole file.

trying to include details of where each file was updated means that you 
can't just set a single 'dirty' flag for the file (or clear the 'scanned' 
flags), you instead need to detect and notify on every write.

this is a HUGE additional load on the notification mechansim and the 
software that recieves the notifications.

just sending "fix X was scanned and now isn't" is going to be bad enough, 
you _really_ don't want to do this for every write.

David Lang

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

[Alan Cox]

> I think I'm going to stick with my special file in securityfs since it
> makes it some simple to install the fd in the scanning process (as
> opposed to netlink where I don't even know how it would be possible...)

AF_UNIX passes file handles just fine. I'm not sure netlink will help you
here anyway - isn't it lossy under load ?

Also securityfs is more special purpose magic here - what does it have to
do with a general purpose notifier API ? I'd actually generalise the
notifier properly and go for a syscall.

Alan

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

[Eric Paris]

On Mon, 2008-08-18 at 17:15 +0100, Alan Cox wrote:
> > On async notification we fire a message to everything that registered
> > 'simultaneously.' On blocking we fire a message to everything in
> > priority order and block until we get a response.  That response should
> > be of the form ALLOW/DENY and should include "mark result"/"don't mark
> > result."
> 
> No can do - you get stuck with recursive events with the virus checker
> trying to stop the indexer from indexing a worm.

My last interface was single leveled and was able to efficiently stop
recursion by simply excluding all processes which were scanners.  It was
implemented as a flag in the task_struct.  I could probably go the same
route and just exclude all kernel initiated scanners from all scanning
operations.  I also included an interface for a process to be completely
excluded, but given multi-level scanners I don't think an 'exclude all'
is appropriate.

I could add a separate interface for background/purely userspace
scanners to register their level and only call scanners from the kernel
with a lower level.  Not sure what security I'd want to put around this
interface.

> 
> > read -> we have the ALLOW/mark result bit in core set so just allow.
> 
> Don't think we need this - SELinux can do that bit
> 
> > mtime update -> clear ALLOW/"mark result" bit in core, send async
> > notification to userspace
> 
> Why via the kernel ?

the single in core allow/deny bit is so that the vast majority of
operations are completely free.  Say we scan/index /lib/ld-linux.so.2
once.  Do you really want every single read/mmap operation from then on
to have to block waiting for the userspace caches of you HSM, your AV
scanner, and you indexer?  If all three tell the kernel they don't need
to see it again and that information is easy and free to maintain, lets
do it.

> > The communication with userspace has a very specific need.  The scanning
> > process needs to get 'something' that will give it access to the
> > original file/inode/data being worked on.  My previous patch set does
> 
> file handle. Really you need to give the handle of the object because it
> may not have a name or a meaningful inode number

I think I'm going to stick with my special file in securityfs since it
makes it some simple to install the fd in the scanning process (as
opposed to netlink where I don't even know how it would be possible...)

-Eric

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

[david]

On Mon, 18 Aug 2008, Eric Paris wrote:

> But lets talk about a real design and what people want to see.
>
> Userspace program needs to 'register' with a priority.  HSMs would want
> a low priority on the blocking calls AV Scanners would want a higher
> priority and indexers would want a very high priority.

why do you need to introduce a priority mechanism for notifying scanners? 
just notify them all and let them take action at their own rate for async 
notifications. if you are waiting for their result you need to invoke them 
directly, but whether you do it in order or in parallel will depend on the 
config. this is an optmization problem that the kernel should not be 
trying to figure out becouse the right answer is policy dependant (if they 
all need to bless the file for it to be accepted then fire them off in 
parallel (system resources allowing), if one accepting it is good enough 
you may want to just run that one and see if you get lucky rather then 
eating up resources of all the others)

> On async notification we fire a message to everything that registered
> 'simultaneously.' On blocking we fire a message to everything in
> priority order and block until we get a response.  That response should
> be of the form ALLOW/DENY and should include "mark result"/"don't mark
> result."

why in the world would you block for an _async_ notification mechanism?

> If everything responds with ALLOW/"mark result" we will flip a bit IN
> CORE so operations on that inode are free from then on.  If any program
> responds with DENY/"mark result" we will flip the negative bit IN CORE
> so deny operations on the inode are free from then on.

this requires syncronous scanning by all scanners.

> Userspace 'scanners' if intelligent should have set a timespace in a
> particular xattr of their choosing to do their own userspace results
> caching to speed up things if the inode is evicted from core.  This
> means that the 'normal' flow of operations for an inode will look like:
>
> open -> async to userspace -> userspace scans and writes timestamp
>
> read -> blocking to userspace -> userspace checks xattr timestamp and
> mtime and responds with ALLOW/"mark result"

you can't trust timestamps, they go forwareds and backwords. they need to 
have some sort of 'generation id' but don't try to define meaning for it, 
leave that to the scanner. have everything else treat it as a simple "it 
matches" or "it doesn't match"

> read -> we have the ALLOW/mark result bit in core set so just allow.
>
> mtime update -> clear ALLOW/"mark result" bit in core, send async
> notification to userspace

you keep planning to do this with a single allow mark. it may not be that 
simple.

> close -> send async notification to userspace

as several others have noted, alerting on close is not good enough, we 
need to alert on the scanned->dirty transition (by the way, this 
contridicts the part of your message I snipped where you were advocating 
notification on every write)

> If some general xattr namespace is agreed upon for such a thing someday
> a patch may be acceptable to clear that namespace on mtime update, but I
> don't plan to do that at this time since comparing the timestamp in the
> xattr vs mtime should be good enough.

if you are already accessing xattrs, why not just use the value rather 
then trying to make it into a time?


> ******************************
>
> Great, how to build this interface.  THIS IS WHAT I ACTUALLY CARE ABOUT
>
> The communication with userspace has a very specific need.  The scanning
> process needs to get 'something' that will give it access to the
> original file/inode/data being worked on.  My previous patch set does
> this with a special securityfs file.  Scanners would block on 'read.'
> This block was waiting for something to be scanned and when available a
> dentry_open() was called in the context of the scanner for the inode in
> question.  This means that the fd in the scanner had to be the same data
> as the fd in the original process.

having scanners access a file blocking on read won't work for multiple 
scanners (unless you are going to create multiple files for them to read)

> If people want me to use something like netlink to send async
> notifications to the scanner how do I also get the file/inode/data to
> the scanning process?  Can anyone think of a better/cleaner method to
> get a file descriptor into the context of the scanner other than having
> the scanner block/poll on a special file inside the securityfs?

this is easy, the userspace library (libmalware or glibc) intercepts the 
open and is invoking the scanners if the checks tell it to. they can send 
the file descripter over a unix socket on the machine to a scanner daemon, 
or they can invoke the scanner in the existing user context.

David Lang

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

[david]

On Mon, 18 Aug 2008, Eric Paris wrote:

> On Mon, 2008-08-18 at 17:15 +0100, Alan Cox wrote:
>>> read -> we have the ALLOW/mark result bit in core set so just allow.
>>
>> Don't think we need this - SELinux can do that bit
>>
>>> mtime update -> clear ALLOW/"mark result" bit in core, send async
>>> notification to userspace
>>
>> Why via the kernel ?
>
> the single in core allow/deny bit is so that the vast majority of
> operations are completely free.  Say we scan/index /lib/ld-linux.so.2
> once.  Do you really want every single read/mmap operation from then on
> to have to block waiting for the userspace caches of you HSM, your AV
> scanner, and you indexer?  If all three tell the kernel they don't need
> to see it again and that information is easy and free to maintain, lets
> do it.

this is why the proposal caches the results of all the scanners with the 
file (in the xattrs), rather then having each scanner store it's own scan 
results

David Lang

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

[Eric Paris]

On Mon, 2008-08-18 at 10:29 -0700, david@lang.hm wrote:
> On Mon, 18 Aug 2008, Eric Paris wrote:
> 
> > But lets talk about a real design and what people want to see.
> >
> > Userspace program needs to 'register' with a priority.  HSMs would want
> > a low priority on the blocking calls AV Scanners would want a higher
> > priority and indexers would want a very high priority.
> 
> why do you need to introduce a priority mechanism for notifying scanners? 
> just notify them all and let them take action at their own rate for async 
> notifications. if you are waiting for their result you need to invoke them 
> directly, but whether you do it in order or in parallel will depend on the 
> config. this is an optmization problem that the kernel should not be 
> trying to figure out becouse the right answer is policy dependant (if they 
> all need to bless the file for it to be accepted then fire them off in 
> parallel (system resources allowing), if one accepting it is good enough 
> you may want to just run that one and see if you get lucky rather then 
> eating up resources of all the others)

You have some pretty serious reading comprehension problems with my
message.  Try reading it all over again keeping in mind (although not
stated it was I thought understood) that the priority was only of value
during blocking calls.

> > On async notification we fire a message to everything that registered
> > 'simultaneously.' On blocking we fire a message to everything in
> > priority order and block until we get a response.  That response should
> > be of the form ALLOW/DENY and should include "mark result"/"don't mark
> > result."
> 
> why in the world would you block for an _async_ notification mechanism?

try reading it again.

> 
> > If everything responds with ALLOW/"mark result" we will flip a bit IN
> > CORE so operations on that inode are free from then on.  If any program
> > responds with DENY/"mark result" we will flip the negative bit IN CORE
> > so deny operations on the inode are free from then on.
> 
> this requires syncronous scanning by all scanners.

yup.

> > Userspace 'scanners' if intelligent should have set a timespace in a
> > particular xattr of their choosing to do their own userspace results
> > caching to speed up things if the inode is evicted from core.  This
> > means that the 'normal' flow of operations for an inode will look like:
> >
> > open -> async to userspace -> userspace scans and writes timestamp
> >
> > read -> blocking to userspace -> userspace checks xattr timestamp and
> > mtime and responds with ALLOW/"mark result"
> 
> you can't trust timestamps, they go forwareds and backwords. they need to 
> have some sort of 'generation id' but don't try to define meaning for it, 
> leave that to the scanner. have everything else treat it as a simple "it 
> matches" or "it doesn't match"

Not my problem.  Userspace needs to make their own determination and
cache their own results from async scans.  Kernel fires and forgets on
async.  Its up to userspace to make those notifications useful if they
can help with the blocking read (open?) calls.

> > read -> we have the ALLOW/mark result bit in core set so just allow.
> >
> > mtime update -> clear ALLOW/"mark result" bit in core, send async
> > notification to userspace
> 
> you keep planning to do this with a single allow mark. it may not be that 
> simple.
> 
> > close -> send async notification to userspace
> 
> as several others have noted, alerting on close is not good enough, we 
> need to alert on the scanned->dirty transition (by the way, this 
> contridicts the part of your message I snipped where you were advocating 
> notification on every write)

Is it really that hard to understand what I'm saying?  We notified on
mtime update and cleared the "mark result".  Why shouldn't we notify on
close?

> > If some general xattr namespace is agreed upon for such a thing someday
> > a patch may be acceptable to clear that namespace on mtime update, but I
> > don't plan to do that at this time since comparing the timestamp in the
> > xattr vs mtime should be good enough.
> 
> if you are already accessing xattrs, why not just use the value rather 
> then trying to make it into a time?

I'm not accessing anything.  I'm leaving xattrs as an exercise of
efficiency for people who want to write a userspace scanner.  Not my
problem.

> > ******************************
> >
> > Great, how to build this interface.  THIS IS WHAT I ACTUALLY CARE ABOUT
> >
> > The communication with userspace has a very specific need.  The scanning
> > process needs to get 'something' that will give it access to the
> > original file/inode/data being worked on.  My previous patch set does
> > this with a special securityfs file.  Scanners would block on 'read.'
> > This block was waiting for something to be scanned and when available a
> > dentry_open() was called in the context of the scanner for the inode in
> > question.  This means that the fd in the scanner had to be the same data
> > as the fd in the original process.
> 
> having scanners access a file blocking on read won't work for multiple 
> scanners (unless you are going to create multiple files for them to read)

WHAT?

> > If people want me to use something like netlink to send async
> > notifications to the scanner how do I also get the file/inode/data to
> > the scanning process?  Can anyone think of a better/cleaner method to
> > get a file descriptor into the context of the scanner other than having
> > the scanner block/poll on a special file inside the securityfs?
> 
> this is easy, the userspace library (libmalware or glibc) intercepts the 
> open and is invoking the scanners if the checks tell it to. they can send 
> the file descripter over a unix socket on the machine to a scanner daemon, 
> or they can invoke the scanner in the existing user context.

But, I have code for my solution that addresses just about every problem
mentioned on list so far except for multi priority blockers.  Where is
your code?

-Eric

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

[Alan Cox]

>   I suspect we're saying "on close" when what's really meant is
> "opened for write". In the latter case, the notification would tell
> the user-space program to watch for changes, possibly by something as
> simple as doing a stat now and another when it gets around to 

Or more precisely perhaps "on the file becoming dirty". A program that
opens for write, computes for an hour and writes out doesn't want to load
events down until it begins writing.

I agree "on close" is inaccurate for the scanner cases and that is why
we've been talking about events + a close time event.

> deciding if it should scan the file. I see lots of room for
> user-space alternatives for change detection, depending on how much
> state it keeps. Rsync-like, perhaps?

Agreed.

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

[Eric Paris]

On Mon, 2008-08-18 at 18:25 +0100, Alan Cox wrote:
> > I think I'm going to stick with my special file in securityfs since it
> > makes it some simple to install the fd in the scanning process (as
> > opposed to netlink where I don't even know how it would be possible...)
> 
> AF_UNIX passes file handles just fine. I'm not sure netlink will help you
> here anyway - isn't it lossy under load ?

But the file being installed needs to be at least RD for AV/Indexer.
Particularly of interest to people here would be a file opened O_WRONLY
and then the indexer wouldn't have the ability to read the data that was
just written.  So we need a new FD, can't just send the old one.

I'd also assume that an HSM would need a WR file descriptor, which isn't
easy.  I've found that (through trial and error not understanding the
code) trying to make new descriptors for the new process have WR often
returned with ETXTBUSY....

I think I might just give RO file descriptors and if an HSM comes along
work with them to get WR fd's working....

> Also securityfs is more special purpose magic here - what does it have to
> do with a general purpose notifier API ? I'd actually generalise the
> notifier properly and go for a syscall.

Well, securityfs is really just a location for a bunch of interfaces.
The real 'magic' is that I defined my own read and write functions on a
special inode.

Lets assume a new syscall (and I know you tried to describe this too me
before but I can't remember it and I'm having some e-mail history
trouble) what would it look like?  A scanner constantly calls scan() to
block for data to be scanned?  So an AV, HSM, or indexer all would be
blocking in scan() just waiting for data?  How do they respond?  How is
it better, cleaner, or more general than a 'special' file they
read/write?

-Eric

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

[david]

On Mon, 18 Aug 2008, Eric Paris wrote:

> On Mon, 2008-08-18 at 10:29 -0700, david@lang.hm wrote:
>> On Mon, 18 Aug 2008, Eric Paris wrote:
>>
>>> ******************************
>>>
>>> Great, how to build this interface.  THIS IS WHAT I ACTUALLY CARE ABOUT
>>>
>>> The communication with userspace has a very specific need.  The scanning
>>> process needs to get 'something' that will give it access to the
>>> original file/inode/data being worked on.  My previous patch set does
>>> this with a special securityfs file.  Scanners would block on 'read.'
>>> This block was waiting for something to be scanned and when available a
>>> dentry_open() was called in the context of the scanner for the inode in
>>> question.  This means that the fd in the scanner had to be the same data
>>> as the fd in the original process.
>>
>> having scanners access a file blocking on read won't work for multiple
>> scanners (unless you are going to create multiple files for them to read)
>
> WHAT?

if you have multiple things reading from a pipe only one will get any one 
message, right?

David Lang

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

[david]

On Mon, 18 Aug 2008, David Collier-Brown wrote:

> tvrtko.ursulin wrote:
>>> Huh? I was never advocating re-scan after each modification and I even 
>>> explicitly said it does not make sense for AV not only for performance but 
>>> because it will be useless most of the time. I thought sending out 
>>> modified notification on close makes sense because it is a natural point, 
>>> unless someone is trying to subvert which is out of scope. Other have 
>>> suggested time delay and lumping up.
>
> Alan Cox wrote: 
>> You need a bit more than close I imagine, otherwise I can simply keep the
>> file open forever. There are lots of cases where that would be natural
>> behaviour - eg if I was to attack some kind of web forum and insert a
>> windows worm into the forum which was database backed the file would
>> probably never be closed. That seems to be one of the more common attack
>> vectors nowdays.
>
> I suspect we're saying "on close" when what's really meant is
> "opened for write". In the latter case, the notification would tell
> the user-space program to watch for changes, possibly by something as
> simple as doing a stat now and another when it gets around to deciding if it 
> should scan the file. I see lots of room for
> user-space alternatives for change detection, depending on how much
> state it keeps. Rsync-like, perhaps?

trying to have every scanner program monitor every file that any program 
opens for write by doing periodic stat commands on it sounds like a very 
inefficiant process (and unless they then get notified on close as well, 
how do they know when to stop monitoring?)

getting a notification on the transition from scanned -> dirty is much 
less of a load (yes, it does leave open the possiblilty of a file getting 
scanned multiple times as it keeps getting dirtied, but that's a policy 
question of how aggressive the scanner is set to be in scanning files)

David Lang

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

[Eric Paris]

On Mon, 2008-08-18 at 13:54 -0400, Eric Paris wrote:
> On Mon, 2008-08-18 at 18:25 +0100, Alan Cox wrote:
> > > I think I'm going to stick with my special file in securityfs since it
> > > makes it some simple to install the fd in the scanning process (as
> > > opposed to netlink where I don't even know how it would be possible...)
> > 
> > AF_UNIX passes file handles just fine. I'm not sure netlink will help you
> > here anyway - isn't it lossy under load ?
> 
> But the file being installed needs to be at least RD for AV/Indexer.
> Particularly of interest to people here would be a file opened O_WRONLY
> and then the indexer wouldn't have the ability to read the data that was
> just written.  So we need a new FD, can't just send the old one.

Also not knowing much about sending FD's over AF_UNIX sockets, do they
share the same seek offsets or does the new process get a new fd which
points to the same data?  I wouldn't want to have to count on the
indexer to not move the offset around on the bittorrent client.  Like I
said, haven't never used sendmsg to pass a socket I don't know what you
get on the other end.

-Eric

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

[Eric Paris]

On Mon, 2008-08-18 at 11:09 -0700, david@lang.hm wrote:
> if you have multiple things reading from a pipe only one will get any one 
> message, right?

S_ISREG()  ?   We're talking about file scanning not communication
interception.  Arjan strongly wanted me to push this down to read, but I
still planned to not look at lnks, dirs, chars, blocks, fifos and
sockets...

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

[Jan Harkes]

On Mon, Aug 18, 2008 at 01:54:57PM -0400, Eric Paris wrote:
> But the file being installed needs to be at least RD for AV/Indexer.
> Particularly of interest to people here would be a file opened O_WRONLY
> and then the indexer wouldn't have the ability to read the data that was
> just written.  So we need a new FD, can't just send the old one.
> 
> I'd also assume that an HSM would need a WR file descriptor, which isn't
> easy.  I've found that (through trial and error not understanding the
> code) trying to make new descriptors for the new process have WR often
> returned with ETXTBUSY....

The devil is in the details, and besides everyone trying to heap other
things on, one thing that keeps getting brought up, and seemingly keeps
getting ignored is the fact that there already is a perfectly reasonable
interface to pass file system events (open, close, read, write, etc) to
userspace applications in the form of FUSE which has already in some
ways solved issues wrt. subtle deadlocks that can happen when you bounce
from an in-kernel context to a userspace application.

Fuse is definitely the way to go for HSM. But even for one of the
various threat models I've read in the past couple of days it would be
perfect. i.e. not allowing Linux servers to be used as a means to
propagate viruses for other machines.

The trick is to have a scanned view on the file storage though a FUSE
mount, and then have samba/knfs/apache/etc. export only the fuse mounted
tree or chroot the daemons under the scanned part of the namespace. This
provides an excellent way to separate 'trusted' applications from
non-trusted by leveraging the namespace. In fact the raw data can easily
be stored in such a way that it is owned and accessible only by fuse's
userspace process (and root) so that even without chroot, local users
can only access the data through the fuse mount/scanning layer.

And the kernel parts are already implemented, doesn't require new
syscalls, or placing policy about which processes happen to be
'priviledged' in the kernel and solves several nasty deadlocks that can
happen when you start blocking processes in their open, close, read,
write or page faulting code paths.

...
> trouble) what would it look like?  A scanner constantly calls scan() to
> block for data to be scanned?  So an AV, HSM, or indexer all would be
> blocking in scan() just waiting for data?  How do they respond?  How is

They all block at different places because they all have very different
requirements.

HSM blocks in open before the file data is present because that still
needs to be fetched. AV scan blocks after the file data is accessible
but before returning to the application and the indexer only cares about
being notified after a open for write/mmap releases the last (writing)
reference to the file, since it seems to me to be quite useless indexing
not yet or partially written data.

As far as I am concerned, this thread has been going nowhere fast by
mixing up the various requirements that come from different possible
applications that people imagine this interface being used for. As far
as I was hoping, part of "defining the threat model" line of questioning
was to avoid having discussions spin into the realm of how even with all
the protections someone could still subvert the virus scanner by
bit-flipping memory state with a scanning tunneling microscope or
something.

Jan

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

[Eric Paris]

On Mon, 2008-08-18 at 14:35 -0400, Jan Harkes wrote:

> The devil is in the details, and besides everyone trying to heap other
> things on, one thing that keeps getting brought up, and seemingly keeps
> getting ignored is the fact that there already is a perfectly reasonable
> interface to pass file system events (open, close, read, write, etc) to
> userspace applications in the form of FUSE which has already in some
> ways solved issues wrt. subtle deadlocks that can happen when you bounce
> from an in-kernel context to a userspace application.

Can you help me write/prototype something that will work for every
regular file anywhere on the system including the kernel binary
in /boot, the glibc libraries in /lib/ld-linux.so, /sbin/ldconfig and
every file on every USB stick you put into the machine?  When all of
these are on separate partitions?  Every file under / needs to be
exported to the scanner.  I'm very willing to believe fuse is the way to
go for an HSM, but I don't see how to get every single file on the
system through the FUSE based scanner.

Yes propagation is an important use of file scanning (maybe the
biggest), but we clearly can't secure every part of the border, and I
don't know how to use fuse to do it all rather than just pieces and
parts.

You're absolutely right about this thread droning on.  But I've got code
that solves the problems.  If someone else shows me better code rather
than talk I'm all for it!

-Eric

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

[Alan Cox]

> Also not knowing much about sending FD's over AF_UNIX sockets, do they
> share the same seek offsets or does the new process get a new fd which

They share the seek offset.

> points to the same data?  I wouldn't want to have to count on the
> indexer to not move the offset around on the bittorrent client.  Like I
> said, haven't never used sendmsg to pass a socket I don't know what you
> get on the other end.

man pread(). The posix committee long ago figured out that you needed a
sane way not to get involved with offsets even between processes or in
threaded apps.

Alan

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

[david]

On Mon, 18 Aug 2008, Eric Paris wrote:

> On Mon, 2008-08-18 at 14:35 -0400, Jan Harkes wrote:
>
>> The devil is in the details, and besides everyone trying to heap other
>> things on, one thing that keeps getting brought up, and seemingly keeps
>> getting ignored is the fact that there already is a perfectly reasonable
>> interface to pass file system events (open, close, read, write, etc) to
>> userspace applications in the form of FUSE which has already in some
>> ways solved issues wrt. subtle deadlocks that can happen when you bounce
>> from an in-kernel context to a userspace application.
>
> Can you help me write/prototype something that will work for every
> regular file anywhere on the system including the kernel binary
> in /boot, the glibc libraries in /lib/ld-linux.so, /sbin/ldconfig and
> every file on every USB stick you put into the machine?  When all of
> these are on separate partitions?  Every file under / needs to be
> exported to the scanner.  I'm very willing to believe fuse is the way to
> go for an HSM, but I don't see how to get every single file on the
> system through the FUSE based scanner.
>
> Yes propagation is an important use of file scanning (maybe the
> biggest), but we clearly can't secure every part of the border, and I
> don't know how to use fuse to do it all rather than just pieces and
> parts.
>
> You're absolutely right about this thread droning on.  But I've got code
> that solves the problems.  If someone else shows me better code rather
> than talk I'm all for it!

the issue is that the kernel developers are not that interested in 
creating one-off interfaces for anti-virus scanners. If the interfaces are 
more general and able to be used for a wider variety of problems they are 
much more interested in having them implemented.

unfortunantly you went off and developed a bunch of code before talking to 
people about what the appropriate interfaces would look like, (this is a 
common problem, see the 'how to participate in the kernel' document at 
http://ldn.linuxfoundation.org/book/how-participate-linux-community)

David Lang

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

[Jan Harkes]

On Mon, Aug 18, 2008 at 02:46:16PM -0400, Eric Paris wrote:
> On Mon, 2008-08-18 at 14:35 -0400, Jan Harkes wrote:
> > The devil is in the details, and besides everyone trying to heap other
> > things on, one thing that keeps getting brought up, and seemingly keeps
> > getting ignored is the fact that there already is a perfectly reasonable
> > interface to pass file system events (open, close, read, write, etc) to
> > userspace applications in the form of FUSE which has already in some
> > ways solved issues wrt. subtle deadlocks that can happen when you bounce
> > from an in-kernel context to a userspace application.
> 
> Can you help me write/prototype something that will work for every
> regular file anywhere on the system including the kernel binary
...

Going back to your own email,

| From: Eric Paris <eparis@redhat.com>
| Date: Wed, 13 Aug 2008 12:36:15 -0400
| Message-Id: <1218645375.3540.71.camel@localhost.localdomain>
| Subject: TALPA - a threat model?  well sorta.
...
| The value of a file scanning interface is not in stopping active
| attacks.  Its in making the Linux platform a more difficult location for
| the storage and propagation of bad data.  I think its reasonable to
| think that we all agree we don't want to be the preferred hosting
| platforms for trojan binaries intended to attack other non-Linux
| systems.  Why would one want consciencely choose to leave Linux as a
| safe haven for the existence of malware?  Even though the malware is not
| attacking the Linux platform do we as the Linux community really want to
| be a breeding and hosting ground as long as the costs are not too high?
...

This is the threat model I addressed in my email. So now you change the
model to something where the malware is in fact attacking the Linux
platform? Well ok, I'll bite.

> in /boot, the glibc libraries in /lib/ld-linux.so, /sbin/ldconfig and
> every file on every USB stick you put into the machine?  When all of
> these are on separate partitions?  Every file under / needs to be
> exported to the scanner.  I'm very willing to believe fuse is the way to
> go for an HSM, but I don't see how to get every single file on the
> system through the FUSE based scanner.

Have a modified initrd which contains fuse and the scanner and when
mounting the root file system also start the scanner + fuse mount, and
then instead of pivoting into the root-fs, pivot into the fuse mounted
one.

Of course that doesn't yet deal with non-root disks or external devices
that are mounted later on. This would require a modified mount sequence
so that the mount action is completed by a daemon that is running in the
trusted root next to the scanning process so that the new mountpoint is
correctly placed underneath the scanning layer. Maybe it it possible to
start a new fuse/scanning process for every mount as well, but then you
may get some things scanned multiple times because the scanner in the
lower layer ends up having to verify/validate the actions of the
scanners in higher layers.

But at some point it really is just an excerise in who or what you
trust. Because if you at least are willing to trust that the root disk
has not been compromised and the system is allowed to boot then it
would be possible to modify just the mount binary to mount the untrusted
file system in a place that is not accessible for non-priviledged users
and mount the fuse loopback in the requested location. And because mount
is modified it can 'pretend' there is no fuse layer when it updates
/etc/mtab.

As you can tell, in my scenario I do need a modified mount binary and
possibly modified initrd depending on the level of paranoia.

> You're absolutely right about this thread droning on.  But I've got code
> that solves the problems.  If someone else shows me better code rather
> than talk I'm all for it!

Not sure if it is better code, I just happened to see it while looking
if I could find the example fuse loopback filesystem code on-line, but
here you go,

    http://clamfs.sourceforge.net/

Jan

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

[Pavel Machek]

Hi!

> > On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com 
> wrote:
> > > Then there is still a question of who allows some binary to declare 
> itself 
> > > exempt. If that decision was a mistake, or it gets compromised 
> security 
> > > will be off. A very powerful mechanism which must not be easily 
> > > accessible.  With a good cache your worries go away even without a 
> scheme 
> > > like this.
> > 
> > I have one word for you --- bittorrent.  If you are downloading a very
> > large torrent (say approximately a gigabyte), and it contains many
> > pdf's that are say a few megabytes a piece, and things are coming in
> > tribbles, having either a indexing scanner or an AV scanner wake up
> > and rescan the file from scratch each time a tiny piece of the pdf
> > comes in is going to eat your machine alive....
> 
> Huh? I was never advocating re-scan after each modification and I even 
> explicitly said it does not make sense for AV not only for performance but 
> because it will be useless most of the time. I thought sending out 
> modified notification on close makes sense because it is a natural point, 
> unless someone is trying to subvert which is out of scope. Other
> have 

Why do you think non-malicious applications won't write after close /
keep file open forever?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Eric Paris]

On Tue, 2008-08-19 at 00:40 +0200, Pavel Machek wrote:
> Hi!
> 
> > > On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com 
> > wrote:
> > > > Then there is still a question of who allows some binary to declare 
> > itself 
> > > > exempt. If that decision was a mistake, or it gets compromised 
> > security 
> > > > will be off. A very powerful mechanism which must not be easily 
> > > > accessible.  With a good cache your worries go away even without a 
> > scheme 
> > > > like this.
> > > 
> > > I have one word for you --- bittorrent.  If you are downloading a very
> > > large torrent (say approximately a gigabyte), and it contains many
> > > pdf's that are say a few megabytes a piece, and things are coming in
> > > tribbles, having either a indexing scanner or an AV scanner wake up
> > > and rescan the file from scratch each time a tiny piece of the pdf
> > > comes in is going to eat your machine alive....
> > 
> > Huh? I was never advocating re-scan after each modification and I even 
> > explicitly said it does not make sense for AV not only for performance but 
> > because it will be useless most of the time. I thought sending out 
> > modified notification on close makes sense because it is a natural point, 
> > unless someone is trying to subvert which is out of scope. Other
> > have 
> 
> Why do you think non-malicious applications won't write after close /
> keep file open forever?

If you ask this one more time without reading the many times I've
answered these questions I think I'm going to explode.

Permissions checks are done on open/read.  Decisions are invalidated at
mtime update, which INCLUDES mmap after close!  I don't care if you keep
your file open forever, if you wrote to it, we are just going to scan it
next time a process decided to open/read it.  Please stop confusing this
already long and almost pointless thread with implementation details
that have repeatedly been explained.

-Eric

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

[Peter Dolding]

On Tue, Aug 19, 2008 at 9:07 AM, Eric Paris <eparis@redhat.com> wrote:
> On Tue, 2008-08-19 at 00:40 +0200, Pavel Machek wrote:
>> Hi!
>>
>> > > On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com
>> > wrote:
>> > > > Then there is still a question of who allows some binary to declare
>> > itself
>> > > > exempt. If that decision was a mistake, or it gets compromised
>> > security
>> > > > will be off. A very powerful mechanism which must not be easily
>> > > > accessible.  With a good cache your worries go away even without a
>> > scheme
>> > > > like this.
>> > >
>> > > I have one word for you --- bittorrent.  If you are downloading a very
>> > > large torrent (say approximately a gigabyte), and it contains many
>> > > pdf's that are say a few megabytes a piece, and things are coming in
>> > > tribbles, having either a indexing scanner or an AV scanner wake up
>> > > and rescan the file from scratch each time a tiny piece of the pdf
>> > > comes in is going to eat your machine alive....
>> >
>> > Huh? I was never advocating re-scan after each modification and I even
>> > explicitly said it does not make sense for AV not only for performance but
>> > because it will be useless most of the time. I thought sending out
>> > modified notification on close makes sense because it is a natural point,
>> > unless someone is trying to subvert which is out of scope. Other
>> > have
>>
>> Why do you think non-malicious applications won't write after close /
>> keep file open forever?
>
> If you ask this one more time without reading the many times I've
> answered these questions I think I'm going to explode.
>
> Permissions checks are done on open/read.  Decisions are invalidated at
> mtime update, which INCLUDES mmap after close!  I don't care if you keep
> your file open forever, if you wrote to it, we are just going to scan it
> next time a process decided to open/read it.  Please stop confusing this
> already long and almost pointless thread with implementation details
> that have repeatedly been explained.
>
You will see latter where what you just said fails and its issue is
preventable too downloader with build in previewer.

Funny enough solution to this is fairly simple.   But does require
looking at a white list methods and LSM.

Two major ways.    White list format check method tells you that file
is not complete enough so black list scanning is not required yet.  Ok
lighter than running 5000 black list signatures over it each time a
new block gets added.

Unfortunately scan of all pieces as them come in for possible threat
still has to be done reason on videos and the like people in some
applications start playing them before the download is complete.
Lots of video and audio formats have blocks that can be cleared piece
by piece.   Just like a bittorrent can scan and pass block by block so
does a white list scanner need to be able to.  More creative use can
be void block insert into some formats.   Ie part downloaded block at
X replaced with a equal to blank block to the player  that is external
to the download tool.   This is damaged data access prevention.
Nicely prevents some stability issues and gives users extra features.

White list scanner knowing the format can detect when enough segments
are in a file to run a black list scan avoiding jack hammering the cpu
eating black list scan.

Dealing with bittorrent clients with built in preview is a pain in the
you know what.   Since are they reading the file to send to someone
else are they reading the file to display in there internal viewer or
do they take straight from there download buffer to internal view.
Even worse lots of bittorrent streams are encrypted and cannot be
scanned while network packets.   So second solution required a LSM
around the downloader preventing it in case of breach being able to go
anywhere in the system.   LSM only allows access to files that the
downloader has downloaded by other applications with more rights when
its pasted White list and needed black list scanning.

Getting this to work without using white list of known format method
and LSM is basically imposable because a black list is going to take
far to much cpu time scanning incomplete files.

This is one of the reasons why the system is 4 tech groups.  HIDS,
white list methods, black list methods and LSM.      Without all 4 you
are stuffed trying to make a prevention system work because you will
get snagged somewhere trying to cover all setups and events.   A
combination is required some setups can get away without the black
list.   There are many points where current black list methods are
flawed or hurt way too much.

Some of these will require looking at two extra tech groups.   1 being
intergation into applications.   2 providing apis for applications to
do particular protocols and blocking out direct network access other
than threw those apis.

Lot of windows anti-virus people are way too focused on black list.
White list might annoy you from time to time but it can also grant
features that users may not want to give up.

Peter Dolding

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

[douglas.leeder]

malware-list-bounces@dmesg.printk.net wrote on 2008-08-19 02:15:49:

> You will see latter where what you just said fails and its issue is
> preventable too downloader with build in previewer.
> 
> Funny enough solution to this is fairly simple.   But does require
> looking at a white list methods and LSM.
> 
> Two major ways.    White list format check method tells you that file
> is not complete enough so black list scanning is not required yet.  Ok
> lighter than running 5000 black list signatures over it each time a
> new block gets added.


You seem to have some very funny ideas about what white-listing and 
black-listing 
scanners do.

Checking filetypes and checking for complete/non-corrupt files is 
something
black-listing scanners do.

Where-as whitelisting: 
"An emerging approach in combating viruses and malware is to whitelist 
software which is considered safe to run, blocking all others"

While ensure media files are complete could be done by a scanner that
also does white-listing, I don't think it's a core part.

> Dealing with bittorrent clients with built in preview is a pain in the
> you know what.   Since are they reading the file to send to someone
> else are they reading the file to display in there internal viewer or
> do they take straight from there download buffer to internal view.
> Even worse lots of bittorrent streams are encrypted and cannot be
> scanned while network packets.   So second solution required a LSM
> around the downloader preventing it in case of breach being able to go
> anywhere in the system.   LSM only allows access to files that the
> downloader has downloaded by other applications with more rights when
> its pasted White list and needed black list scanning.

So?

We not talking about throwing away LSM, or replacing it in any way.

This discussion is about an additional scanning path, for files, for any 
kind of content-based 
scanning.


> 
> Getting this to work without using white list of known format method
> and LSM is basically imposable because a black list is going to take
> far to much cpu time scanning incomplete files.

So?


> Lot of windows anti-virus people are way too focused on black list.
> White list might annoy you from time to time but it can also grant
> features that users may not want to give up.

The thing is Windows has had built-in white-listing for a long
time, and yet there is still a market for AV scanners, this suggests 
people don't like white-listing.

Also consider all of the problems and criticism Vista's UAC has had. And 
UAC is 
only white-listing privileged operations. 

-- 
Douglas Leeder

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

[tvrtko.ursulin]

david@lang.hm wrote on 18/08/2008 18:07:30:

> On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com wrote:
> 
> > Theodore Tso <tytso@mit.edu> wrote on 18/08/2008 15:25:11:
> >
> >> On Mon, Aug 18, 2008 at 02:15:24PM +0100, tvrtko.ursulin@sophos.com
> > wrote:
> >>> Then there is still a question of who allows some binary to declare
> > itself
> >>> exempt. If that decision was a mistake, or it gets compromised
> > security
> >>> will be off. A very powerful mechanism which must not be easily
> >>> accessible.  With a good cache your worries go away even without a
> > scheme
> >>> like this.
> >>
> >> I have one word for you --- bittorrent.  If you are downloading a 
very
> >> large torrent (say approximately a gigabyte), and it contains many
> >> pdf's that are say a few megabytes a piece, and things are coming in
> >> tribbles, having either a indexing scanner or an AV scanner wake up
> >> and rescan the file from scratch each time a tiny piece of the pdf
> >> comes in is going to eat your machine alive....
> >
> > Huh? I was never advocating re-scan after each modification and I even
> > explicitly said it does not make sense for AV not only for performance 
but
> > because it will be useless most of the time. I thought sending out
> > modified notification on close makes sense because it is a natural 
point,
> > unless someone is trying to subvert which is out of scope. Other have
> > suggested time delay and lumping up.
> >
> > Also, just to double-check, you don't think AV scanning would read the
> > whole file on every write?
> 
> if it doesn't read the entire file and only reads the parts that change, 

> out-of-order writes (which bittorrent does a _lot_ of) can assemble a 
> virus from pieces and the scanner will never see it.

No, it would catch it once it gets assembled. It doesn't read the parts 
that change but parts which it finds interesting.
 
> as for Ted's issue, the scanner(s) would get notified when the file was 
> dirtied, they would then get notified if something scanned the file and 
it 
> was marked dirty again after that. If nothing got around to scanning the 

> file then all the following writes would not send any notification 
becouse 
> the file would already be dirty.

This sound like a good strategy.

--
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

[Peter Dolding]

On Tue, Aug 19, 2008 at 6:09 PM,  <douglas.leeder@sophos.com> wrote:
> malware-list-bounces@dmesg.printk.net wrote on 2008-08-19 02:15:49:
>
>> You will see latter where what you just said fails and its issue is
>> preventable too downloader with build in previewer.
>>
>> Funny enough solution to this is fairly simple.   But does require
>> looking at a white list methods and LSM.
>>
>> Two major ways.    White list format check method tells you that file
>> is not complete enough so black list scanning is not required yet.  Ok
>> lighter than running 5000 black list signatures over it each time a
>> new block gets added.
>
>
> You seem to have some very funny ideas about what white-listing and
> black-listing
> scanners do.
>
> Checking filetypes and checking for complete/non-corrupt files is
> something
> black-listing scanners do.
Pure Black List don't.   Pure Black List is looking for a known threat
that is the end of there skill.

Lot of current black list scanners are hybred.   They are using known
format white list sorting there databases.   Basically they are using
white list methods without admitting it.
>
> Where-as whitelisting:
> "An emerging approach in combating viruses and malware is to whitelist
> software which is considered safe to run, blocking all others"
>
> While ensure media files are complete could be done by a scanner that
> also does white-listing, I don't think it's a core part.
>
You are missing something critical.   Really critical.  There are such
things as Heuristic White List scanner.

Heuristic White List scanners are something you use on document
archives or for faster sorting out of a system breached by a unknown
somewhere in a stack of document files.

Major diff between Heuristic Black List and Heuristic White List.   Is
that Heuristic White List does not contain threats.   Instead
Heuristic White List contains knowledge about the formats is
processing and allowed exceptions alone.    So a doc file containing a
macro would be thrown out as a threat by a Heuristic White List unless
the Macro in the doc is included in the list of exceptions.

You find that Heuristic White List's are operating inside a lot of the
black list systems.   Reason with out it there threat processing would
simply unable to be done.

The damaged file detection in current day AV's is not black list its
white list people have mixed the two techs and want to forget the
divide.

Forced to used yet then they wrap what the white list system finds
away from the user.  Basically on the idea if they give you notice you
will do the wrong thing.  Anti-Virus companies are basically taking
the attitude to white lists is use but never show to user.

Truly operating Heuristic White List knowing file formats when it
detects something questionable gives users a few options.   Access
document without threat ie produce new copy of doc with macro striped,
 Run past a black list for that kind of threat, quarantine or delete
it.   Current AV auto set the run past black list from their Heuristic
White List.

This current auto pathing into black list has quite a few downsides.
 Black List section is going to get longer so one day processing time
will be too much again.   No way to work around signature not being
released in time.

Heuristic White List is one of the few things that can close the gap
on the black list system simple quarantine the file if user don't need
it straight up user can choose to wait a week/month before scanning it
with up to date signatures even better with like doc files and lots of
others with embeded macros lots of them document is still accessible
with it striped.    So the issue of a black list signature turning up
1 hour after getting the file will no longer be a problem for
everyone.  Users could even get use to delaying macros and exe's as
status normal in time.

Notice the effect on doc viruses when word started asking users if
they wanted to run macros.   This is a heuristic white list method.
You know there could be a threat you ask user if it is what they
expect.   This has had a far great effect on doc file viruses than any
doc related black list virus entry.   It got out of the race between
attacker and black list.

White List methods are far more developed and embedded in a lot of
locations people are blind to them.   People have got use to thinking
twice when a document asks them to allow macros.   Anyone guess the
problem here with auto black list processing.   File has been scanned
against a black list even if the user will never use the macro.  What
a waste of CPU time if there was a virus in that file it would have
never got life.

Heuristic White List embeded in online clients for incoming and out
going truly allows people to swap files with 100 percent trust.   If
the white list allows the format because it contains nothing that no
matter how fine could be a threat.   Black Listing can never be used
to offer trust over the internet.

Heuristic White List scanners date from before 1994 when I first come
across them.  Major issue then was too many formats closed spec this
has changed.   "emerging approach" that is crap.   Its been a hidden
approach that AV companies and others don't want to have to admit they
are using and that has proven itself far more effective than any black
list.  In combination with black list if the balance is right gets the
best results.   Currently all anti-virus software has the balance
wrong for most effective protection.   Also by not providing it to
users as a option is really lack of responsibility.  Lot of cases
business email and archive document storage could be covered against
viruses by a pure white list system striping all possible threats.
Effectively blocking 100 percent of all viruses threw that path in or
out due to business following standard of not archiving macros or
sending macros.   Yes its going to remove a little too much at times.

UAC is poor design.   selinux also white lists privileged operations.
catch is it remembers between reboots and does not ask user over and
over and over again for the same approvals.   That is UAC failing no
memory.  White list + memory is required so it don't drive users up
wall.  This of course is a balance again if the remembering of the UAC
like system is wrong it gets abused.  Lot of firewalls got this right
for permissions as well bug the user a lot a first after programmed
don't bug user much.  This is exactly the same job as UAC except on
networking and most operate by a white list method.

Its wrong that users hate white listing its how the white listing is done.

A black list anti-virus false positive on stacks on stacks of files it
should not be will also drive user up wall.   Either the design
functions right or it not and it has nothing todo with black list or
white list both can be screwed up in design.

White listing is heavily used without upsetting users.  Ok may upset
users at first but test of time says they will get use to it and treat
it as normal.   Do you need someone with a lot of IT history knowledge
and knowledge of different protection designs?

Peter Dolding

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[david]

Having talked with Eric a bit more it looks like we have some fairly 
fundamentally different views on the scope of how this sort of thing would 
be used and that is causing us to talk about different things.

we are both looking at the threat model of trying to provide hooks so that 
data is scanned before allowing programs to use it (neither of us is 
talking about trying to do LSM things). where we differ is the uses we 
expect the hooks to be put to.

please note that I am trying to state Erics position, I may be mistaken.

Eric is viewing this through the AV point of view,
   this means

He doesn't expect there to be many scanners on a system
   initally he was only thinking of one.

He expects the interactions between the scanners to be simple (i.e. all 
scanners must bless a file or it's considered bad)
   the policy is simple and will always be the same

He expect AV signatures to change rapidly
   so storing the results of scans is of very limited value

He is expecting the scanning software to set the policy
   so there is no reason to have a system/distro defined policy

He is thinking that any ability to avoid doing the scan is a security 
hole.


these things are leading him to the kernel-based implementation that he 
posted.



I am seeing things (I think) a bit more broadly (definantly differently).

I think that the availability of a general 'this file was written to' 
interface in the kernel combined with 'take action before opening' will 
lead to many uses beyond AV work.
   these include things like filesystem indexers, HSM systems, backup 
software as well as security scanners (IDS, 'tripwire', as well as AV)

I expect to see IDS type scanners, possibly multiple ones on a machine, 
each fairly simple and not trying to do a complete job, but authoritative 
within it's area.
   this means that the interaction between approvals is more complex and 
not something that should be coded into the kernel, it should be 
configured in userspace.

becouse of things like indexers, backups, and IDS type I see great value 
in storing the fact that a file was scanned across reboots for some users 
(other users may not want to trust the system without re-scanning it after 
a reboot in case the files were changed)

In an enterprise environment I can see value in having much of the 
scanning done by one system and trusted by other systems
   this pushes for permanent, disk-based caching of scan results

I expect the distro/sysadmin to set the policy, in part becouse I expect 
to see multiple scanners and the thought of each of them setting system 
policy seemd a recipe for problems.

As part of the overall policy settings I think that there are cases where 
it's appropriate for many programs to not have the files scanned before 
accessing them (trivial examples for non-HSM environments, wc, tar, file, 
backup software)
   while this can open security holes, so can setting permissions and LSM 
configs. getting this right is part of the responsibility of the sysadmin 
(and the distro has the responsibility of giving the sysadmin reasonably 
sane defaults to start from)


these things are leading me to advocate using xattr as the result cache 
(so it will survive reboots), and userspace libraries for the hooks into 
open/read/mmap/etc (to allow for the more complex policies that I expect 
to see)


Eric has one other significant advantage, he has produced code, and is 
presumably payed to work on this (based on his posts and @redhat address)

I am a user/tester advocating a design that I think is superior, but am 
not likly to end up being the one to code it. besides the time involved, I 
consider myself a decent programmer, but don't consider myself to be ready 
to tackle this sort of task (either the kernel hooks or the userspace 
library hooks).



At this point I think opinions are needed for how generalized these hooks 
should be, and how difficult it should be for things on a system to be 
configured to bypass the scans.

thoughts?

David Lang

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

[Peter Dolding]

On Tue, Aug 19, 2008 at 9:40 PM,  <james.lyne@sophos.com> wrote:
>
> As for the example you have given with macro viruses, I disagree that this
> is whitelisting. In this case, the application which originally introduced a
> specific class of security risk added additional controls and warnings to
> prevent abuse. This was a good feature and should be encouraged, but I don't
> believe this constitues whitelisting. This is comparable perhaps to some of
> the moves made by Firefox to generically detect abuse of their script
> runtime and alert the user of supsicious activities.
>
Its a class of white listing under developed.  Just because the
application created the thread does not change there answer.   For a
time some of these programs also tried answering with built in black
lists as well the black list methods have failed and the white list
method remains as the winner.  Firefox is basically building in a form
of whitelisting.    Heuristic White listing is about suspicious not
about exact threat identification.

Major issue is simple.  I will give some examples where white listing
along comes into its own.   Issue is lots current scanners don't even
allow user to go that path.

Lets say I have a file store of documents like letters spread sheets
and  so on  being kept for archival reasons.   This documents can
exist executable code free and needed to exist damage free.   No
executable code no viruses/trojans/trouble also no executable code is
good for long term archives since the processing of executable code
could change.  Damage free removes buffer overflow and damaged format
attacks.   Current Anti-viruses take the line I must scan and rescan
against a black list.  This has effectively means a 100 GB archive
becomes imposable to scan and give a clean rating to because its a
never ending process.  White list scanning the archive is not a never
ending process only time it has to be redone is if the White List
scanner was imperfect for the formats in the archive ie missed some
executable or buffer overflow/damaged sections in the formats it
knows.   This is 100 percent a failure to provide what is needed by
anti-virus companies.

Emails and IM more people don't normally intentionally send executable
code to each other.  White listing using format aware scanner  here is
a great stop unknown threats straight up  even question user about
unknown format they are receiving most users would not take as a bad
thing.

Anti-virus companies complain about Linux not providing them with a
stable api to integrate into Linux kernel.   Anti-virus companies are
also guilty of the reverse to Download, IM and Email programs.   No
stable common api for developers to use your products instead you hack
in.   Really you need to be working hand and hand with these programs.
 Reason with a lot of these programs the transferred data itself may
start being access and running before its transferred out of memory
and before you get a chance to scan it particularly as encryption
becomes more heavily used.   Stable API on both sides helps everyone.

Sorry to say mass installed Linux clients working off a central update
server white listing the complete network is simple.   All updates are
coming threw one location.  Black list scanning the update server
effectively scans all installed applications if the network is locked
down.  So as long as white list scanning is maintained on the clients
of the business update server preventing anything else from entering
the network is protected.   Same kind of thing can be done with
windows but since you cannot simply jack the white list system into
the update server its harder.

Part of the way forward is accepting that scanning techs are two
halfs.   White lists and Black Lists.   Next is accepting that at
times users need White List suspicious answers more than Black List
this is the threat answers.   Then working out how to give them White
List scanning in a controlled way.   User being able to set how the
anti-virus responds when it gets a White List suspicious answer.
Some users will stick with the status now of white list suspicious
going straight into black list.   Others due to different needs will
choose to do the other things like

1. Quarantine amount of time to get a more up to date scanner.   This
is particularly useful if user has just connected there laptop to the
internet after a while off line and has downloaded there emial before
the anti-viruses black lists are updated or for some reason users
cannot update there anti-virus due to server issues.   Users still
need to be able to use email and other things safely.  Current black
list forced path is failing users since if the black list passes the
white list suspicious from looking at the format is disregarded.

2.  User knows a section of there storage that should not contain
anything that a white list should detect.  So alteration there is a
threat id of the threat is not high up list.   Becides if its a
unknown threat current method see it slip threw.   Of course any
detection like this should offer to go threw black list for format ID
and only clear if user approves.   Not the current auto pass of the
current hook up.

Corrupted identification is a white list methods.   Started off with
like the likes of validators these tools know the file formats they
are looking at and sort out damaged from undamaged.  When doing data
recovery most people don't have a nice list of checksums to give you
instead you need to sort out what files are still usable this is where
validators come in.   There is no list part to a validator only thing
it knows is the format itself slightly altered validators become white
list heuristic scanners ie lots of added if this is present don't
trust the file.   Basically over time more and more white list methods
have drifted into anti-virus engines.   Big issue you have forgotten
that they are not Black List.

Sorting Black and White list methods is dead simple.   Its the
information you need to create them.  If you need to know about the
evil stuff to create them you are in Black List.   If you only need to
see above board stuff like specs for formats you are in white list.
People have forgot the divide.   Its also critical to remember due to
both have different advantages and disadvantages.

Advantage of the White List Group 100 percent detection of threats is
achievable and is slower growing database if you use heuristic
methods.  Disadvantage of White List Group used in the set-up alone
can block too much ie Can have a higher false positive rate.

Advantage of the Black List Group low false positive rate.
Disadvantage can have a false negatives.

Using white list checksum methods really large storage required and is
infective against user created documents to the same level black lists
checksum based are useless against user created documents.

Basic threat detection design.   White List then anything rejected
must Pass threw Black List before being allowed run.    Now deleting
before passing threw black list has to be acceptable.

Users are asking for 100 percent protection from viruses where able.
The tech to give them that at a price has existed for years.   About
time White List Heuristics are given to end users as a tool to use if
it suits there current setup.   This is allowing users at there own
choosing to get ahead of the attackers.

Peter Dolding

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[Eric Paris]

On Tue, 2008-08-19 at 19:44 -0700, david@lang.hm wrote:

> please note that I am trying to state Erics position, I may be mistaken.

you did pretty well.

> He expect AV signatures to change rapidly
>    so storing the results of scans is of very limited value

Not quite.  I believe it should be the responsibility of the scanner to
determine how and if they want to store the results of the scan.  I'm
willing (and want) to provide a simplistic kernel fast path if all of
the scanners agree to use it.

> He is expecting the scanning software to set the policy
>    so there is no reason to have a system/distro defined policy

I'm not sure of the definition of this 'policy' but, yes, I think all
scanners should make their own decisions in their own little bubble.


> I am seeing things (I think) a bit more broadly (definantly differently).
> 
> I think that the availability of a general 'this file was written to' 
> interface in the kernel combined with 'take action before opening' will 
> lead to many uses beyond AV work.

At the moment I'm leaning towards a separate async notification system
for open/mtime change/close which will be a fire and forget notification
system with no access control mechanism.

A second, although very similar, mechanism will block on read/mmap
(although I'm not so sure how to handle O_NONBLOCK without a kernel
fastpath/inode marking that actually gets used, this is really a serious
design issue with putting this at read/mmap.  I don't think we are ready
to give up on O_NONBLOCK for S_ISREG altogether just yet are we?) and
provide access control.  I also plan to include open() in the
blocking/access control based on a /proc tunable.  If applications can't
handle EPERM at read/mmap they can get it at open and suffer the
perf/blocking hit needlessly on open/stat sequences.

> I expect to see IDS type scanners, possibly multiple ones on a machine, 
> each fairly simple and not trying to do a complete job, but authoritative 
> within it's area.
>    this means that the interaction between approvals is more complex and 
> not something that should be coded into the kernel, it should be 
> configured in userspace.

I don't understand how something can be 'authoritative within it's area'
and still have a 'complex interaction policy.'  I see it as, either yes
means yes and no means no, or it isn't authoritative.

If two scanners need some complex interaction it certainly needs to be
in userspace, no question there.  Sounds like a dispatcher daemon needs
to get the notification from the kernel and send them to the scanners
and then let it do all sorts of magic and sprinkling of pixie dust
before the daemon return an answer to the kernel.  In the end that
deamon is the authoritative thing.  I don't plan to write it since I
don't see the need, but the possibility of writing a dispatcher daemon
certainly exists if there is actually need.

Everything says yes at read/mmap we allow.  Anything says no we deny.
You need more than that write an intermediary daemon in userspace to
govern that interaction.

> becouse of things like indexers, backups, and IDS type I see great value 
> in storing the fact that a file was scanned across reboots for some users 
> (other users may not want to trust the system without re-scanning it after 
> a reboot in case the files were changed)

My answer is that if they want to store whatever it is they care about
across boots so the scanner can write an xattr to help.  I believe that
all scanners are going to need/want to have some for of userspace
caching.  I plan to provide a fastpath in kernel scanners can make use
of, but anything more complex should be a completely userspace solution
and should be able to be built on what I provide at a later time.

> Eric has one other significant advantage, he has produced code, and is 
> presumably payed to work on this (based on his posts and @redhat address)

Not paid much   :)

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[david]

On Wed, 20 Aug 2008, Eric Paris wrote:

> On Tue, 2008-08-19 at 19:44 -0700, david@lang.hm wrote:
>
>> please note that I am trying to state Erics position, I may be mistaken.
>
> you did pretty well.

thanks.

>> I expect to see IDS type scanners, possibly multiple ones on a machine,
>> each fairly simple and not trying to do a complete job, but authoritative
>> within it's area.
>>    this means that the interaction between approvals is more complex and
>> not something that should be coded into the kernel, it should be
>> configured in userspace.
>
> I don't understand how something can be 'authoritative within it's area'
> and still have a 'complex interaction policy.'  I see it as, either yes
> means yes and no means no, or it isn't authoritative.

as an example.

if the system package manager says the syslogd binary doesn't match the 
checksum that it has recorded should it be prevented from running? (a 
strict policy would say no, but the sysadmin may have recompiled that one 
binary and just wants a warning to be logged somewhere, not preventing the 
process from running)

what happens if scanner A (AV scanner) says that a binary has a virus in 
it, but scanner B (IDS scanner checkins checksums) says that it's the 
right version? what mechanism do you have to say that a yes from scanner B 
overrides a no from scanner A?

> If two scanners need some complex interaction it certainly needs to be
> in userspace, no question there.  Sounds like a dispatcher daemon needs
> to get the notification from the kernel and send them to the scanners
> and then let it do all sorts of magic and sprinkling of pixie dust
> before the daemon return an answer to the kernel.  In the end that
> deamon is the authoritative thing.  I don't plan to write it since I
> don't see the need, but the possibility of writing a dispatcher daemon
> certainly exists if there is actually need.

that could work, the need to have the userspace daemon to do the more 
complex things was part of what was pushing me to think in terms of 
userspace hooks for open/read/mmap/etc instead of kernelspace hooks 
(avoiding the context switches you mentioned in an earlier message becouse 
you start in userspace)

> Everything says yes at read/mmap we allow.  Anything says no we deny.
> You need more than that write an intermediary daemon in userspace to
> govern that interaction.
>
>> becouse of things like indexers, backups, and IDS type I see great value
>> in storing the fact that a file was scanned across reboots for some users
>> (other users may not want to trust the system without re-scanning it after
>> a reboot in case the files were changed)
>
> My answer is that if they want to store whatever it is they care about
> across boots so the scanner can write an xattr to help.  I believe that
> all scanners are going to need/want to have some for of userspace
> caching.  I plan to provide a fastpath in kernel scanners can make use
> of, but anything more complex should be a completely userspace solution
> and should be able to be built on what I provide at a later time.

without the kernel support to clear the flags when the file is dirtied how 
can these programs trust the xattr flags that say they scanned the file 
before?

you also mention using mtime, I don't think that's granular enough. we 
already have people running into problems during compiles with fast 
machines not being able to detect that a file has changed by the mtime.

I'm not saying that xattr is the only way to store the info, it just seems 
like a convienient place to store them without having to create a 
completely new API or changing anything in on-disk formats.

the real requirements that I see are more like this

1. must be able to be cleared by the kernel when the file is dirtied

2. must be able to be persistant across reboots

3. should allow free-form tags to be stored by scanners

4. if it's deemed nessasary to close the race condition of a file getting 
modfied while the scanner is scanning it, there should be an 'atomic to 
userspace' call to set a tag IFF an old tag exists. This is a new API 
call, but would only need to be used by the scanners.

while #3 can cause conflicts between scanners, I don't expect that in 
practice (I expect each scanner to use their own unique prefix to avoid 
conflicts)

David Lang

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[david]

On Wed, 20 Aug 2008, Eric Paris wrote:

>> He is expecting the scanning software to set the policy
>>    so there is no reason to have a system/distro defined policy
>
> I'm not sure of the definition of this 'policy' but, yes, I think all
> scanners should make their own decisions in their own little bubble.

I realized I need to reply to this part just after hitting send on the 
reply to the rest of it.

part of the policy that needs to be set is when scans do and don't need to 
be done.

you almost never want to have 'scans' take place when scanners access 
files (the HSM restore is the only exception), and there are significant 
performance benifits in exempting other programs as well.

you are saying that the decision of which programs to skip and which ones 
to not skip should be the responsibility of the scanner. I disagree for a 
couple of reasons

1. I don't think that the scanner can really know what program is trying 
to do the access.

2. I think the policy of which files to limit to scanned data and which 
ones to allow access to unscanned data should be a sysadmin decision 
(assisted by the distro), not something set through the scanning software. 
In sort I don't trust Symantec, Macafee, etc to make the correct decisions 
for all the different linux distros out there, or for the different 
scanners to provide sane, consistant interfaces to specify this sort of 
thing. I expect each of them to take the attitude that they know what's 
best, and hard-code the policy with little (if any) allowance for 
exceptions, and that exception list would be managed differently for each 
scanner.

David Lang

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[Eric Paris]

On Wed, 2008-08-20 at 10:33 -0700, david@lang.hm wrote:

> if the system package manager says the syslogd binary doesn't match the 
> checksum that it has recorded should it be prevented from running? (a 
> strict policy would say no, but the sysadmin may have recompiled that one 
> binary and just wants a warning to be logged somewhere, not preventing the 
> process from running)

My belief is that if you choose to run a file scanner and that file
scanner gets the answer wrong you need to look at the file scanner.
There shouldn't be arbitrary overrides.  If you don't accept the results
of the scanner what's the point?  Tell you package manager scanner that
you changed it.

> without the kernel support to clear the flags when the file is dirtied how 
> can these programs trust the xattr flags that say they scanned the file 
> before?

I don't understand what you mean about trust.  This is an argument for
kernel support now?  What is it that you say needs and what doesn't need
it?  Can you explain exactly what your perfect solution from top down?

> I'm not saying that xattr is the only way to store the info, it just seems 
> like a convienient place to store them without having to create a 
> completely new API or changing anything in on-disk formats.

And I saying we don't actually need any of this and if it is actually
needed by someone in the real world they can easily build their own
solution on top of my generic interface.  I'm not making the assertion
it is race free and don't think it is possible without making every
sequential (hahahaha.)  But I claim in the face of normal operation it's
fine.  My interface, as proposed, is very generic.  Much more so than
what I think you are trying to describe.  I couldn't make mine more
minimal or broad.

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[david]

On Wed, 20 Aug 2008, Eric Paris wrote:

> On Wed, 2008-08-20 at 10:33 -0700, david@lang.hm wrote:
>
>> if the system package manager says the syslogd binary doesn't match the
>> checksum that it has recorded should it be prevented from running? (a
>> strict policy would say no, but the sysadmin may have recompiled that one
>> binary and just wants a warning to be logged somewhere, not preventing the
>> process from running)
>
> My belief is that if you choose to run a file scanner and that file
> scanner gets the answer wrong you need to look at the file scanner.
> There shouldn't be arbitrary overrides.  If you don't accept the results
> of the scanner what's the point?  Tell you package manager scanner that
> you changed it.

and this is the core disagreement we have. I don't trust the AV vendors 
that much. I want there to be some way for me to disagree with them.

I've had AV false positives a few too many times where it flagged critical 
software as being bad to be comfortable giving them that much control

>> without the kernel support to clear the flags when the file is dirtied how
>> can these programs trust the xattr flags that say they scanned the file
>> before?
>
> I don't understand what you mean about trust.

if a program set an xattr to say that it scanned the file and then the 
system reboots, how can this program know that the file hasn't been 
modified since that xattr was set? your in-memory data is gone, so you 
can't tell from that. the xattr tag is still there.

> This is an argument for
> kernel support now?  What is it that you say needs and what doesn't need
> it?  Can you explain exactly what your perfect solution from top down?

1. a flag mechansim (namespace in xattr or something else) that allows for

1a. scanners to store arbatrary tags in a way that will survive a reboot.

1b. when the file is dirtied the kernel clears all flags that have been 
set on this file.

   especially for mmap access the kernel is in a good position to detect 
that the file has been dirtied, but nothing else is.

1c. when the kernel detect a formerly clean file getting dirtied it sends 
a message to userspace in a way that multiple scanners can receive the 
alerts

1d. to close the race of the file being modified while it's being scanned, 
add a system call (atomic as far as userspace is concerned) that sets a 
new tag IFF an old tag is set

2. on access a check is done against a list of 'required' tags, if not all 
tags are present the master scanning logic is invoked.

   for several reasons I've been thinking that this step could/should be 
done 
in userspace

If done in userspace

2a. define a place to record the 'required' tags.

   one way to do this is to have a directory for it, programs define 
'required' tags by creating a file with that as it's name with the 
contents of the file including the scanner name and the command line to 
execute to perform a scan

2b. define a way of stacking different scanners (being able to define what 
to do if each scanner says "yes", "no", "I don't know", "the file changed 
under me", and "the file changed under me, but I think I found a problem", 
and what to do with the combination of different answers).

   it may be that something resembling the way that pam works would be 
suitable.

3. modify knfsd so that it does the on access checks that the userspace 
library could do for #2 and calls out to the master scanning logic.

   this is new since the last time I wrote up the proposal (the first 
message in this thread), and is definantly more work, but in thinking 
about it I am starting to think that if the userspace solution is a good 
fit for everything but static binaries and knfsd, then the answer is to 
modify knfsd and say that the sysadmin/distro is responsible for making 
the static binaries compiled against the right libraries

when programs get ready to start scanning they can set a tag 
'app-scanning' when they complete the scan they can use the atomic op to 
say "if the tag 'app-scanning' is set, clear it and set the tag 
'app-scanned-gen1234'" (if 'app-scanning' is not set then the file was 
dirtied after the scan started)

if a program is running as part of an on-access scan it would then return 
it's opinion of the file.

it would be up to the master software (2b) to decide what to do if the 
scanners disagree, no scanner voices an opinion, or if a scanner reports 
the file changed while it was scanning it (it may want to kick off the 
scan immediatly, it may want to wait, it may want to limit the number of 
times it tries to scan a file and then either just allow or deny the 
access (all these thing are policy decisions)


>> I'm not saying that xattr is the only way to store the info, it just seems
>> like a convienient place to store them without having to create a
>> completely new API or changing anything in on-disk formats.
>
> And I saying we don't actually need any of this

I know, this is the core of our disagreement.

> and if it is actually
> needed by someone in the real world they can easily build their own
> solution on top of my generic interface.

most stuff could be, but I don't think everything could.

> I'm not making the assertion
> it is race free and don't think it is possible without making every
> sequential (hahahaha.)

I think we can make it race free.

> But I claim in the face of normal operation it's
> fine.  My interface, as proposed, is very generic.  Much more so than
> what I think you are trying to describe.  I couldn't make mine more
> minimal or broad.

and I am thinking that the slight additional step of having the kernel 
clear all tags rather then just having a single 'it was ok' tag is a 
significant advantage.

beyond that I think both approaches can work, the difference is how 
simple/complex we think the result is going to be used.

I think that we both agree that if you are right about how simply it's 
going to be used, you are also correct in putting it all in the kernel. 
however if I'm right about it being used for more complex things, then 
significant parts of it belong in userspace.

based on my beleive that much of this belongs in userspace, I'm then 
saying that it may make sense for all of #2 to be in userspace.

David Lang

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for access scanning

[douglas.leeder]

Eric Paris wrote on 2008-08-20 16:15:21:

> At the moment I'm leaning towards a separate async notification system
> for open/mtime change/close which will be a fire and forget notification
> system with no access control mechanism.
> 
> A second, although very similar, mechanism will block on read/mmap
> (although I'm not so sure how to handle O_NONBLOCK without a kernel
> fastpath/inode marking that actually gets used, this is really a serious
> design issue with putting this at read/mmap.  I don't think we are ready
> to give up on O_NONBLOCK for S_ISREG altogether just yet are we?) and
> provide access control.  I also plan to include open() in the
> blocking/access control based on a /proc tunable.  If applications can't
> handle EPERM at read/mmap they can get it at open and suffer the
> perf/blocking hit needlessly on open/stat sequences.

I think these are excellent ideas. 

The kernel really does have to keep some record if it's going to do any 
scanning from read() calls, it can't go to userspace each time to check
if a file is cached.
(It might be the single open file descriptor that's marked though)

O_NONBLOCK is then handled nicely, and we can avoid ever blocking that 
client process (which given they're trying non-blocking IO is probably 
a good thing).

-- 
Douglas Leeder



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 linux interface for access scanning

[david]

On Thu, 21 Aug 2008, douglas.leeder@sophos.com wrote:

> Eric Paris wrote on 2008-08-20 16:15:21:
>
>> At the moment I'm leaning towards a separate async notification system
>> for open/mtime change/close which will be a fire and forget notification
>> system with no access control mechanism.
>>
>> A second, although very similar, mechanism will block on read/mmap
>> (although I'm not so sure how to handle O_NONBLOCK without a kernel
>> fastpath/inode marking that actually gets used, this is really a serious
>> design issue with putting this at read/mmap.  I don't think we are ready
>> to give up on O_NONBLOCK for S_ISREG altogether just yet are we?) and
>> provide access control.  I also plan to include open() in the
>> blocking/access control based on a /proc tunable.  If applications can't
>> handle EPERM at read/mmap they can get it at open and suffer the
>> perf/blocking hit needlessly on open/stat sequences.
>
> I think these are excellent ideas.
>
> The kernel really does have to keep some record if it's going to do any
> scanning from read() calls, it can't go to userspace each time to check
> if a file is cached.
> (It might be the single open file descriptor that's marked though)

if you say that the hooks are in the kernel then it does make sense to try 
and have the checking of the cached state done in the kernel.

this will mean that the kernel will have to have some way of knowing which 
programs it should block when the check fails and which ones it should let 
go ahead anyway.

> O_NONBLOCK is then handled nicely, and we can avoid ever blocking that
> client process (which given they're trying non-blocking IO is probably
> a good thing).

I don't see how this follows.

David Lang

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[Pavel Machek]

Hi!

> Eric is viewing this through the AV point of view,
>   this means
...
> He is thinking that any ability to avoid doing the scan 
> is a security hole.

That's contrary to the threat model ('it is just a scanner').

(Plus you can't do it. mmap. Of course you can pass viruses between
two cooperating applications... and you can do it through filesystem,
too. And you probably can make un-cooperating network server serve
viruses, as long as the network server uses mmap.)

This is the thing that makes antivirus ugly, its unique to the
antivirus, plus it can't be done. I.e. bad goal.


							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [malware-list] scanner interface proposal was: [TALPA] Intro linux interface for for access scanning

[david]

On Fri, 22 Aug 2008, Pavel Machek wrote:

> To: david@lang.hm
>
>> Eric is viewing this through the AV point of view,
>>   this means
> ...
>> He is thinking that any ability to avoid doing the scan
>> is a security hole.
>
> That's contrary to the threat model ('it is just a scanner').
>
> (Plus you can't do it. mmap. Of course you can pass viruses between
> two cooperating applications... and you can do it through filesystem,
> too. And you probably can make un-cooperating network server serve
> viruses, as long as the network server uses mmap.)

by the way, sendfile and splice will probably also cause grief (or at 
least open-only checks like mmap)

> This is the thing that makes antivirus ugly, its unique to the
> antivirus, plus it can't be done. I.e. bad goal.

the items that I see as the potentially difficult policy decisions

1. when to scan files on access

and the more dificult issue,
2.when to allow access to unscanned files

3. what to do if different scanners disagree with each other


I think Eric's answers would be

1. unless they are already marked as being scanned since rebooting

2. only when a scanner program is doing the access, unless the scanner 
programs all decide differently.

3. only allow access if all scanners agree.


My answers are

1. unless they have already been marked by the current generation of 
scanner signatures

2. depends wildly on the environment. some uses will want to follow Eric's 
very strict policy, others will only want to impose the on-access scanning 
on software expected to be exposed to windows clients, yet others will 
want to scan by default, but exempt programs that don't interpret their 
input (for example 'wc')

I also don't know how the kernel could reliably figure out what program is 
asking for access. I guess you could try to do something with SELinux 
tags, but that makes this system dependant on SELinux, plus since you can 
only have one tag on the program it will potentially double the number if 
unique tags on the system, with a significant complication to the ruleset 
to make each of the tags identical, except for this one function.

3. like #2 depends wildly on the environment and what scanners are in use. 
I could easily see a 'majority vote wins' with three (or more) AV scanners 
in use. I could also see having a checksum based scanner override the 
decision of a heristic based scanner

David Lang

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

[david]

On Tue, 19 Aug 2008, tvrtko.ursulin@sophos.com wrote:

> david@lang.hm wrote on 18/08/2008 18:02:57:
>
>> On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com wrote:
>>
>>> david@lang.hm wrote on 18/08/2008 13:07:47:
>>>
>>>>>> 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
>>>>> outworrying
>>>>>> about race conditions, but this seems like a fairly easy one to
> close
>>>>>
>>>>> I don't think you can use xattrs as some atomic barriers, I suspect
>>> they
>>>>> are suspectible to same race conditions as open-write-read.
>>>>
>>>> this is why it would require kernel support to turn them into atomic
>>>> barriers (and the reason for this item). without kernel support there
> is
>>> a
>>>> race (it's debatable if that race i significant enough to require the
>>>> implementation of kernel support to close it, but that's why I listed
>>>> this)
>>>
>>> Maybe not since there are races with database updates anyway. What
> would
>>> be necessary is a method of clearing the whole xattr namespace on
> fresh
>>> mount to avoid trusting stale data. That I so far don't see how it can
> be
>>> done from userspace safely.
>>
>> you don't need to clear the xattr space, you can get the same effect by
>> having scanners that care increment their generation ID.
>
> Not the most efficient way since generation ID is global while we are
> talking about a single mount/filesystem. So incrementing the generation ID
> causes all filsystems to be rescanned. Also you need additional hooking in
> mount, plus you have a race condition unless you block in mount while you
> do your stuff. And you need to take care about deadlocks.

if this is important enough the generation id could be made per-filesystem 
one if this was important enough. yes you would need hooks in mount 
(including blocking) to be 100% protected

I don't see the deadlock though


>> but this would require some way for them to learn of mounts.
>>
>>> Also problem with read-only mounts comes to mind. Ups, yes, this is a
> big
>>> problem with this scheme in general. We cannot trust xattr namespace
> when
>>> we mount something fresh because it has been potentialy mounted on a
>>> different system, but if it gets mounted read-only we cannot purge
> that
>>> data and we cannot store our scan results. Only option is not to do
> any
>>> scanning.
>>>
>>> This may not be a common usage scenario so it may not be a problem
> though.
>>
>> this is also a policy question, you may _want_ to trust the scanning
> done
>> by a different machine, so it's not always the case that you need to
>> invalidate the scan results when mounting things.
>
> Without additional filesystem/VFS support you won't be able to tell if
> wherever the filesystem was previously mounted had any scanning done. It
> may have been mounted on a kernel which does not support the whole scheme
> so it didn't clear the namespace for modified files.

if the scan results are stored in xattrs all you have to do is to look for 
them. if they are there then scanning was done.

and no, you can't ever be 100% sure that the scanning tags were implmented 
correctly on another machine, so some people will choose to not trust 
them, but other people will choose to trust them. this is a policy 
decision, not somthing that should be baked into the design.

>>>> I don't think this tool should require the use of other tools to
> exempt
>>>> programs from it, and going that way lies madness (there are too many
>>>> combinations of different tools, trying to define all of the possible
>>>> interactions can't work, and saying that you must use SELinux with
> this
>>>> and not any of the other options is going to be a sure way to get a
> lot
>>> of
>>>> people to not use your tools)
>>>
>>> Then there is still a question of who allows some binary to declare
> itself
>>> exempt. If that decision was a mistake, or it gets compromised
> security
>>> will be off. A very powerful mechanism which must not be easily
>>> accessible.  With a good cache your worries go away even without a
> scheme
>>> like this.
>>
>> I disagree. I think the number of binaries on the system that don't need
>
>> the scanning is surprisingly large, many programs just treat files they
>> access as blobs of data and don't try to interpret them. it's only when
>> the file is interpreted or handed to another system that it needs to be
>> scanned.
>
> In a way this is a slighlty different way of moving protection from core
> to the border which means you must enumerate all possible entry/exit
> points and you must not get it wrong.

again, a policy decision. some people will choose to pay the scanning cost 
for all binaries, others will choose to take the risk of getting it wrong 
to avoid paying the scanning cost when it doesn't help them.

>>>>> I think you overcomplicated it both in design and in presentation of
>>> this
>>>>> text. I was not able to follow and absorb all your postings so I am
>>> not
>>>>> sure what apart from single cache point and non-persistent cache you
>>>>> dislike in Eric's proposal?
>>>>
>>>> single cache point, non-persistant cache, inablility to support
> scanners
>>>
>>>> that don't involve enforcement, inability to do preemptive scanning
> of
>>>> changes, inability to have user policy define what priority to put on
>>>> checks, lack of thought of any use other then anti-virus functions.
>>>
>>> So you do have a whole new set of requirements which if agreed on
> someone
>>> will need to implement.
>
> You skipped this bit where I almost asked you if you are willing to get
> your hands dirty with implementing all this? :)

I am willing to help, but my ablity to help is limited. I'm much more of a 
user/tester then I am a kernel/library programmer.

I'm one of the people who would use this (or not use this) on the several 
hundred machines I manage. I see value in having the capability to do the 
scanning/indexing reliably even on machines that don't have windows 
anywhere near them, but an interface that didn't allow for multiple 
scanners and didn't allow for persistant tagging of scan results would be 
of very limited use to me. and if there is no way to have programs bypass 
the scan the performance hit would be crippling so I wouldn't use it on my 
machines.

>>>> yes this is more complicated than a single bit in memory as the flag,
>>> but
>>>> it's also far more flexible.
>>>
>>> True. It would be nice though if we could think of a solution which
> would
>>> not have a in-kernel tag parser. I am mostly worried about performance
>>> because tags would have to be checked on every open/read/whetever and
>>> compared against the policy set from userspace. If I understand
> correctly
>>> how you imagined it. Or if you wanted to go to userspace for all these
>>> decisions then add even more cost for context switching. In later case
> you
>>> would also have some kenrel code dealing with cleaning xattr tags
> which
>>> would not be mentioned anywhere else in the kernel and that sounds a
> bit
>>> like black magic.
>>
>> I don't have an in-kernel tag parser. I have a in-kernel tag clearer,
> but
>> the tag parser is in the userspace library. this also avoids all the
>> context switches that worry you as well.
>
> How is that? Context switches which worry me are the ones which happen
> when for each access to a file we need to go to userspace just to see if
> it has already been scanned. That is why I was more in favour completely
> of in-kernel caching scheme.

you are missing my point. you are saying that there is a context switch 
to go to userspace to check things. I am suggesting that you would never 
leave userspace to go to the kernel until after the check is done. the 
userspace open/read/mmap/etc call would do the checking and only if it 
passed would it make the context switch into the kernel.

>>>>>> are any of the features I list impossible to implement?
>>>>>
>>>>> Serialisation and race condition avoidance using extended attributes
> I
>>>>> think.
>>>>
>>>> why could the kernel not have a command that locked the inode for the
>>>> read, check, write cycle of changing extended attributes? I agree
> (and
>>>> document) that without such support there is a race condition.
>>>
>>> We could but I agree that we probably don't need to. Having this would
> be
>>> very bad for performance.
>>
>> why would this be bad for performance? the atomic version would be a
>> different function that would only be used when marking a file clean,
> and
>> as this locking would only be contended if multiple scanners needed to
>> mark a file clean at the same instance, it will be a very
> low-contention,
>> low-use lock.
>
> Maybe you would need to lock when checking if file is clean to avoid
> races? Don't know, I didn't give this that much thought.

I'm not sure if you need to do this or not, but if you do you can get the 
effect of locking by setting a "I'm working on it" xattr, if the file gets 
dirtied before you get done it will get cleared and when you are finished 
scanning you can check to see if it's still there before marking the file 
as clean.

if you want to be sure there are no race conditions at all in this there 
would be a need for an 'atomic' (as relates to userspace) way to set an 
xattr only if another one was set.

David Lang

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

[David Collier-Brown]

david@lang.hm wrote:
> if you want to be sure there are no race conditions at all in this there 
> would be a need for an 'atomic' (as relates to userspace) way to set an 
> xattr only if another one was set.

Hmmn, such code would rather resemble the O_CREAT|O_EXCL handling in open(2).

--dave
-- 
David Collier-Brown            | Always do right. This will gratify
Sun Microsystems, Toronto      | some people and astonish the rest
davecb@sun.com                 |                      -- Mark Twain
cell: (647) 833-9377, bridge: (877) 385-4099 code: 506 9191#

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

[tvrtko.ursulin]

david@lang.hm wrote on 18/08/2008 18:02:57:

> On Mon, 18 Aug 2008, tvrtko.ursulin@sophos.com wrote:
> 
> > david@lang.hm wrote on 18/08/2008 13:07:47:
> >
> >>>> 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
> >>> outworrying
> >>>> about race conditions, but this seems like a fairly easy one to 
close
> >>>
> >>> I don't think you can use xattrs as some atomic barriers, I suspect
> > they
> >>> are suspectible to same race conditions as open-write-read.
> >>
> >> this is why it would require kernel support to turn them into atomic
> >> barriers (and the reason for this item). without kernel support there 
is
> > a
> >> race (it's debatable if that race i significant enough to require the
> >> implementation of kernel support to close it, but that's why I listed
> >> this)
> >
> > Maybe not since there are races with database updates anyway. What 
would
> > be necessary is a method of clearing the whole xattr namespace on 
fresh
> > mount to avoid trusting stale data. That I so far don't see how it can 
be
> > done from userspace safely.
> 
> you don't need to clear the xattr space, you can get the same effect by 
> having scanners that care increment their generation ID.

Not the most efficient way since generation ID is global while we are 
talking about a single mount/filesystem. So incrementing the generation ID 
causes all filsystems to be rescanned. Also you need additional hooking in 
mount, plus you have a race condition unless you block in mount while you 
do your stuff. And you need to take care about deadlocks.
 
> but this would require some way for them to learn of mounts.
> 
> > Also problem with read-only mounts comes to mind. Ups, yes, this is a 
big
> > problem with this scheme in general. We cannot trust xattr namespace 
when
> > we mount something fresh because it has been potentialy mounted on a
> > different system, but if it gets mounted read-only we cannot purge 
that
> > data and we cannot store our scan results. Only option is not to do 
any
> > scanning.
> >
> > This may not be a common usage scenario so it may not be a problem 
though.
> 
> this is also a policy question, you may _want_ to trust the scanning 
done 
> by a different machine, so it's not always the case that you need to 
> invalidate the scan results when mounting things.

Without additional filesystem/VFS support you won't be able to tell if 
wherever the filesystem was previously mounted had any scanning done. It 
may have been mounted on a kernel which does not support the whole scheme 
so it didn't clear the namespace for modified files.
 
> >> I don't think this tool should require the use of other tools to 
exempt
> >> programs from it, and going that way lies madness (there are too many
> >> combinations of different tools, trying to define all of the possible
> >> interactions can't work, and saying that you must use SELinux with 
this
> >> and not any of the other options is going to be a sure way to get a 
lot
> > of
> >> people to not use your tools)
> >
> > Then there is still a question of who allows some binary to declare 
itself
> > exempt. If that decision was a mistake, or it gets compromised 
security
> > will be off. A very powerful mechanism which must not be easily
> > accessible.  With a good cache your worries go away even without a 
scheme
> > like this.
> 
> I disagree. I think the number of binaries on the system that don't need 

> the scanning is surprisingly large, many programs just treat files they 
> access as blobs of data and don't try to interpret them. it's only when 
> the file is interpreted or handed to another system that it needs to be 
> scanned.

In a way this is a slighlty different way of moving protection from core 
to the border which means you must enumerate all possible entry/exit 
points and you must not get it wrong.
 
> >>> I think you overcomplicated it both in design and in presentation of
> > this
> >>> text. I was not able to follow and absorb all your postings so I am
> > not
> >>> sure what apart from single cache point and non-persistent cache you
> >>> dislike in Eric's proposal?
> >>
> >> single cache point, non-persistant cache, inablility to support 
scanners
> >
> >> that don't involve enforcement, inability to do preemptive scanning 
of
> >> changes, inability to have user policy define what priority to put on
> >> checks, lack of thought of any use other then anti-virus functions.
> >
> > So you do have a whole new set of requirements which if agreed on 
someone
> > will need to implement.

You skipped this bit where I almost asked you if you are willing to get 
your hands dirty with implementing all this? :)

> >> yes this is more complicated than a single bit in memory as the flag,
> > but
> >> it's also far more flexible.
> >
> > True. It would be nice though if we could think of a solution which 
would
> > not have a in-kernel tag parser. I am mostly worried about performance
> > because tags would have to be checked on every open/read/whetever and
> > compared against the policy set from userspace. If I understand 
correctly
> > how you imagined it. Or if you wanted to go to userspace for all these
> > decisions then add even more cost for context switching. In later case 
you
> > would also have some kenrel code dealing with cleaning xattr tags 
which
> > would not be mentioned anywhere else in the kernel and that sounds a 
bit
> > like black magic.
> 
> I don't have an in-kernel tag parser. I have a in-kernel tag clearer, 
but 
> the tag parser is in the userspace library. this also avoids all the 
> context switches that worry you as well.

How is that? Context switches which worry me are the ones which happen 
when for each access to a file we need to go to userspace just to see if 
it has already been scanned. That is why I was more in favour completely 
of in-kernel caching scheme.
 
> >>>> are any of the features I list impossible to implement?
> >>>
> >>> Serialisation and race condition avoidance using extended attributes 
I
> >>> think.
> >>
> >> why could the kernel not have a command that locked the inode for the
> >> read, check, write cycle of changing extended attributes? I agree 
(and
> >> document) that without such support there is a race condition.
> >
> > We could but I agree that we probably don't need to. Having this would 
be
> > very bad for performance.
> 
> why would this be bad for performance? the atomic version would be a 
> different function that would only be used when marking a file clean, 
and 
> as this locking would only be contended if multiple scanners needed to 
> mark a file clean at the same instance, it will be a very 
low-contention, 
> low-use lock.

Maybe you would need to lock when checking if file is clean to avoid 
races? Don't know, I didn't give this that much thought.

--
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

[david]

On Mon, 18 Aug 2008, douglas.leeder@sophos.com wrote:

>> David Lang wrote on 18/08/2008 01:58:40:
>>
>>> 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.
>>
>> How does it make sense to have a 'known good' according to 'one-of'
> status
>> while there is a single access point ie. no relationships between access
>
>> triggers and 'known good' authority points?
>>
>> Or in simpler words - A says a file is safe, B says it isn't and in your
>
>> proposal you store both information. Then a time to access the file
> comes
>> and what do you do, allow or deny?
>>
>> Maybe I am missing something but I just don't see how this could work
> and
>> how single 'known good' flag per inode does not work. In the proposed
>> implementation Eric posted we don't have support for multiple scanners
> but
>> it is quite possible to extend it with that. In which case the only
> model
>> that makes sense is that all of them must declare something clean in
> order
>> for it to be marked as clean. More into the implementation details - any
>
>> of those scanners who wants to revoke it's decision (new malware
> database
>> or whatever) just needs to increment the global counter which will cause
>
>> all inodes (but on-demand, as they are accessed) to be rescanned.
>
> I think the case of interest is an AV scanner + an indexing scanner.
>
> The indexing scanner marks a file when it changes, and doesn't want to
> scan it
> until the file changes.
>
> The AV scanner wants to mark as unclean the file every time the AV data is
> updated.
>
> Of course the only reason you need separate caches is for performance -
> when the AV
> cache marker is updated, and the file is accessed you don't want to
> trigger the
> indexing scanner.
>
> I guess you could have similar effects for two AV scanners:
> AV1 is a white-list scanner
> AV2 is a black-list scanner
>
> AV1 only scans on execution, and only changes its mind when the user
> explicitly allows an executable
> AV2 is updated hourly, and can change its mind after any update
>
> With a single cache marker: AV1 has to scan each execution after every
> hourly update of AV2
>
> With multiple cache markers: AV1 only scans new executables, or all
> executions after an explicit allow

it gets even worse if you have more scanners.

you may have a OS package manager scanner that knows the checksums of the 
files that were installed via packages,plus you may have multiple 
anti-virus scanners (people want to try and run more then one so that what 
one misses another may catch), plus a HIDS scanner to check that config 
files haven't changed (seperate from the package manager scanner)

then you can add on top of this one or more indexers.

you don't want to run all of these just becouse you updated one of them.

and if you subscribe to multiple anti-virus scanner updates, they are not 
going to be in sync with each other, so one may update at noon (triggering 
a full rescan), and another at 12:30 (triggering another)

David Lang

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

[douglas.leeder]

malware-list-bounces@dmesg.printk.net wrote on 2008-08-18 11:15:21:

> David Lang wrote on 18/08/2008 01:58:40:
> 
> > 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.
> 
> How does it make sense to have a 'known good' according to 'one-of' 
status 
> while there is a single access point ie. no relationships between access 

> triggers and 'known good' authority points?
> 
> Or in simpler words - A says a file is safe, B says it isn't and in your 

> proposal you store both information. Then a time to access the file 
comes 
> and what do you do, allow or deny?
> 
> Maybe I am missing something but I just don't see how this could work 
and 
> how single 'known good' flag per inode does not work. In the proposed 
> implementation Eric posted we don't have support for multiple scanners 
but 
> it is quite possible to extend it with that. In which case the only 
model 
> that makes sense is that all of them must declare something clean in 
order 
> for it to be marked as clean. More into the implementation details - any 

> of those scanners who wants to revoke it's decision (new malware 
database 
> or whatever) just needs to increment the global counter which will cause 

> all inodes (but on-demand, as they are accessed) to be rescanned.

I think the case of interest is an AV scanner + an indexing scanner.

The indexing scanner marks a file when it changes, and doesn't want to 
scan it 
until the file changes.

The AV scanner wants to mark as unclean the file every time the AV data is 
updated.

Of course the only reason you need separate caches is for performance - 
when the AV 
cache marker is updated, and the file is accessed you don't want to 
trigger the 
indexing scanner.

I guess you could have similar effects for two AV scanners:
AV1 is a white-list scanner
AV2 is a black-list scanner

AV1 only scans on execution, and only changes its mind when the user 
explicitly allows an executable
AV2 is updated hourly, and can change its mind after any update

With a single cache marker: AV1 has to scan each execution after every 
hourly update of AV2

With multiple cache markers: AV1 only scans new executables, or all 
executions after an explicit allow

-- 
Douglas Leeder

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.