Please contact me privately or (preferably the list) for questions,

comments, discussions, flames, names, or anything.  I'll do complete

rewrites of the patches if someone tells me how they don't meet their

needs or how they can be done better.  I'm here to try to bridge the

needs (and wants) of the anti-malware vendors with the technical

realities of the kernel.  So everyone feel free to throw in your two

cents and I'll try to reconcile it all.  These 5 patches are part 1.

help with performance for those who actually have userspace scanners but

also could presents be implemented using this framework.
Background

++++++++++

There is a consensus in the security industry that protecting against

malicious files (viruses, root kits, spyware, ad-ware, ...) by the way

of so-called on-access scanning is usable and reasonable approach.

Currently the Linux kernel does not offer a completely suitable

interface to implement such security solutions.  Present solutions

involve overwriting function pointers in the LSM, in filesystem

operations, in the sycall table, and other fragile hacks.  The purpose

of this project is to create a fast, clean interface for userspace

programs to look for malware when files are accessed.  This malware may

be ultimately intended for this or some other Linux machine or may be

malware intended to attack a host running a different operating system

and is merely in transit across the Linux server.  Since there are

almost an infinite number of ways in which information can enter and

exit a server it is not seen as reasonable to move these checks to all

the applications at the boundary (MTA, NFS, CIFS, SSH, rsync, et al.) to

look for such malware on at the border.
For this Linux kernel interface speed is of particular interest for

those who have it compiled into the kernel but have no userspace client.

There must be no measurable performance hit to just compiling this into

the kernel.
Security vendors, Linux distributors and other interested parties have

come to...
[ message continues ]

A long time ago the FUSE developers said something about implementing

write-through stacking for FUSE (i.e. 'sudo fusermount -o allow_other

encfs / /' would allow mounting on /, and encfs could read/write under

its own mount point).
Wouldn't that make more sense?  You could i.e. edit /etc/avfs.conf to

say "scanner=clamscan" "clamscan=/usr/bin/clamscan" and mount avfs

on /...?
--

Actually local disk file systems can be changed invisibly to the VFS too by

directly writing to the block device. This does not change the

page cache, but the on disk copy and when a page is pruned from

RAM and reloaded VFS will see the new contents without knowing

about any change. How would you stop that in your

proposal? I assume you could always require a special LKM that

forbids block writes for anything mounted, but that has other problems

too and one wuld need to be extremly careful of holes in

such a protection scheme (e.g. overlapping partitions) 
[haven't read the rest of the proposal]
-Andi
--

I didn't consider it.  Most likely at the end of the day the finding

will be, "if you can write directly to the block device you already won

since there as so many other things you can do to subvert the system."
Admittedly its the first technical point brought up on list that I

didn't consider at all (lots of other things brought up on list that

need more thought that weren't exactly technical details, don't let me

seem like I'm downplaying those)
-Eric
--

This means your scheme is not generally supposed to protect against root? 
I assume yes (since I can think of lots of other holes for

root), but you should state that explicitely in the spec since it

is a major limitation.
On the other hand it will also allow you to optimize significantly:
In particularly it also means that you can trust the permissions

and don't need to check any files which cannot be written by users

you don't control.
-Andi
--

Can you point to any helpful explanations of that concensus?
Off-hand it's surprising.  (A defense that depends on cataloging every

possible individual attack sounds difficult!)
--b.

--

I can't, but everyone is doing it so that is at least an implied 
Maybe it is not how you imagine it? It is not a database of every possible

individual attack but there are more intelligent methods. But I am not an

expert in this field to explain it better..
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

I suspect that what people actually want is a requirement of what it is

they are trying to do. Not a list of demands on the kernel that they think

are needed to implement what they think is the right way to solve some
This is practically impossible to do completely without rewriting a lot

of code (which will never be accepted). I don't see why it is needed though

as the filesystem cache is supposed to be kept coherent with disk.

--

Problem is with network filesystems. So could it be a flag somewhere per

filesystem which would say something like "this filesystem guarantees

content of a file cannot change without get_write_access or

file_update_time being called locally"? That doesn't sound like a lot of

code so what am I missing?
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

Maybe... but that's not the same as what requirement 5 calls for.
But depending on exactly what semantics you really call for, it can get

tricky to account for all of pagecache. Writes can happen through page

tables or get_user_pages. True that a process has to at some point have

write permission to the file, but the cache itself could be modified

even after the file is closed and all mmaps disappear.

--

I see what you mean, it should have been worded better. Nevertheless that

is what was intended by it - to enable caching only on filesystems where 
I don't have a very good understanding of the VM subsystem I must admit.

So in other words with the current kernel file modification time is not

necessarily correct - it represents when the file was last opened for

modification, not when it was actually modified? (While those two points

in time can be arbitrarily separated)
How would I use those methods for file modification? I am curious to make

a test case..
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

That is exactly what you cannot do. Otherwise you have to rewrite

filesystems not to use the pagecache, and probably have to do disallow

or do some horrible hacks to support mmap.
The requirement you actually intend is more like what you said before,
It is a best effort thing. When you start mmapping, that allows

get_user_pages, which in turn may be able to take pages and modify
Even just with mmap (we do a much better job of it now, but) you

can probably write to a file after mtime if you write to already

dirty pages.
--

--

If we had stackable LSMs then the required functionality could simply be

built into the LSM interface. Then the anti-malware would simply stack

itself with other LSMs. In my opinion this is a perfect example for the

argument of stackable LSMs. So far we mainly have LSMs which provide an

extra access control mechanism (in addition to DAC). IMHO, Ideally DAC

could be another stackable LSM (enabled by default). Other security

schemes such as intrusion detection, firewalls/netfilter, anti-malware,

and application restrictions (sandboxes such as jails or finer grained

restrictions such as AppArmor) could all register LSMs onto the stack.
Additional infrastructure would be necessary. Permissible security

remains a item of contention. Perhaps I am naive but I think most LSMs

could work based on accept/reject. Where every LSM must accept an action

in order for it to be carried out.
MHO,
Cliffe.
--

Could it really?  How would such an interface work?
Remember, the big issue here isn't the kernel "hooks", but the fact that

a lot of people are yet to be convinced that something like this needs

to be within the kernel itself.
Perhaps we should dig up the proposals for the filesystem-notify type

patches, something like that might be all the majority of the virus

people need, as they want to just scan things for Windows viruses, not

Linux ones, and to do so "lazily" might be sufficient.
thanks,
greg k-h

--

The key difference between a lazy scan and an active intervention is tiny

- the ability to block in the security decision to open a file.
Once you have that bit you have the ability to hand the file handle up to

a daemon to chew on and return a status. The same co-incidentally gives

you the hooks for doing various kinds of HSM as you can block an open

while you retrieve the archived content from wherever it was warehoused.
Alan

--

From memory Dazuko is a LSM designed for this purpose, although it

cannot be used on systems running other LSMs due to the lack of stacking

support. It is used by a bunch of anti-malware programs including ClamAV

and AVG.

--

Sorry to say stacking support really does need to be taken with a grain of salt.
Deeper the stack worse the issue of creating system lag.
Anti-malware stacking into LSM adding there own hooks need to be

looked at as more of a problem than a solution.
Lets take a simple example of Dazuko.   It catches all filesystem

accesses and can alter them.   Side effect all protected documents by

the LSM could end up going threw Dazuko so if a flaw is in the anti

virus that can be exploited straight up complete system exposed.
So really LSM stacking is not the correct solution.   More correct

solution would be list out what features malware and virus scanners

need and extend LSM interfaces so the main LSM could control where the

antivirus/malware scanner was accessing.  Yes there are times you

don't want virus scanners or malware scanners seeing everything.
Containers is another issue around stacking.   Containers being added

to Linux are providing more and more controls.  Currently LSM's are

independent to this.   People have responded that it is light weight

virtualisation so dones not need the need to run a different LSM

secuirty construct inside a container.   Its that it is

virtualistation is why it kinda need to.
Now any stacking design of LSM's have to take into account the needs

of containers.
Of course prefered is no stacking for containers and some form of

cross LSM mapping.  Like prime kernel LSM being selinux,  OS contained

being smack so smack secuirty files coveted to selinux with host OS's

limitations applied so container maintains its secuirty.
Same could be applied to chroot's.   This is a common over site of the

current LSM model.   chroot or containers running different

distrobution inside there is no preformated  way of picking up the

secuirty.   Note could even be the same distrubtion different version

just at one point of time they changed secuirty systems.  So user is

running a chroot or a container to run a old application that is

needed.  But now its ru...
[ message continues ]

Stacking is easy for files. It's a real pain in the backside for UDP 
Oh, humility isn't all it's cracked up to be. Show us all up and

write the code. I'm serious, I don't think there's anyone here who

would object to a really good stacking scheme.
--

How is it any better/worse for UDP packets than files?
--

paul moore

linux @ hp

--

On delivery you'd need to decide what security scheme is actually

available on the packet and in what order to interpret any inbound

security data. If you had an MLS scheme that uses CIPSO, an integrity

mechanism using IPSEC and a DAC scheme that assigns user ids by

host address getting the ordering right and every domain registered

properly in the networking stack would be a trick. Plus, making sure

that any state the security scheme requires is tricky. Maybe it's not

actually worse if the schemes agree on what qualifies as a security

element, but if one scheme does access control outbound while another

does inbound it will get hairy.
--

I still don't understand how that is any different from a file or some

other resource, local or remote.  Assuming a single security label

(tag, mark, mode, etc.) on an entity on which you wish to apply an

access control decision the problem boils down to how do you

internalize the security label in such a way that it can be useful for

the security mechanism(s).  In the case of a single LSM you do this

once, in the case of multiple, stacked LSMs you do this multiple times.
With multiple security markings on an entity then you have to decide if

you want to consider every marking at each LSM instance, or a subset.

The complexity in this case does go up dramatically, but I think the

key point for our discussion is that it doesn't matter if the entity is 
Once again, these points apply equally to files as they do to packets.
--

paul moore

linux @ hp

--

Perhaps you're right. I'm thinking in terms of the notion that each

LSM can have an independent file system attribute, but if they all

want to use IP options we're talking about a very limited resource.

No real biggie, I mostly wanted to point out that there's more to

stacking than fetching multiple xattrs.
--

Ah, I'd love to give it a shot but I have this little PhD thesis and

related LSM and tools I need to work on. I just thought I'd put my 5c in.
Cliffe.

--

I don't see anything in the list above that make this a requirement that

the code to do this be placed within the kernel.
What is wrong with doing it in glibc or some other system-wide library
Wonderful, we are going to implement a solution that is known to not

work, with a trivial way around it?
How about the same 64/32bit requirement?  Your implementation is

incorrect otherwise.
(hint, your current patch is also wrong in this area, you should fix

that up...)
And a binary structure?  Ick, are you trying to make it hard for future

expansions and such?
And why not netlink/network socket?  Why a character device?  You are
Is this secondary file handle properly checked for the security issues

involved with such a thing?  What happens if the userspace client does
What happens when the world moves to 128bit or 64bit uids?  (yes, I've

seen proposals for such a thing...)
Why would userspace care about these meta-file things, what does it want
Cute hack.  What's to keep it from racing with the fd changing from the
Heh, so if you want to write a "virus" for Linux, just implement this

flag.  What's to keep a "rogue" program from telling the kernel that all
Why?  What numbers do you have that say the kernel is faster in

implementing this?  This is the first mention of such a requirement, we
I disagree, see above.
thanks,
greg k-h

--

A linux virus would trivially get around that by doing its own syscalls

instead of using glibc. (It might still link dynamically to glibc so

you don't get suspicious, but won' actually use it when doing bad stuff.)
Helge Hafting

--

That's fine, then the file is corrupted.  It is when the "normal"

program goes to load the file that we want to block and determine if we

have a problem or not in the data.
virus scanners are not a security model in the aspect of SELinux or

SMACK.  If they were, they would just use the LSM interface.  virus

scanners are interested in blocking "normal" programs from reading

invalid data from disk before acting on it or executing it.
thanks,
greg k-h

--

they were collected from the comments of Sophos, CA, and McAfee on

malware-list@lists.printk.net back in January 2008.  I can't find the

lists archived on the net so I will post the raw messages tomorrow from
It may be possible to do in glibc, LD_PRELOAD doesn't exactly work for
The model only makes claims about open and I want to be forthright with

its shortcomings.  It sounds rather unreasonable to think that every

time I want to read one bite from a file which is being concurrently

written by another process some virus scanner should have to reread and

validate the entire file.  I think as some point we have to accept the

fact that there is no feasible perfect solution (no you can't do write

time checking since circumventing that is as simple as splitting your
I'm willing to say that opens after (1) are going to be validated.  I am

not certain that all executables opened for write while they are being

executed return ETXTBSY (I do know it happens at least sometimes) so I'm
I'll definitely go back and look, but I think I use bit lengths for

everything in the communication channel so its only endian issues to
As long as the requirement that the first 32 bits be a version it might

make ugly code but any future expansions are easy to deal with.  Read

from userspace, get the first 32 bits, cast the read from userspace to
Opps, old description.  I do just use an inode in securityfs, not a misc

character device.  I'm not clear what netlink would buy here.  I might

be able to make my async close vetting code a little cleaner, but it

would make other things more complex (like registration and actually
I'm not sure the security issues that you are refering too, do you mean

do we make LSM checks and regular DAC checks for the userspace client on

the file in question?  yes.
The userspace client is forced to respond to all fd's it is handed.  If

userspace decided to respond to a request but never close the file the

client will eventually run out of fds and I really should make ...
[ message continues ]

In general this metadata provides more context to the event that happened.

For example reporting - log message/UI popup/centralised something can be

displayed saying which user running which application was involved with

bad stuff. Also we can find out where the user is logged in and send him a

message there.
It is more descriptive than just failing the access with -EACCESS which 
When you don't run an userspace client cache should not come into play

because nothing will be cached (in this iteration at least). So I guess

you meant something different here? Like not running an userspace client

and having the filter disabled (or even not) will produce very little

overhead, probably not observable without micro-benchmarking. Having an

userspace client which just replies with "allow" should have even less

performance impact because most inodes will get cached which means filter

chain will be shorter on subsequent accesses to the same inode.
In either case it will become obvious how huge performance win is to have

in kernel caching once you get the numbers. Let me know if I can help you

with that somehow.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

I share the concern here.  The idea that a piece of malware can exclude

itself seems nasty to me.  I am not an expert on writing malware, but it

intuitively seems to me to be a huge opportunity for creativity.  The

argument that it's ok because anything that the malware writes will

eventually be scanned anyway does not reassure me.
Also...  I was one of the people who brought up the idea of a process

exclusion when the requirements list was being developed.  I intended it

as a way that an AV application could exclude specific OTHER processes

by name (as selected by the AV user) -- not as a way that a process

would exclude itself.  I don't think that the implementation here

reflects this goal, which still seems to me to be a requirement.
Jon Press

CA/HCL Internet Security Business Unit
-----Original Message-----

From: malware-list-bounces@dmesg.printk.net

[mailto:malware-list-bounces@dmesg.printk.net] On Behalf Of Eric Paris

Sent: Monday, August 04, 2008 8:33 PM

To: Greg KH

Cc: linux-kernel@vger.kernel.org; malware-list@lists.printk.net

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface
Processes can only get this flag one of 2 ways.
1) register as a client to make access decisions

2) echo 1 into the magic file to enable the flag for themselves
A process can only set this flag on itself and having this flag only

means that your opens and closes will not be scanned.  And excluded

program could write a virus and it would not be caught on close, but it

would be caught on the next open.
--

There's no fixed process name in Linux that cannot be easily faked: 
Use process name -- every process can change that by writing to its own

environment.

Use comm name -- there's a prctl to change that and there can be collisions

Use path name of binary -- breaks with chroot and name spaces. Also existing

binaries can be subverted.

Use inode of binary -- can be faked with fuse and breaks when the binaries

is copied ...

Use dev, inode -- breaks when copying binary and when running on network

file systems without a device node
-Andi
--

You aren't doing write time scanning anyway.  This exclusion means that

an 'excluded' process can OPEN things that would normally be called

malware.  The model here doesn't talk about adding files with bad

information to the system it talks about stopping that bad information

from being opened and propagated further.  Thread exclusions as they are

written in the patch only weaken security to those processes which

actively choose to read malware, it in no way weakens the security of
Wait wit, you'd rather have a 'privileged' process be allowed to exclude

every other process on a system than have a it only be allowed to

exclude itself? and somehow that is safer?
"by name" is right out the window.  You are never going to win 'by name'

on anything to do with the kernel  :)  Maybe you can get me to

eventually buy into 'by pid' or something like that, but setting flags

on other running processes is always going to be racy and scary for me.

Can you show me some code on how to do this cleanly?  And why it needs

to be done in kernel?
What is the goal you are trying to achieve?  A performance win for the

application in question or is this a security aware application that

needs to be able to access 'sensitive' data?
-Eric
--

Regarding self-exclusion...  We are doing write-time scanning, or more

accurately close-time scanning.  We don't block the close, but we do

scan the file afterwards, and if it is infected, we perform any one of

several actions -- such as report to user, rename, quarantine, delete,

etc.  I would not want a self-excluded executable to be able to write

something that I don't get to scan.
Regarding exclusion by name, etc...  You are right.  I am accustomed to

thinking about our current architecture, which does not involve a

published interface.  I have to adjust my thinking.  Putting such a

feature into the kernel would not be a good idea.  We can handle it in

user space.
Jon
-----Original Message-----

From: Eric Paris [mailto:eparis@redhat.com]

Sent: Tuesday, August 05, 2008 10:57 AM

To: Press, Jonathan

Cc: Greg KH; linux-kernel@vger.kernel.org; malware-list@lists.printk.net

Subject: RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux

interfaceforon access scanning
You aren't doing write time scanning anyway.  This exclusion means that

an 'excluded' process can OPEN things that would normally be called

malware.  The model here doesn't talk about adding files with bad

information to the system it talks about stopping that bad information

from being opened and propagated further.  Thread exclusions as they are

written in the patch only weaken security to those processes which

actively choose to read malware, it in no way weakens the security of
Wait wit, you'd rather have a 'privileged' process be allowed to exclude

every other process on a system than have a it only be allowed to

exclude itself? and somehow that is safer?
"by name" is right out the window.  You are never going to win 'by name'

on anything to do with the kernel  :)  Maybe you can get me to

eventually buy into 'by pid' or something like that, but setting flags

on other running processes is always going to be racy and scary for me.

Can you show me some code on how to do this cleanly?  And why it ne...
[ message continues ]

With the current implementation there are 2 ways to be excluded.  Both

require root and I plan on both requiring the access to pass a

newfangled LSM hook or maybe just require CAP_RAWIO.  LSM people have

thoughts?
Method #1)  Become a client listening for access decisions, basically

just open /security/talpa/client/talpa-client and you are free of

open/close scans.  We have to make the scanner itself not cause its own

opens and closes to need scanned, think infinite recursion.
Method #2) Exclude yourself.  This involves

opening /security/talpa/exclude/talpa-exclude and writing "1" into it.

this file is owned by root and is 600.  Regular user processes cannot

exclude themselves willy nilly nor can any configuration exclude them.

It might be possible to do exclusions in userspace using the pid and

non-caching results for things other than the scanning clients

themselves.
If you can outline the design of a better method that meets your needs

I'd be glad to try to code it.  In your mind how do you see programs

being able to exclude others while not being a security risk?  I assume

your answer is that the program "giving out the exclusions" must be

root, which we already satisfy.  There is (or could be, I don't remember

offhand) the option to disable thread exclusions in kernel (except for

those threads that act as userspace clients, they MUST be excluded

somehow).  But really as it stands any root process could just enable

them again.  In the non-LSM case root processes already won so, they can

just disable the whole infrastructure send kill -9 to all your clients

and have at it.....
-Eric
--

On Tue, 05 Aug 2008 13:19:56 -0400
ok so lets be specific.

You are trying to prevent an application from opening a "damaged" file,

or from someone starting a "damaged" file.

You are not trying to prevent anything once you have executed a damaged

file; once you execute one of these for this part it's game over (to

limit the damage other tools like selinux exist, but are outside the

scope of talpa).
So... as long as /sbin/init isn't compromised... intercepting exec and

open (in all variants) is all you need.
And this can be done from userland with the preload: the "workaround"

from the preload assumes you've already executed malicious code, which

is outside of your protection scope.
What am I missing?
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

I'm not sure if this is off the direct idea of this thread, or if I am

possibly missing the whole point.
However, I want to point out that scanning on close is still an integral

part of AV protection, even if intercepting opens and execs

theoretically catches everything.
You can say that there are four parts to the malware life cycle --

getting on a machine, residing there, causing local damage, and

propagating elsewhere.  It is part of the philosophy of AV protection

that you do everything you can to prevent all of them.  That's why there

are scans on close, scheduled scans, and scans on open.  Most of our

users employ all three and do not rely on one or two.  If an infection

arrives on a machine and finds a home because it is assumed that it will

be caught when it is opened for use, then it is just one more compromise

away from doing damage and/or spreading.
Jon Press
-----Original Message-----

From: Arjan van de Ven [mailto:arjan@infradead.org]

Sent: Tuesday, August 05, 2008 1:39 PM

To: Eric Paris

Cc: Press, Jonathan; Greg KH; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux

interfaceforon access scanning
On Tue, 05 Aug 2008 13:19:56 -0400
ok so lets be specific.

You are trying to prevent an application from opening a "damaged" file,

or from someone starting a "damaged" file.

You are not trying to prevent anything once you have executed a damaged

file; once you execute one of these for this part it's game over (to

limit the damage other tools like selinux exist, but are outside the

scope of talpa).
So... as long as /sbin/init isn't compromised... intercepting exec and

open (in all variants) is all you need.
And this can be done from userland with the preload: the "workaround"

from the preload assumes you've already executed malicious code, which

is outside of your protection scope.
What am I missing?
--

If you want to reach me at my...
[ message continues ]

On Tue, 5 Aug 2008 14:04:26 -0400
We're getting close.
What exactly are the threat models you want to protect against?
Once we have the answer to that question, we can figure out

whether the current patch set addresses the threat model or

whether alternate approaches are needed.
--

All rights reversed.

--

Alas, we've been here before.
http://article.gmane.org/gmane.linux.kernel/608634
  On Thu, 29 Nov 2007, Al Viro wrote:
  > Incidentally, I would really love to see the threat profile we are

  > talking about.  
  Exactly.
  Please come up with a set of requirements that can be reviewed by the

  core kernel folk, and perhaps then focus on how to meet those requirements

  once they have been accepted.
To be very clear, so we don't waste any _more_ time and effort on this: 
The anti-malware folk need to first provide a clearly understandable and

complete description of the problem including a characterization of the

threat.
The next step is to propose a design which addresses the problem, and to

clearly and completely demonstrate how it does so.
Only then will it be possible to conduct an informed discussion on the

underlying case for malware scanning and its possible implementation.
- James

--

James Morris

<jmorris@namei.org>

--

On Tue, 5 Aug 2008 14:04:26 -0400
but close is... very limited in value. Open is a discrete event

traditionally associated withh permission checks.

Close... not so.  (And if you mmap memory, you can then close the file

and still write to it via the mmap)
Lets ask it differently: what will you do if you find something nasty?

You can't fail the close... so why block for it?

And if you don't block for it... all you would need is an asynchronous

notification... something like... inotify

--

Thankfully my implementation will invalidate that close time check and

caching result.  It does the invalidating the same place we update mtime

and my understanding is that mmap has been updating mtime for quite a

while now.  So again, it might not be perfect, but that situation should

get caught the next time around.  I see close time checking as more of a

performance win and as a way to help close some of the length bad

information could exist than anything since its done in a non-blocking

path.
I think we all agree that open is the most interesting time for scanning

operations, but as Jonathan points out there is some value (even if not
I actually already have an async non-blocking close notification built

in.  Instead of waiting for a userspace response we just queue the close

notification and move along.  When userspace gets around to it scanning

and allow/deny caching can then take place at a later time.
-Eric
--

Open for read is the "traditional" time for scanning, but the

sequence (open for write) -> change -> (time passes or close happens)

is specifically a good time to do content checking, so as to have the

answer to the check available for the open for read.
I'd suggest "read" and "write" are the two cases that are interesting,

and that we've been using 'open" an "close" for a not very good

approximation to them (;-))
--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#

--

On Tue, 05 Aug 2008 14:39:34 -0400
Then isn't the close time check superfluous, since you do the

checks at change time already?
--

All rights reversed.

--

In the patches I posted, "checks" are done at open and close if the

result is not already in the cache.  Every write invalidates the cache

and thus the next open/close will do a "check."
So the longer a process keeps a file open the longer it is susceptible

to "unclean" data existing in that file.
--

You're right...I am not talking about blocking at all -- which may be a

further indication that I am missing the specific point of this thread.
But be that as it may...  I don't want to have to use more than one

interface to get all the events I am interested in.  I want to register

as a client and listen, and get everything I need from the same place.
Also, it seems to me that for my purposes, close is discrete enough.  It

tells me that there is now something out there that should be looked at.
Jon
-----Original Message-----

From: Arjan van de Ven [mailto:arjan@infradead.org]

Sent: Tuesday, August 05, 2008 2:28 PM

To: Press, Jonathan

Cc: Eric Paris; Greg KH; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux

interfaceforon access scanning
On Tue, 5 Aug 2008 14:04:26 -0400
but close is... very limited in value. Open is a discrete event

traditionally associated withh permission checks.

Close... not so.  (And if you mmap memory, you can then close the file

and still write to it via the mmap)
Lets ask it differently: what will you do if you find something nasty?

You can't fail the close... so why block for it?

And if you don't block for it... all you would need is an asynchronous

notification... something like... inotify
--

A: http://en.wikipedia.org/wiki/Top_post

Q: Were do I find info about this thing called top-posting?

A: Because it messes up the order in which people normally read text.

Q: Why is top-posting such a bad thing?
That's an implementation issue, not a requirement.  If it's a
So, if you hook glibc to catch all calls to close, is that sufficient?
thanks,
greg k-h

--

-----Original Message-----

From: Greg KH [mailto:greg@kroah.com]

Sent: Tuesday, August 05, 2008 2:39 PM

To: Press, Jonathan

Cc: Arjan van de Ven; Eric Paris; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a

linuxinterfaceforon access scanning
A: http://en.wikipedia.org/wiki/Top_post

Q: Were do I find info about this thing called top-posting?

A: Because it messes up the order in which people normally read text.

Q: Why is top-posting such a bad thing?
That's an implementation issue, not a requirement.  If it's a

requirement, it sure is a lazy one :)
[JON PRESS]  I wouldn't call it lazy, actually.  It's more like

"economical" or "ergonomic" -- or, dare I say it -- "user-friendly."  In

this case, the users are the AV vendors who will have to write to the

API that will come out of this spec.  We will be more inclined to

appreciate the SDK (for want of a better term) if it covers all the

bases, rather than force us to go elsewhere for some of our

requirements.  When we write SDKs, we try to make sure that our users

at.
So, if you hook glibc to catch all calls to close, is that sufficient?
[JON PRESS]  Let's see...I'm going to use inotify for some events, glibc

for others, and this API for the rest.  Would you really want to write

an application like that?
--

On Tue, 5 Aug 2008 16:15:32 -0400
so you have to do 2 cases:
1) inotify to notice files changing

 (no need to hook glibc for that, and no need to hook close() since you

 already get a notify for the change)
This is to catch the *creation* of "bad" content (say a browser saving a

download or somesuch)
By nature this is asynchronous for both performance and "what could you

do if" reasons.

(but so would the close() scan be, and again please explain how you

deal with write-to-mmap-after-close)
2) A synchronous check on open() or exec()
This is to prevent *use* of "bad" content, either by an application

opening a bad file, or by executing a "bad" program. 
For neither do you need to hook the kernel; ld preload works great for

this. 
This does assume that at some point you have a transition from "ok"

program to the first time you run a "bad" one (via exec or open); and

that you catch it at that point.
I don't yet buy the argument "but what if the virus corrupted your ld

preload", because if it can do that your own virus scanner is also

corrupted.
Can you explain what gap is left after you do these two things?
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Actually, the real question (and the reason why I question the personal

integrity of the people in "AV community" pushing that kind of trash)

is very simple:
Where Is Your Threat Profile?
Various people had been asking for _years_ to define what the hell are you

trying to prevent.  Not only there'd been no coherent answer (and no, this

list of requirements is _not_ that - it's "what kind of hooks do we want"),

you guys seem to be unable to decide whether you expect the malware in

question to be passive or to be actively evading detection with infected

processes running on the host that does scanning.
Moreover, the answer seems to be changing back and forth to suit the needs

of the moment in the argument.  Slightly exaggregated it goes like this:
-- Why don't you do $FOO?

-- Running virus would be able to evade $FOO, of course!

-- No shit, Sherlock; it would also be able to evade much more intrusive $BAR

you are proposing; here's how <obvious evasion method>

-- Oh, but that's not a problem; think of Linux server with Windows clients

and Windows viruses...

--

http://marc.info/?l=linux-security-module&m=121796172212429&w=2
Write after close will invalidate the close time caching decision, but

will still get caught on the next open....
-Eric
--

But realize that you are adding an overhead on us, the kernel community,

to make your life easier.  We are the ones that are taking our time to

review and comment on this code.  We are the ones who will have to live

with this code for forever, and maintain it over the lifetime of linux.

So far, you all have shown no willingness to give anything back to us at

all.
In fact, I'd go so far as to say you have been openly hostile, violating

our copyright and license by shipping closed source kernel modules,

making our users have huge problems when we can not support them if they

happen to have the misfortune of using your product, and creating code

that pokes directly into the kernel in ways we explicily do not want to

have happen (syscall hooking, walking symbol tables, etc.)
So please remember, that you should be the ones going out of your way to

be nice to us, as you are coming from a huge deficit here that you all
Think of it as a way to justify your huge prices :)
thanks,
greg k-h

--

We all? How is that true? I for example wrote some code and am willing to

help maintain it if it gets accepted. And as you describe it, it would be

true for any submission because not all things are usefull for all people,

while everything is baggage for the community. And who is the community? I

thought all who take place in discussions, bug reporting, submitting code,

fixing bugs etc are the community.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

You did?  I didn't see any patches from you here, did I just happen to

miss them?
If Eric's code was based on yours, that's great, but it didn't imply

maintenance, especially as it doesn't look like your original patches

much :)
thanks,
greg k-h

--

First copyrights in all those files are Sophos.  Tvrtko is where the

basis for most of these code came from.  Although ongoing maintenance

has not been discussed, he and Sophos deffinitely get the credit for

working on code.
-Eric
--

As an observer of this thread:
- Some set of requirements suddenly appears out of the void on

  linux-kernel.

- Noone is able and/or willing to exactly describe the problem(s) they

  are trying to solve.
With this status quo the discussion is going nowhere - Linux kernel

development does not work this way.
The aim is not to include this code, but to find the best technical

solution for your problem(s) - no matter whether this will have anything
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Because previously it was said to go away and come back with a clear list

of requirements. And here you make it sound like a negative thing. See 
Hopefully we will get there. Very little time has passed since the

discussion has started, even less considering the time zone difference for 
I completely agree with that. Here I was just pointing out that what Greg

wrote was untrue and exaggerated so not helping the discussion at all.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

The list of requirements you came up with was a very low-level set of

requirements.  This is why Al Viro called it not much better than we

want a bunch of hooks here, here, and here.
What is needed is the high-level set of requirements --- which in the

case of security fixes, really needs to start with a threat model (or

threat models).  See my previous message, where I tried to help you

guys out on this.  There are scenarios such as "The Linux Desktop",

where the Clueless User may be tricked to run random binaries.  Then

there is the "The Linux Fileserver", where users may upload malware

via CIFS, NFS, et. al, but there aren't any Clueless Users to start

the malware running on said Linux Fileserver, etc.  When you do threat

analysis you need to know whether the malware is likely to have

compromised root (superuser) access or not.   Etc.
Low-level requirements are things like "this code must take the

number, multiply by it 7, and add 42".  High-level requirements answer

the question, why the heck are you trying to do this in the first

place?!?
						- Ted

--

Until now the main discussion participant from the AV side is

Jonathan Press.
But the real discussion hasn't even started since the information

required is not available.
And as soon as the information for the real discussion is available all 
cu

Adrian
-- 
       "Is there not promise of rain?" Ling Tan asked suddenly out

        of the darkness. There had been need of rain for many days.

       "Only a promise," Lao Er said.

                                       Pearl S. Buck - Dragon Seed
--

Well, if you insist, but I must state that this mail represents my own opinion

and not my employer's (that's because all the people I could consult with are 
Well, here is one attempt.
A good percentage of an AV product's job is to prevent exploitation of a

security hole in a product before the vendor (assuming the vendor admits it's

bug and not a misuse of the product's features).
Most distribution makers go through a lot of work before releasing an update,

which might take days. Add to this the fact that some users refuse to update

periodically (because one operating system out there shattered the belief in

this practice) and that some of them are willing to pay to not care. This is

reason enough for most AV vendors.
In the present, on the Linux Desktop, this is [still] hypothetical talk and

God help it will remain so. However, if there is one incredibly small chance

that one (new?) type of malware can spread to a large number of users, then

AV vendors will race for creating a solution because there will _definitely_

be people needing help with this (please notice that the IQ scale starts from

zero and not from 130 :) ).
I think this patch is trying to do what dazuko hasn't managed to do (yet): get

into mainline. :)
--

Mihai Donțu

--

On Thu, 7 Aug 2008 03:49:55 +0300
just to get things clear;

you're not talking about preventing the actual exploitation per se

(that would be the job of the various protection technologies) or the

containment (that would be SELinux), but more about detecting the

presence and preventing to (accidental) use of pre-canned, widely used

exploit binaries/files ?
--

I apologize for the late reply. The answer to your question is: yes. I was

planning to write some more on this subject but this is unnecessary now,

because I see [almost] everyone accepted that some kind of antimalware

scanning is needed and are looking for alternative (better) solutions to the

patch that started all this.
Can't wait to see the end result. :)
Thanks,
--

Mihai Donțu

--

On Mon, 11 Aug 2008 16:45:47 +0300
we do still appreciate your description, since I don't think there's a

clear "here's what we really try to protect against" statement yet.
Answering Ted's questions would be a really good start...
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Perhaps I could try: the AV folks are trying to prevent the

execution of either modified normal binaries/files or

specifically exploit binaries/files, by machines for which the

files are executable or interpretable.
  The experience of those communities is predominantly

with DOS/Windows executables and interpretable files, which

they have difficulty generalizing from.
  In principle, they could be targeted at any machine, so any

mechanisms should be applicable to native executables and

interpretables as well as foreign ones.
--dave (who (in)famously wrote a UUCP virus, which warned sysadmins

        if they had bad enough security settings to have run it as root) c-b

--

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#

--

You know, that's actually a very good statement of the model.
I think everyone understands one side of the threat model, that is Linux machines being carriers of infections aimed at other platforms.  There are many ways that such infections can be stored, and many ways in which they can be communicated to the target machines.  There are so many that it would not be effective or efficient for each such transfer application to be able to handle its own malware scanning, which is the short statement of why centralized AV protection with notification assistance from the kernel is appropriate.
So, putting that aside, David's statement is a reasonable summary of the nature of the other side of the model, the native attacks we are trying to protect against.  That is, on any platform, not just Linux, we don't always know ahead of time what kind of attack can be launched and how it would be done.  Experience has shown that no one knows enough about every piece of software on every machine to be able to know ahead of time what vulnerabilities there are that can be exploited.  Therefore, we adopt a methodology that allows us to be fairly general.  The signature matching approach allows us to find the signatures of either specific exploit binaries or corrupted normal binaries that our collection and research activities have identified as malware.
It is true that most of our experience is with DOS and Windows, and that the types of attacks that can be launched there are not easy to generalize to other platforms.  However, that does not mean that non-Windows platforms like Linux are therefore immune, or that we are tilting at windmills to say that we address non-Windows infections.  There are many specific forms of malware on non-Windows platforms that we identify in the same way that we identify them on Windows.
In a sense the reason I have found the question about "threat model" to be so difficult to answer is that the basic unpredictability of the attack makes the answer in essence:  "Anything".  That is, it...
[ message continues ]

No.
Proposed kernel solution did not work -- there still was write

vs. read race. You are right that it is not ok for each application to

do its own malware scanning, but libmalware.so that handles the

scanning seems very reasonable.
And as applications _need_ to be modified for the write vs. read race

to be solved, libmalware.so looks like a way forward.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Pavel
I am not sure what you are suggesting, and I may have missed the

libmalware proposal (I don't see any mention of that specific idea in

any other message).  However, just to be clear...  At no point did we

suggest that the kernel would do any scanning.  What we have been

interested in is a mechanism that can allow a scanning application to be

notified by the kernel of specific i/o events, for those events to be

blocked by the kernel until a user-space scan is done, and then the

user-space scan sends back allow or deny, at which point the i/o event

returns to the caller -- either success or error.  This is the only way

that malware can be guaranteed of being detected when it is used (for

local application purposes or for transmission to another platform) or

created.  
Also, a solution that requires applications to be modified will not

work, because there is no way that we would be able to get ALL

applications on the machines to be modified in the required ways.  If

ANY applications are not so modified, then you have an unacceptable

malware hole.  The only solution that really works is one that

guarantees that all applications are involved, which is why the kernel

has to be involved in some way.  It's the only centralized authority

that can stick its nose into all of the required activities.
Whether the specific proposal currently on the table handles all the

issues or not is to me a separate point.
Jon Press

--

On Wed, 13 Aug 2008 06:46:46 -0400
this is a very broad statement that ignores the LD_PRELOAD approach,
you don't need to modify applications to make them use a library...
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

LD_PRELOAD does not solve at least knfsd and suid binaries. But we are 
Same is true for a kernel solution. Plus, it also works for those who make

system calls directly, knfsd and suid binaries, and we can have cheap and

ultra-efficient caching. Not much kernel code, even less complex kernel

code and unmeasurable impact when not used and compiled in. What are the

big technical objections to that?
--

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

Yes, there are about 5 suid binaries on typical linux system. Link
That is does not work?
(Neither does LD_PRELOAD; it still has the old mmap problem. Too bad,

but at least you get 99.9% coverage of all the apps).

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

And knfsd ?
Oh yes you don't seem to have an answer just manure to throw

--

I think I acknowledged inability to handle knfsd... just don't use

knfsd, then. Its not like nfs is critical for communicating with

Windows, right?
That is still better than proposed solution here -- TALPA breaks with

mmap, or when someone does read too soon after write. 
Marketing "antivirus" system that is racy be design seems to deserve

some manure.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

On Wed, 13 Aug 2008 15:16:12 +0100
the biggest objection is the lack of security model description.

STILL nobody has answered Ted's questions.
And still the AV side of the argument keeps making circular arguments.
I'm not saying the kernel shouldn't be involved at all.

I can totally see a solution where we have a

sys_virus_scan(int fd)

that glibc calls at appropriate places (say every read() and mmap())

and that on the kernel side uses a cache to store which virus signature

version it was last scanned with, and if not new enough.. punts to some

userspace scanner for vetting.
but first someone needs to answer Ted's very basic questions or the

TALPA side really does look like a donkey in this argument.
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

I think that the english saying is "It takes two to tangle". As much as I

am "guilty" for stepping out on Pavel's dejavu comments while at this

stage I agree we should be making a more coherent and systematic threat

model, you also haven't really contributed anything new and constructive

by jumping into my (or was it Jonathans?) reply to him. So I disagree that

"AV side" is the only side making circular argument and looking as a

donkey (thanks), especially in todays exchange.
So lets finish this thread now and hopefully we will have something real

to discuss soon.
--

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

As I said, that does not work. Proposed solution blocked open, while

you'd have to block read() and you still could not handle mmap.
So you make sure all apps are modified. Distros are good at that, and

modifications are not that hard.
Plus, proposed solution already has three unacceptable holes:
1) it only catches known signatures
2) write vs. read race mentioned above
3) mmap problem
. Making sure all apps use libmalware.so is trivial compared to

solving 3).
							Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

On Wed, 13 Aug 2008 14:56:38 +0200
the other thing is.. all applications ALREADY use such a library. It's

called "glibc".
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Pavel Machek wrote on 13/08/2008 13:56:38:
Discussions about perfect, better or no security are in danger of becoming 
You haven't answered what exactly is this libmalware.so, since you are the

only one mentioning it? It would be interesting to learn how it solves the

mmap problem, provides perfect security so it is acceptable, handles the

kernel NFS server serving malicious files, caters for applications which

do not use it, is better (more secure) than the kernel solution, provides

reasonalbe performance and is easier to maintain for the community? To

list only some of the requirements which have been mentioned so far.
--

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

Hi!
Okay, so goal of libmalware.so is to "not allow data in the black list

to pass through Linux server". Threat model is windows machines trying

to copy infected files through the server. Viruses are not expected to
mmap problem: libmalware.so would not offer mmap() to applications (or

maybe it would do copy of the file, then allow mmap on the copy).
kernel NFS server is not handled; don't use it for serving Windows

clients. Not that you need performance for that, anyway.
Obviously libmalware.so will not help applications not using it. With

distributions, that's not a problem.
Unlike kernel solution, it does not contain races with read/write/mmap

-- untrusted files access is made through methods that can be safe.
You can query helper daemon for cache info; that should provide good

enough performance.
I never claimed it is easier to maintain than kernel solution; but

unlike kernel solution it actually _works_, 100% of time, for apps

using it.

								Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

Again that's a big condition.
Jon Press

--

Yes, that's the part libmalware.so proposal solves. Given scary number
Yep, so... why don't you propose something better? I'm pretty sure

100% reliable scanning is impossible without modifying applications,

but hey, you can prove me wrong.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

On Fri, 15 Aug 2008 00:39:18 +0200
If you're trolling, you're not being very good at it.
Just because you cannot easily infect a Linux system from a

user application does not mean malware cannot do all kinds

of damage with user privileges.  Think of a key sniffer (using

the same interface that the X screensavers use) or a spam bot

running with user privileges.
Firefox, OpenOffice.org and other (mostly desktop) programs are

extremely large and complex, deal with untrusted data on a daily

basis and could be used to spread worms and get malware onto systems.
The old DOS model of "you need to infect system binaries" is not

a good description of how today's malware works.  Malware is not

there to infect a system "as much as possible", but to accomplish

actual malice.
Consequently, the number of acceptable attack vectors on a system

is pretty large and we should protect against these kinds of

programs.
It would be good to get this additional layer of protection against

malware in place, before people start developing Linux malware.
--

All rights reversed.

--

But Pavel is raising a good question.  In Eric's proposed threat

model, he claimed the only thing that he was trying to solve was

"scanning".  Just file scanning.  That implies no root privileges, but

it also implied that he wasn't worried about malware running with user

privileges, either.  Presumbly, that would be caught and stopped by

the file scanner before the malware had a chance to run; that is the

execve(2) system call would also be blocked until the executable was

scanned.
So if that is the threat model, then the only thing libmalware.so

doesn't solve is knfsd access, and it should be evaluated on that

basis.  If the threat model *does* include malware which is **not**

caught by the AV scanner, and is running with user privileges, then

there are a whole host of other attacks that we have to worry about.

So let's be real clear, up front, what the threat model is, and avoid

changing the model around to rule out solutions that don't fit the

initially preconceived one.  That's how you get to the TSA

confiscating water bottles in airport security lines.
	     	   	      	      	       - Ted

--

And static binaries, and other kernel modular file I/O done on behalf of

applications, and making a library work well which is *hard*, and

labelling and scalability, and sharing a cache between users, and

aggregating events across processes .. and a few other things.
I don't think this is useful. I don't actually care what the virus folks

want to implement. I would rather see useful general purpose interfaces

that are practical and make sense. I cdon't really care whether people

use the write() system call to do sensible or dumb things. What we should

care about is the write syscall.
There seem so far to be two independent requests
* Noticing a file has recently changed, possibly with information about

changes and possibly being able to aggregate/time that for scalability.

This has a need to be able to accurately reference which file. This is

needed for good content indexing, and virus people want it for certain

kinds of scanning (post write, background etc). Doing this solely as a

final close notifier seems to be insufficient (as it may never close).
* Being able to pause an open pending some action. Examples include HSM

and dubiously some kinds of virus check. Problems here include the fact

it can only meaningfully be done for first open (which is fine for HSM)

and that the notion of an exclusive open, or of repeated clearly defined

open/read-write/close/done sequences are actually quite foreign to Unix

like systems.
We shouldn't need to care what people do with good interface. What

matters is in your airport example is that at the infrastructure level

there is a point you can choose to do scanning and we agree where.

Whether people use this to provide a Starbucks or goons with rubber

gloves who take away babies milk is an application layer problem.
Alan

--

Well, I believe libmalware.so works with threat model I described; of

course it will not protect statically linked sambad (unless you

statically link it with libmalware.so, which you should do). I'm not

actually advocating LD_PRELOAD. There are enough userspace nfsds

around, but yes, you can't use libmalware.so with knfsd. 
[You could do something like fuse filesystem linked with libmalware,

and make knfsd export that, and put applications you can't link with
Do HSMs really get implemented like that? I'd expect HSM to be

something like fuse or unionfs... and when it is confined to one

filesystem, you can use existing solutions.
I don't like blocking at open at all, and I don't think blocking at

open is enough for antivirus scanner.

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

If it's a good interface that also happens to address HSM/DMAPI

functionality, as well as a more efficient way for trackerd to work, I

agree completely.  I think you will agree the proposed TALPA interface

is a bit too virus-scanner specific, though?  Especially with explicit

talk of specialized (persistent or not) "clean/dirty/infected" bits

that the kernel would store in the inode for the benefit of the AV

scanner?  That's rather optimized for the goons-with-rubber-gloves

that-make-mothers-drink-their-own-breast-to-prove-it's-not-explosives

crowd, I think...
       	     	      	  	    		   - Ted

--

An interesting example is (please don't scream everyone -- it's just an

illustration of one approach to the problem) NetWare.  (In fact, we

still have a lot of active NetWare customers, so the fact that it is an

archaic OS is not really the issue.)  NetWare takes the kitchen-sink

approach.  It has an interface that allows notification on a whole host

of i/o events, way more than we have ever found useful, and the

application can register for the ones it wants and go from there.  The

kernel does not care what the application's inherent logic is, as long

as the application passes control back with some appropriate return

information (in other words, allow or deny in the context of malware)

within a reasonable amount of time.  I have no idea what purpose it was

written for originally, and there are flaws to be sure, but I know that
That may just be a question of terminology.  If the bits are construed

not as clean/dirty/infected, but as "I care about this file" vs. "I

don't care about this file" then the rubber gloves come off.
Jon Press
--

Sure, as long as we're very clear about the semantics of the bits.  If

the bits are not persistent, but which get dropped if the inode is

every evicted from memory, and it's considered OK, or even desirable,

to rescan the file when it is brought back into memory, that may be

acceptable to the rubber gloves folks (make people go through lots

superflous of security scans, even when they are transfering betewen

flights --- security is always more important than passengers'

convenience!), but perhaps not to other applications such as file

indexers, who would view rescanning files that have already been

scanned, and not have been modified, as a waste of time, battery, CPU

and disk bandwidth, etc.
As I understand it, the TALPA proposal had non-persistent

clean/dirty/infected bits.
						- Ted

--

Yes the current proposal has temporary markers in the in-memory

representation if inodes.
This is a problem for current anti-malware scanning, as virus data updates

come every few hours

(at which point the entire clean/infected state has to be cleared), so the

loss after a reboot is

limited.
--

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

Every few hours?!?  I hadn't noticed Windows AV programs getting

updates that frequently, at least not the ones that I've been familiar

with.  (Semantec, Norton, McAfee)
						- Ted

--

Try running a mail server that provides virus scanning for a large population

of 100K or so mailboxes.  You end up pulling from your vendor on an hourly

basis, just because a virus on a burn through your userbase can toast you that

quickly.
Since 9AM Sunday (is now 11:30AM Friday as I write this), we've pulled new

signatures 33 times (one new signature each time in this case) from our vendor.

So yeah, about once every 3-4 hours we get a new updated one for a new variant

of whatever.  I've seen times when we've pulled a new signature file 3 hours in

a row, and each time there were 10-12 new variants, so averaging 12/hour...

From one of our Linux machines that configured to update normally:

Fri 15 Aug 2008 15:02:23 BST

Fri 15 Aug 2008 12:52:19 BST

Fri 15 Aug 2008 08:32:24 BST

Fri 15 Aug 2008 04:12:27 BST

Fri 15 Aug 2008 02:02:23 BST
That was the sort of time period I remember being told -

        but the AV products probably don't make a song and

dance about a small virus data updates so you probably wouldn't notice

them.
--

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

Of course I mean't NOT a problem...
--

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

No, I'm not claiming to protect against running processes.  I'll leave

that for SELinux.
I haven't seen this supposed libmalware.so so take anything I say with a

grain of sand.  But I take it that the solutions to the problems are

'don't do that.'
aka malware is allowed to flow freely across linux nfs servers.  Great,

I'm sure corperate IT organizations are going to love knowing there

isn't a darn thing they can do to protect their nfs server from being

storage grounds other than hope they can control all of the border.
And I still don't get this 'mmap problem' that I don't solve that

libmalware magically solves.  What?  don't use mmap?  I certainly hope

not.
Are we seriously considering that the right thing to do is to try to

push malware scanning to every project on sourceforge?  At least putting

a solution inside glibc wasn't completely insane, I just think for

numerous reasons we've seen on list for the last 2 weeks not a better

idea.  In any case, having an application have to make special calls to

handle 'untrusted' data is basically like turning the keys to the castle

over on every exploit.  No, I might not make promises about subverted

applications, but that doesn't mean I have to just open all the doors.

And anything that requires explicit application help is just that.  Talk

about theater.
-Eric
--

Don't use mmap, it is as simple as that. AFAICS mmap(MAP_SHARED) --

which is basically shared memory -- is fundamentally incompatible with

reliable virus scanning.
...or do you have a reasonable solution for mmap?

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

mmap has a few different problems
1. intercepting reads and writes to take action at that time
2. the fact that two programs can use it as an inter-process communication

mechanism.
if you are worried about the IPC aspects, all you can do is forbid it,

along with shared memory, pipes, network connections, etc. none of these

provide you with a 'final result' that can be scanned, and as others have

pointed out there are too many ways to do things that get assembled by the

far side to try and catch all malware in them.
as for intercepting reads and writes. the approach I outlined addresses

this by having the kernel mark thefile as dirty if any writes happen, and

checking the file status at the time of doing the mmap instead of trying

to do it when the file is accessed after the mmap.
David Lang

--

...can and will use it as an IPC. So we need to modify some

applications.
Rather than modify all the applications using mmap (you can't tell if

the other side is going to use it for shared memory... right?), we
Can you automatically tell if applications are using mmap for IPC?
BTW in another mail you wanted to include /var/log/syslog from

scanning. You should not be doing that if syslog is exported to

Windows systems. Of course, you can get away with scanning syslog when

Windows client tries to read it, which should be acceptable...

									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

On Mon, 18 Aug 2008 00:58:44 +0200
If web browsers, office suites and mail clients on Windows

have certain kinds of vulnerabilities, it is safe to assume

that the same programs on Linux will have similar problems.
Can we please get rid of the idea that "Windows facing" is

where the whole malware problem is?
As for how to solve it - lets try to come up with a solution

that is reasonably high performance and can be used for more

than just malware scanning.  
Using the same code for things like HSM would be nice.
--

All rights reversed.

--

Don't mix exploits with viruses -- they are different.
Exploit is where application does something very unexpected due to a

bug.
Virus is where machine works correctly, but user does something

stupid.
For exploits, randomization + patching + compartments seem like a

solution. We should be working on "how to confine openoffice.org so

that it can't do much damage" instead of "how to detect .doc documents

that makes openoffice.org do something unexpected".
									Pavel

--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

There is a solution to this whole scanning thing, but I've been

reluctant to suggest it, and it will be pretty obvious why y'all

probably don't want to try it. Just to be sure the options are

out on the table, here goes.
Define an xattr, let's call it "UNSCANNED", which has as its value

a timestamp. A regular file with this attribute cannot be executed

or opened,(exec or open hangs or fails, either behavior has merit

and downsides) and it requires privilege (perhaps CAP_MAC_ADMIN)

to remove the attribute. File creation attaches the attribute. Any

open for write attaches the attribute.
Your scanner runs with privilege (say CAP_MAC_OVERRIDE) and passes

judgment on files with this attribute, removing either the file, if

it is Evil, or the attribute, if it is Good. The scanner is invoked

when a file that was open with write access is closed. This can be

done using mechanisms already discussed on this thread.
If you like, you could use a "SCANNED" attribute instead of an

"UNSCANNED" attribute, and reverse the sense of the test. The

major difference will show up on filesystems that don't support

xattrs. The implications should be obvious.
Now at the beginning I said that you wouldn't like this scheme,

and it shouldn't take a security expert to see the usability problems.

This is how an old school trusted systems junkie (like me) would do

it, and I don't see a better way that would actually achieve the

stated goals. If you wanted you could implement an LSM to do the

labeling bit in a day or two, the notification in about the same

time, which would leave the scanner as the long pole in your

development schedule.
P.S. - Library based security doesn't work.
--

did you read the proposal I wrote up? it's similar to (but more flexible

than) what you are saying
it would allow for multiple 'scanned' tags (to allow for multiple scanning

programs). the kernel would clear the tags when the file is dirtied (not

when it is closed, the file may not be closed for weeks after all), there

is a mechanism to tell the scanner(s) that a file was modified (rather

then having to scan the entire filesystem), and if the scan was not done 
why not? (with the appropriate kernel support)
it actually wouldn't be hard to have the kernel check the xattr, what

would be hard is hving the kernel know when it should then invoke the

scanner(s) and when it shouldn't. This is a policy decision that doesn't

belong in the kernel.
David Lang

--

One xattr, multiple xattrs, all would work. It's simpler to clear the

"scanned" attribute on open than on dirty, a your scheme means looking
I'm old school. I say that all policy decisions regarding objects that

the kernel maintains belong in the kernel. That's why I say that any time

a file is closed with scanned unset (or unscanned set) the scanner should

be invoked or notified. The scanner can choose to ignore or queue the

notification, but the kernel will be done at that point. The kernel have

done all that it can and it's up to the scanner from then on.
--

Because of syscalls  and you don't need to use LD.so to run a program.
Programs can embed there own LD.so and avoid using the system core

one.   This kind of function is being developed for LSB applications

for platforms that don't support LSB.
syscalls you can run programs by passing all .so files and directly

talk to kernel.
Two aways around LD Preloads there are a few more.
Peter Dolding

--

you seem to be disagreeing with the threat model. If so, rather then

arguing agains this implementation of a defense, you need to be arguing

against the threat model.
you are arguing that this solution doesn't work in some conditions. you

are correct, but the threat model that was proposed (and nobody has

proposed any different ones) is not trying to defend against code running

on the system, even if that code is trying to bypass the protection. I

even think that this is a good thing. it allows the distros to use the

protection where appropriate and disable it where it's not (which is a

surprisingly large number of places).
David Lang

--

no, but can you tell at the time of the mmap command if anyone has it

opened for writing? if you can then you can just not allow the mmap in

thid case (policy decision by userspace, as such it can try to look at

what other programs are accessing it via mmap to decide if it should allow 
I listed that as an example of what I would consider a sane policy. by

doing the checking is a userspace library different binaries can be linked

against different libraries by the sysadmin/distro to decide which ones

need to do what checking. there's nothing inherent in the mechanism that

foces the policy in any direction.
David Lang

--

libmalware.so is shorthand for 'have a userspace library do the scanning 
nfs isn't secure anyway so you better control the border.
it's only the kernel nfs daemon that won't use the library, so the answer

is don't use that daemon. I beleive that there is a FUSE NFS option, or if

nothing else, mount a filesystem with FUSE (linked against libmalware.so) 
libmalware can intercept the mmap call and decide to either prohibit it,

copy the file so that the program is operating from it's own copy, or do

something else (all dependant on policy, as defined in userspace for this 
libmalware.so and a modified glibc are not mutually exclusive. you distros

could offer versions of glibc that include libmalware.
again, libmalware.so is not referring to any specific body of code, it's

referring to the concept that the handling of open/mmap/read/etc and

scanning is done via a userspace library rather then by the kernel. if

everyone can agree on that concept then hashing out the details of _which_

library it gets put in is a smaller detail.
this isn't designed to require every app that wants this protection to

have to change it's code.
David lang

--

(snip). Agreed, you explained it better than I would.

								Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

one reason to layer scanners is that you could have one that just checks

to see if the file was deployed from a OS package, if it was (and still

has the same hash as the package manager thinks it should have) it sets a

flag that other scanners could look for (if they see it they can skip

scanning the file)
David Lang

--

actually, instead of trying to have one scanner trust the results of

another, a better approach would be for libmalware to look for the package

manager approval and if it finds that it could skip asking the other

scanners to look at it.
this sort of thing can easily be done in userspace libraries, but you

definantly would _not_ want to do in a kernel-level enforcement mechanism.
David Lang

--

On Thu, 14 Aug 2008 20:43:35 -0400
You bring up a very good point - malware does not need to

be stored on a filesystem in order to run or cause damage.
--

All rights reversed.

--

Being in the correct place is key.   Wrong place more issues more holes.
Lets get this right this time please.  Windows is a mess.   You cannot

run many av products side by side.    Due to failures of signatures at

times to pickup every threat out there we have to move forward with a

system that works.  Supporting many scanners at once if needed.
LIM guys are going after the same kind of defect detection.
Lot of designs have been created over all the years but they have all

failed to address the basics.
Scanning without file caching leaves a hole and costs cpu time.  So

integration into the file system cache system is kinda key.
Designing hooks forcing users to use only 1 product.   Yes good for

market lock in but kicks lots people in teeth.
Getting patch mainline is basically going to hit walls if you don't

sit down and say lets fix the kernel secuirty correctly.   This is not

windows you have the power to alter the complete kernel if you can

provide valid justification for the change.
Valid justification is that someone like me looks at it and cannot

find a flaw in design and it provides needed functionality.  Issue you

keep on addressing only 1 this is the reason why the patches have

stayed out side mainline when other patches have got in.   In theory

the complete core of the Linux kernel could be replaced if Valid

justification could be made.
This is where Linux is different to Windows.   You are free to

redesign linux to be the hardest OS on earth for a virus to operate.

Where windows you have to work with provided model.   Lots here need

to drop the idea that anything in the Linux kernel is set in stone.

Only thing set in stone flawed designed get shot down.
Lets start with what would the features you would wish for as

Anti-virus designers if you could design a OS from scratch around your

Anti-virus so it was almost flawless.   From that list we have what we

need to work on to give you exactly what you want in time.   Even

better post that on a long term we...
[ message continues ]

you're still top-posting!

Please do not do that.. post your comments below the mail like anyone

else does.
On Tue, 5 Aug 2008 14:34:26 -0400
that's your problem to be honest. Worst case you have a small wrapper
inotify tells you that. close does not.

--

A: No.

Q: Should I include quotations after my reply?
I think you might be missing the point a bit here, as the traditional

Unix model that Linux has prevents much of what the "traditional AV"
Great, then put a hook in glibc and catch all closes and then kick off
But this proposed patchset does not do much to prevent all of these,
So how are you going about preventing the "infection from arriving"

with this proposed patchset?
Isn't that something that SELinux or another LSM can prevent better?
thanks,
greg k-h

--

Could you please explain some more what and how do you think Unix model

prevents?
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

It prevents any user from overwriting an existing executable, and it

prevents any user from adding an executable file to a common directory

(/usr/bin).
It also prevents any user from overwriting a different user's data file.
What specific threat model are you feeling is still present on Linux

today that this proposal is supposed to address?
thanks,
greg k-h

--

kill -9

deferred close via mmap

etc etc etc
You can't just armwave it into glibc, that doesn't hold water. You also

have shared state between processes (index on last close of a handle

shared by several threads or processes).
Same problem you have in the indexing business (which also wants the

close hook) - aside from all the practical issues that LD_PRELOAD tends

to turn up.
I'm not actually interested in the AV stuff, but content indexing I do

care about and we do need a way to get notification up to user space.
Alan

--

>> I think you might be missing the point a bit here, as the traditional

do, right?
Is your point that Linux and Unix machines are less vulnerable to

viruses?  If so, that's not relevant to my point at all.  A Unix machine

can be a carrier, passing infections on to other vulnerable platforms

(guess which one).  An enterprise security system sees the entire

enterprise as an integrated whole -- not just individual machines with
I'm not endorsing or opposing the proposal until I digest it further.
However, I will say that while preventing infections from arriving is

not foolproof, doing a scan-on-close with the option to delete or

quarantine an infected file goes a long way.
Jon
-----Original Message-----

From: Greg KH [mailto:greg@kroah.com]

Sent: Tuesday, August 05, 2008 2:12 PM

To: Press, Jonathan

Cc: Arjan van de Ven; Eric Paris; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a

linuxinterfaceforon access scanning
A: No.

Q: Should I include quotations after my reply?
I think you might be missing the point a bit here, as the traditional

Unix model that  Linux has prevents much of what the "traditional AV"
Great, then put a hook in glibc and catch all closes and then kick off
But this proposed patchset does not do much to prevent all of these,
So how are you going about preventing the "infection from arriving" with

this proposed patchset?
Isn't that something that SELinux or another LSM can prevent better?
thanks,
greg k-h
--

On Tue, 5 Aug 2008 14:38:23 -0400
How can you, as a security professional, argue for a security measure

that you know is flawed, when there is a mailing list full of people

willing to help figure out what a working security measure would look

like?
Yes, abandoning some of the old DOS anti-virus security model may

cause work, but surely that will be worth it if it leads to a more

secure system?
--

All rights reversed.

--

-----Original Message-----

From: Rik van Riel [mailto:riel@redhat.com]

Sent: Tuesday, August 05, 2008 8:51 PM

To: Press, Jonathan

Cc: Greg KH; Arjan van de Ven; Eric Paris; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a

linuxinterfaceforon access scanning
On Tue, 5 Aug 2008 14:38:23 -0400
How can you, as a security professional, argue for a security measure

that you know is flawed, when there is a mailing list full of people

willing to help figure out what a working security measure would look

like?
Yes, abandoning some of the old DOS anti-virus security model may cause

work, but surely that will be worth it if it leads to a more secure

system?
[JON PRESS]  I hesitate to join back in the discussion, because so far I

haven't been very successful.  I know that my level of technical depth

is not at all the equal of just about everybody else in this

conversation.  That's not my job and I don't claim to have the answers

to all the questions that are being raised.
However...  This question about arguing for a flawed security technique

is a good one, and in a way it gets to the heart of the philosophy of

security.  Scan-on-close is admittedly incomplete as an anti-virus tool.

But I don't agree that that make it flawed.   It is part of a repertoire

of techniques for preventing malware from residing on a machine.
Let's take a simplistic and unrealistic example.  Let's suppose that you

knew that there were 20 applications on your machine that had buffer

overflow vulnerabilities that could be exploited, and you had a fix for

18 of them.  Would you decide not to apply the fixes, because that meant

that there would still be 2 left -- and because theoretically there is a

way to prevent all buffer overflows from being exploited and there is a

mailing list full of people trying to figure out how to do it.
I think if it as being like the Sieve of Eratosthenes.  The further ...
[ message continues ]

The problem with your example is that it ignores the cost; the cost in

code maintenance; the cost in performance, etc.  That's the problem an

absolutist view towards security.  Going back to the your sparying

analogy, if the illness is considered *so* utterly deadly that you

don't consider the costs of beneficial insects dieing, children

getting exposed so badly that they get cancer five years later,

etc. --- then the argument would be heck, let's spray every day!

Let's spray every hour!  Let's have a insectside misters going 24

hours a day in the parks and in the schools!!!
In the TSA example, let's force every single traveller to strip naked

publically and be submitted to body cavity searches!  Since

**obviously** stopping terrorist bombs is so important that no other

considerations need to be taken into account.  Oh, and we should

obviously also give all of our financial information to the security

agencies so they can do futher screens to look for terrorists; who

cares about the risks that laptops with all of that unencrypted data

will be stolen out of a locked office in the San Francisco airport?
Similarly there are costs to doing all of this extra scanning.  You're

getting carried away here way you say that it never hurts to do extra

scanning, and that we don't need to decide whether or not it makes

sense to do it all.  That's just stupid.  The whole defense in depth,

taken to extremes, leads to completely nonsensical thinking.  Security

is *defintiely* a cost/benefit tradeoff, and to do something

meaningful here we need to think rationally about the threat

environment --- and part of that threat environment is the existing

security systems in Linux, which are definitely far more powerful than

what DOS/Windows have.
							- Ted

--

-----Original Message-----

From: Theodore Tso [mailto:tytso@MIT.EDU]

Sent: Wednesday, August 06, 2008 11:09 AM

To: Press, Jonathan

Cc: Rik van Riel; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org;

Arjan van de Ven

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to

alinuxinterfaceforon access scanning
The problem with your example is that it ignores the cost; the cost in

code maintenance; the cost in performance, etc.  That's the problem an

absolutist view towards security.  Going back to the your sparying

analogy, if the illness is considered *so* utterly deadly that you don't

consider the costs of beneficial insects dieing, children getting

exposed so badly that they get cancer five years later, etc. --- then

the argument would be heck, let's spray every day! Let's spray every

hour!  Let's have a insectside misters going 24 hours a day in the parks

and in the schools!!!
In the TSA example, let's force every single traveller to strip naked

publically and be submitted to body cavity searches!  Since

**obviously** stopping terrorist bombs is so important that no other

considerations need to be taken into account.  Oh, and we should

obviously also give all of our financial information to the security

agencies so they can do futher screens to look for terrorists; who cares

about the risks that laptops with all of that unencrypted data will be

stolen out of a locked office in the San Francisco airport?
Similarly there are costs to doing all of this extra scanning.  You're

getting carried away here way you say that it never hurts to do extra

scanning, and that we don't need to decide whether or not it makes sense

to do it all.  That's just stupid.  The whole defense in depth, taken to

extremes, leads to completely nonsensical thinking.  Security is

*defintiely* a cost/benefit tradeoff, and to do something meaningful

here we need to think rationally about the threat environment --- and

part of that threat environment is the...
[ message continues ]

On Wed, 6 Aug 2008 11:33:23 -0400
Disks are slow and files are getting larger by the day.
We can do a lot better than scanning a whole file.  A mechanism

that can notify programs about what file changed and what byte

range in the file changed can reduce scanning overhead by only

needing to scan the part of the file that changed.
More importantly, getting info on which bytes in a file changed

will also help backup programs and disk indexing programs.
Blocking on open can be useful for more than just anti-virus

scanning.  It can also be useful for hierarchical storage

management or simply for using a filesystem while it is being

restored from backup - an important consideration because

restoring a filesystem from backup can take days with modern

data sizes.
Blocking on exec is similar to blocking on open and useful

in the same scenarios.
What we need to work on is making sure that the interfaces

that go into the kernel are useful not just for anti-virus

programs, but also for other software.
--

All Rights Reversed

--

It is much more advanced than that, really. I don't know if ever a whole

file is read and in 99% it is just a tiny part of it. I don't know what I

am allowed to disclose and also it is not my area of expertise, but if you

are interested in how detection actually works maybe we can talk off list

and put you in touch with some other people here.
It is also wrong to think that you can scan only what has changes because

that bit may be harmless itself but present a final part of a malware 
True, but Nick mentioned some huge issues with access after close and

munmap in one of your previous postings. It sounds to me that would be a 
I definitely agree with that.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

On Wed, 6 Aug 2008 17:12:56 +0100
A universally useful large change is often easier to get into

the Linux kernel than a single-purpose hack.
--

All Rights Reversed

--

Over engineering in a void for some supposed someday user isn't a good

idea either.  If there are other people interested in working together

to come up with a solution to multiple needs I'm here to help!
-Eric
--

On Wed, 6 Aug 2008 08:10:53 -0400
this indeed gets to the heart of the problem.

several of us here are trying to argue that scan-on-close isn't very

good, BUT that if you do scan-on-change (say with inotify) you do reach

the same goal but with much better results.
notice the "but" in there. What I hope will happen is that one or more

people from the AV side (eg you and tvrtko) will actually read the "but"

part rather than just dismissing it outright because of not liking your

solution in the first part of it. Part of the answer could be "nice

however our goal is <THIS> so it won't work because of <THAT>".

At least as long as <THIS> isn't "scan on close" because that's not a

goal, that's a means.
this kind of thing seems to be indicative of the entire discussion.

For lkml proposals, both sides need to be willing to accept alternative

solutions for a problem (I know I am, just need to see why ;-).. and

explain the WHY and the goal if it's not clear.
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Problems with inotify as far as I know:
You can't do something like inotify("/") (made up API) but you have to set

up a watch for every directory you wan't to watch. That seems like a waste

of resources.
Then you get back a file name, if you wan't to report it or attempt* to

scan it you have to build a pathname yourself, which means you have to

maintain the whole tree of names in memory. Even bigger waste.
When I say attempt to scan it above I mean that we are back into the

pathanme teritorry. It is not guaranteed we will be able to open and scan

using that pathname. I don't know what inotify reports with chroots and

private namespaces, but it can certainly fail with NFS and root_squash. So

it is less effective as well as being resource intensive.
I think this is a good amount of flaws which shows inotify isn't really

ideal.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

Not ideal, but looks like good enough, and could certainly be

improved. If it is secure-enough for you (I think it is), that looks

like a way to go.
(Plus, such improvements would actually be very welcome).

									Pavel
--

(english) http://www.livejournal.com/~pavelmachek

(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

--

My Issue API does not have to be made up.  The API kinda exists in

Credentials for a completely different use.
Issue with inotify its only monitoring.   No permission alteration to

block access.
Also its the wrong level.   I will explain why.
inotify is sitting on top of the vfs.   Ok fine if you don't want scan

effectiveness.   With bind mounts this becomes trouble quickly.
/tmp

/usr/tmp

/usr/local/tmp
All could be exactly the same physical drive.   Now in the anti-virus

would have to scan each of thoose directories if it does not find out

they are bind mounted.  Also could not look up and say ok that is bind

mounted its fine because since the last lookup a new bind mount could

have been put over the top letting something slip past.
Also TALPA is wrong because its a LSM.   LSM are the most powerful

bits of the OS.   LSM are the enforcers of Linux.  They are the last

line of defence for the OS.   You have your normal permission systems

when they fail then its the job of a LSM to pick up the mess.
Virus scanning is way better inside the permission system.   This way

if you have a issue there is still a back stop of the LSM to prevent a

breached virus scanner doing major system harm.   TALPA risks killing

the backstop.
Basically path based + Linux equals doomed.  VFS is not path based friendly.
Credentials patch on the other hand.  Is under the VFS sees real

partitions so can process divided by partition avoiding rescanning.

Also its in the permission system to has to get approve from the LSM

to do alterations.  So its back stoped.
Also is sitting at exactly the right point to override permissions.
Filesystem cache that exists to sit on top of Credentials provides the

other needed bit scan on write function.
Also filesystem driver level was also correct.  Same reason not messed

up by VFS multi mounting and over mounting.
Don't worry lots of things have been made as LSM's that should not

been.  Basically avoiding having to correct the right things.
Peter...
[ message continues ]

I've been trying to ignore you, but I just can't any more.  Please dear

god look at my work before spewing this crap.  My work is not an LSM.

My work doesn't care about bind mounts, it cares about inodes.  My work

is not path name based.  I'm not sure who you are trying to convince of

something here but obviously talking about something you don't know

about is not working for you.....
-Eric
--

Path based was to using inotify that basically cannot do the job.   I

guess you agree with that.
Ok you corrected that bit in the TALPA design?   Past form of the

beast was hooking down threw the LSM structs to block files so if

something went wrong it could override all the permissions on the

system without any means of anything else blocking it.  Effectively

killing the system.   Basically the Userspace daemon answering block

everything worked.   Ie connected in too high. So key operational

files of the OS could not be protected against the scanner turning

into malware itself.   Yes users are tricked to install fake

anti-viruses and malware scanners on windows.  So yes something

hostile to the system can and most likely will connect to the TALPA

API.   Is over site to the LSM provided?  Just last time I looked

still missing.
Credentials alterations to permissions must go back threw the LSM.

Also Credentials permission change will not operate without LSM built

into kernel.   Running a Anti-virus without a wrapper around it is

partly foolish anyhow.
There is still the duplication issue.  Two filesystem caches one in

TALPA and One the FS-cache that is designed to sit on top of

Credentials.   TALPA is only a part filesystem cache but caching

approved and not approved is still a form of filesystem cache.  Its

caching virtual permissions of the filesystem.
Also duplication of permission overriding Credentials provides means

to override permissions from userspace as well including creating

virtual permissions like TALPA is doing.  Reason for virtual

permissions simple not all file system support the all the permissions

to run Linux on with LSM's fully active.
Simple fact you have two API doing almost exactly the same thing.

Just different ways.   Credentials spreed all the way threw the OS as

well.
So if in the Credential stuct was added a flag saying what version

virus scan had been done on a running executable a search of running

programs that had not been scanned against...
[ message continues ]

Sound great, looking forward to your patches!
I suggest developing them against:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next-creds
Thanks.
- James

--

James Morris

<jmorris@namei.org>

--

Yes, it would be nice if inotify gave you back a full pathname and

where a single watch would return all changes anywhere in the
Linux's namespace support does break a lot of traditional paradigm.

I'll note the TALPA "requirements" are broken themselves since they

refer to pathnames.
Furthermore, I assume you'll always want to do the scanning in

userspace; the virus signature files for Windows are ***huge***.  And

if you are going to be scanning for Windows virii on the argument that

you want to stop malware on fileservers, I don't think you want to put

all of that code into the kernel.  (I'll note that all that code

complexity leads to bugs, which will in kernel code cause system

crashes.  One company's Linux AV code --- I won't say which --- almost

lead to a rather big and public customer abandoning an Linux

deployment because said proprietary, badly/disastrously written,

kernel code was leaking a small amount of memory on every file open,

and no one could figure out why their file server was crashing every

five days or so.  I was called in to rescue said customer before they

cancelled the contract in disgust, and I traced it back to a

proprietary AV kernel module.  What fun...)
So if we are going to have to deal with namespaces, I suspect the best

we can do for any interface (whether it is inotify based or not) is to

have it return pathnames that are valid in the namespace that the

program calling said interface happens to be running in.  If necessary

the AV program can be given access to a highly privileged namespace

where all mounts are visible.  And if you want to restrict namespaces

from being created at all, that's a security policy decision that

should be made via the LSM hooks.
As far as blocking opens are concerned, my suggestion there would be

changes would probably be much more likely accepted if they solved

more problems than just what the AV folks need.  For example, think

about hierarchical storage management, and DMAPI.  DMAPI is a total

disaster because i...
[ message continues ]

I will have a brief look to familiarise myself with inotify

implementation. So maybe, but even if that solves only one 
Core functionality does not depend on pathnames. I thought that was 
Once upon a time I worked for a different company and we used embedded

linux to drive some custom hardware, rather complex things. On some

customer sites, every week or so the OS would hang. Some free, public and

open kernel GPL code was leaking kernel memory on each USB transaction and

depending on the use it would use up all memory sooner or later. We lost

the customer, but didn't abandon Linux. Instead we helped fix the leak and

if you don't believe me it should be ChangeLogs under my name, something

like five or six years ago.
So what do ours anecdotes prove? Only lack of testing I would say.
Also, that companies from your example bad code would probably be better 
I agree wih the first part and that is how it works.
Pathnames are used for reporting purposes and for possible filesystem

hiearchy exclusions. For reporting it is obviously not critical from

security point of view and the design document showed how we get them.

There is no new code added to do it and it happens from userspace. Such

pathnames are relative to the userspace daemon since they are obtained via

/proc/self/fd/ and readlink. Exclusions use relative paths and that is

also explained in the document.
Therefore access to all namespaces should not be needed except in a way of

getting a file descriptor from another process, possibly from another 
I agree and think we are completely open to this. However the story

reverses in a way that we now don't know what are the requirements for 
Could be, but I think we won't know for sure until everything is fleshed

out.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

On Wed, 6 Aug 2008 15:16:02 +0100
one argument against the namespaces one is that of security; on the one

hand I can see the argument of running the virus scanner in its own

container, on the other hand I can see the argument of not liking
that is a fair list of complaints.. the question is can inotify be

fixed....
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

This buffer overflow risk and other equals are why LSM's exist.   It

put jails around applications so they cannot do any more than they are

meant to.   Its called risk reduction something that is most likely a

new idea to people coming from a windows background.   It also makes

exploiting a flawed applicaiton tricky.  Do something that application

should not normally do it will be blocked and trip the LSM alarm that

could be set to straight up terminate the offending application.   Yes

a true shot on sign of trouble system.  This is what you anti-virus

guys call behaviour monitoring same system some anti-virus software

uses to detect unknown viruses.
So 2 left should never happen since we have at least a part fix for

all of them.   This is how it has to work.   Failure is not a option

in our eyes.   If you have a percent missed that is a failure of there

is not something else to prevent damage.  We are not Windows users

with weak setup systems.   We don't want weak distributions out there.

 Nice if some anti-virus products started demanding a min standard LSM

to run side by side with them.
LSM's are already embedded core system exploitation prevention.
LSM currently don't extend deep enough into users to really tighten

completely down on the Users account.
So far I have not found a exact list of what is needed by AV or

Malware companies that say LSM stacking is needed.  That says stacked

LSM's are needed.
So I will bring a few things to the table.  Number one LSB is working

on a common packaging API using DBUS based off policy kit.   So

malware application installers run in users own account and to install

into the system have to go threw a scan able interface.   So far I

have not seen AV companies there working in improving the design.

Prevention beats cure.
This reduces a issue of malware to the Users own account without heavy

handed scanning.
So scanning becomes reduced to user editable files.
Linux firewall supports user mode modules so antivirus can scan

netwo...
[ message continues ]

-----Original Message-----

From: Peter Dolding [mailto:oiaohm@gmail.com]

Sent: Wednesday, August 06, 2008 8:39 AM

To: Press, Jonathan

Cc: Rik van Riel; Greg KH; Arjan van de Ven; Eric Paris;

linux-kernel@vger.kernel.org; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a

linuxinterfaceforon access scanning
On Wed, Aug 6, 2008 at 10:10 PM, Press, Jonathan <Jonathan.Press@ca.com>

This buffer overflow risk and other equals are why LSM's exist.   It put

jails around applications so they cannot do any more than they are meant

to.   Its called risk reduction something that is most likely a new idea

to people coming from a windows background.   It also makes exploiting a

flawed applicaiton tricky.  Do something that application should not

normally do it will be blocked and trip the LSM alarm that

could be set to straight up terminate the offending application.   Yes a

true shot on sign of trouble system.  This is what you anti-virus guys

call behaviour monitoring same system some anti-virus software uses to

detect unknown viruses.
So 2 left should never happen since we have at least a part fix for all

of them.   This is how it has to work.   Failure is not a option in our

eyes.   If you have a percent missed that is a failure of there is not

something else to prevent damage.  We are not Windows users with weak

setup systems.   We don't want weak distributions out there.  Nice if

some anti-virus products started demanding a min standard LSM to run

side by side with them.
LSM's are already embedded core system exploitation prevention.
LSM currently don't extend deep enough into users to really tighten

completely down on the Users account.
So far I have not found a exact list of what is needed by AV or Malware

companies that say LSM stacking is needed.  That says stacked LSM's are

needed.
So I will bring a few things to the table.  Number one LSB is working on

a common packaging API using DBUS based off policy kit.   So malware

...
[ message continues ]

We are not just kernel.  http://hal.freedesktop.org/docs/PolicyKit/

Is a good read.
Long term Linux design is basically Nuke the root user and protect the

core os providing restricted access.
So anti system core damage integrates outside kernel space.   We are

You got to remember syscall trapping can be done for good and evil.
You use it to monitor actions another use it to do harm like steal data.
We need syscall trapping for debugging.  ptrace and the like.
Something important you are forgetting and its critical.  Windows gets

hell loads of overhead from Anti-Virus products.   Our LSM's already

provide overhead.  Duplication is not a way forwards.
Credentials  IBM patch provides a way to override filesystem

permissions so monitor and scan can be done there.
Tracing improvements lined 2.6.27 could be used to monitor

applications a AV is suspect of.
Capabilities restrict syscalls by blocks.
Question exactly why needing to monitor at the syscall level.   Really

why.   There are ways to monitor and restrict accesses without

dropping to that level.
Most likely the issue is that your models are broken.   Under windows

most anti-viruses copy the methods you would use to root kit a OS to

get there data.   Not working with the existing secuirty model.

Learning to work side by side with the LSM and other systems already

provided anti-virus companies are going to have to learn to do.   No

more of this hooking into the OS to get what you want.
Critical note on Linux.   Rootkits out number viruses and malware 20

to 1.   This is way different to your windows numbers.   So any method

that is Rootkit style will fail in time because that hole will have to

be closed.
My main issue is TALPA, dazuko and so on of Anti-Virus Filesystem

monitoring are all going to break anyhow when

http://lwn.net/Articles/251224/ Credentials get added and common

filesystem caching gets added.
You want to change a permissions on a file/object before its opened.

So does the Credential user s...
[ message continues ]

Peter Dolding wrote:
Then in a real sense you've solved much of their problem for them (;-))

After this comes engineering, so that they can re-use the scanning

mechanisms they already have, but from a different caller.
The requirements are probably that they know

- is this an open for read or write (somewhat less time-sensitive)?

- is the data present, or do we have to wait?

- if so, for what?

as of the time they start looking at the file.  Having a race-free

mechanism using credentials and RCU is, IMHO, A Really Good Thing.
Another thing they and we will likely need is a way to discover

if a file is inacessable due to an AV operation, and if the time

it has been inacessable is less than or equal to a scanning

upper bound by file size or beyond it.  The latter is for repair

of broken state introduced by the AV process failing.
--

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#

--

Failed daemon support has to exist in Credentials for filesystems that

cannot store all the security data and needing third party support.

This is the issue same features basically required to do the same

things.  Different reasons.
One to virus scan.  One to fix up security lacking file systems.  From

what I see exactly the same set of features are needed.
At most only 1 feature is missing a form of copy on write.   Adding

this at credentials level over the complete system would not be a bad

thing.  A option to cache writes for scanning even write to like a

journal for latter applying once scanned.   This could even come as

part of the generic file system cache.
This is why I am kinda scratching my head.   Creating new files also

have to go past Credentials.  Even creating and editing files have to

go past Credentials.
It seams like the best place to look to hook in correctly even better

most of the hook is already there.  Hooking into Credentials is far

better than hooking into syscalls.   Since if a new special feature

filesystem access syscall is added it will still enter Credentials.

On top Credentials interface is under the VFS.  Its between the raw

filesystem and the VFS.   So no more path based errors.
Yes deeper into the OS to the correct location.  Anti-virus methods

are too shallow.  AppArmor and some other secuirty systems like it

have the same path based issue because LSM is too shallow.

Anti-Virus company answer has been to root kit out of the LSM API

wrong answer.  Correct answer is get to the correct location in the

OS.
Note clamfs is on the right path using fuse since this goes under the

VFS and not effected by path issues and is not root kitting the OS.

Of course credentials do the job better.
Really Anti-Virus guys give as a shopping list of exactly what you

need to do.   Key word need.   Hooking syscall's most likely is not a

need but a want.   Even worse a want in the wrong location to give 100

percent coverage.  Ie when a new syscall is added it ...
[ message continues ]

not writing to the syscall table hasn't been possible/allowed for..

about 5 years now. (yes I know there were still bad hacks possible

until 2 years ago). So I'm sorry, but the timeline argument doesn't

hold, you've had 5+ years of warning.
All existing RHEL products already don't allow this (I know it for the

earlier ones since I was part of the design team)...  unless your

software acts entirely like a rootkit (but even then)
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Other options involved overwriting LSM function pointers.  I was told

that recently moving SELinux to be statically compiled in apparently

messed them up on that method, at least for RH products.  The other

method I've heard is hunting down all of the filesystem_operations

structs and overwriting those functions.  I was also told that until

recently pages marked RO could just be marked RW and then remarked RO,

although it was recently fixed to RO pages stayed RO.  So yeah, I'd have

to call them all ugly rootkit like hacks.
they just keep finding uglier and uglier ways to infiltrate the kernel

which is why I was ask to try to help get a clean solution.
-Eric
--

Simplely they are following the windows way of doing things.  Rootkit

the OS no one will stop us.  Sorry that RootKitting is not going to

work here long term because we will fix Root Kit weaknesses.  TPM from

IBM will make it even harder.  Nice bits of that are in 2.6.27.
Allowing LSM stacking solves nothing.   IBM's developers credentials

is a far better place for file system monitoring to hook in.  Its pre

caching allows all the alterations they could want.  Even better

credentials is a required patch to clean up Linux internal permission

splating all over the place.  Then generic filesystem caching sits on

top of that.   So 1 less cache needed.  Ie the cache of passes and

failures they keep so they don't slow the system down too much.
About time they wake up Linux Different OS.  We have zero tolerance of

root kits.   There is a section with the design to provide the file

system monitoring and the network monitoring both without being in LSM

space.  So why do they need LSM's.   Cannot they just use system LSM's

to protect there anti-virus like everyone else.   No need to treat

them special.   If they have a issue with a LSM not being good enough

they need to speak up.
They really need to provide what they want to do to us.   There issue

is they keep on looking in the wrong places and doing things the

windows way.   This is not WINDOWS.   In time mac and other OS's could

come tighter on root kits as well causing the programs to fail as

well.   Basically get use to working with a OS that does not tolerate

secuirty flaws.
Peter Dolding

--

Seriously, it's David Howells at Redhat who's doing that.  In your last

email i figured it was a typo, but credit where it's due :)
-serge

--

So you are going to try to force us to take something into the Linux

kernel due to the security inadiquacies of a totally different operating
I agree, but as others have pointed out, you don't need to do this in

the kernel, you can do it from userspace today (samba has hooks for this

for that "other" operating system already).
thanks,
greg k-h

--

-----Original Message-----

From: Greg KH [mailto:greg@kroah.com]

Sent: Tuesday, August 05, 2008 4:18 PM

To: Press, Jonathan

Cc: Arjan van de Ven; Eric Paris; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to

alinuxinterfaceforon access scanning
So you are going to try to force us to take something into the Linux

kernel due to the security inadiquacies of a totally different operating

system?  You might want to rethink that argument :)
[JON PRESS]  On the contrary...you might want to rethink your reaction.

The security inadequacies of that other operating system that happens to

have a 90+% market sure are exactly why Linux and other OS's that

coexist with it should be more conscious of their own interactions with

it.  Enterprises that see Linux as a potential breeding ground for

infestations are less likely to tolerate Linux in their environment.

Why do you think we have so many customers who have a corporate mandate

to have AV software on all machines, no matter what platform type?
thanks,

greg k-h
--

I don't think the pissing contest is going to get us anywhere.  I think

Jon might want to realize that the linux kernel is not driven by

business needs, we are driven by technical correctness and technical

necessity.  lkml isn't a place where you wave a bag of money and say "do

you want to be in the data center, do as I say."  Techies always win,

not business.  I think Greg needs to realize that not all of the AV

vendors are being or want to be difficult, thick, or stubborn.  I would

like to point out for the community's enjoyment that much of the heavy

lifting here has been done by one of these vendors who is currently

using the above mentioned horrible hacks to make their product work

(although at least I believe GPL horrible hacks).  Most all of the black

magic vendors agree they want to work towards a real upstream solution

so lets try to find it, not just build walls and get defensive.
I personally agree with Greg that I don't care if its 'hard' to get all

the information you need to do your job as long as it is reasonable and

sustainable.  I think this interface is both and I'm going to be looking

for numbers to show it over the next couple of days.
I think Alan and I have both described how greater linux security can be

gained through this interface compared to glibc or LD_PRELOAD even if it

isn't perfect security.  I certainly don't make the claim that all

malware (for any OS) is going to get stopped dead in its tracks.  But

then again I also haven't heard any vendor say "we don't look for any

linux malware."  Even if the majority of their business is driven by

"that other OS" it doesn't mean that software on linux is without flaws

and we don't have attackable programs.  Would any vendor who does this

type of work stand up and say how your product may have stopped or been

able to stop a vulnerability that would have been impossible in

userspace.
-Eric
--

On Tue, 05 Aug 2008 16:51:07 -0400
I guess I missed that.
I will fully subscribe to the idea that  "the LD_PRELOAD way assumes you

have a good->bad transition" might not be fully bullet proof (after

all, if your init is compromised you won't have this transition)
but what else is the actual gap?
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Sure, but if that's the case, you don't need to have a blocking open()

interface.  Having inotify tell your application that a file

descriptor that had been opened for writing has been closed

(IN_CLOSE_WRITE) should be quite sufficient.
						- Ted

--

-----Original Message-----

From: Theodore Tso [mailto:tytso@mit.edu]

Sent: Tuesday, August 05, 2008 2:55 PM

To: Press, Jonathan

Cc: Greg KH; Arjan van de Ven; Eric Paris; linux-kernel@vger.kernel.org;

malware-list@lists.printk.net; linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to

alinuxinterfaceforon access scanning
Sure, but if that's the case, you don't need to have a blocking open()

interface.  Having inotify tell your application that a file

descriptor that had been opened for writing has been closed

(IN_CLOSE_WRITE) should be quite sufficient.
[JON PRESS]  I don't get the connection between what I said and your

point about not needing blocking open() interface.  If I ftp into a

Linux machine and GET an infected file, you want FTP to go right ahead

and read it and send it to me over the wire?
--

Shouldn't that be the issue of the FTP server itself not serving up

"invalid" files, and not the kernel?  Why not just hook in it, I'm

pretty sure they already provide this kind of interface, right?
thanks,
greg k-h

--

-----Original Message-----

From: Greg KH [mailto:greg@kroah.com]

Sent: Tuesday, August 05, 2008 5:15 PM

To: Press, Jonathan

Cc: Theodore Tso; Arjan van de Ven; Eric Paris;

linux-kernel@vger.kernel.org; malware-list@lists.printk.net;

linux-security-module@vger.kernel.org

Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to

alinuxinterfaceforonaccess scanning
Shouldn't that be the issue of the FTP server itself not serving up

"invalid" files, and not the kernel?  Why not just hook in it, I'm

pretty sure they already provide this kind of interface, right?
[JON PRESS]  So how would that work?  The FTP server would have code

that called into someone's AV SDK (maybe CA's, maybe not) and scanned

the file before sending.  OK.  What about all the thousands of other

applications that might access a file and send it somewhere, or copy it

somewhere.  They should all do the same thing, right?  How do we make

that happen?  That's the whole point of centralizing the control (the

notification, blocking and waiting -- not the actual scanning, of

course) in the kernel.  The scan becomes unavoidable -- and that is the

definition (OK, a definition) of true security.
--

Ok, let's stop right here.
Please answer Al's question:

	What is the threat model this proposal is attempting to address?
Unless this is well defined, we will go down the "hook this here", "but

what about..." argument back and forth for a very long time getting no

where.
So please let's end this thread right now and can someone please post

the answer to this question.
thanks,
greg k-h

--

Give me a break...  There's nothing to stop you from doing that as

a stackable fs, cachefs-based filesystem, fuse-based filesystem,

CODA with trimmed-down server that does scan-on-commit, et sodding cetera.
Again, do you or do you not expect the malware to be active on scanning

host?  Yes or no, please.
These two variants are so fundamentally different that discussion without

clearly indicating which variant you are currently talking about is absolutely

pointless.

--

On Tue, 5 Aug 2008 17:23:39 -0400
the admin (or distro) decides he wants all files opened by the FTP

server scanned, so he starts the FTP server with the LD_PRELOAD set.
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Scripts

Attempts to screen content

Exec occuring after ld.so is compromised
Is there anything however that cannot be done with SELinux if you added

the ability to block an open and kick it upwards (including the open of

an exec binary)
It seems you would then get a transition from a label of 'trusted' to

'untrusted_unverified' and an open of untrusted_unverified can (depending

on the SELinux rule) then block, trap upwards and continue according to a

userspace response.
At that point all the questions like 'what do I want to scan for' become

SELinux questions and we already have all the technology to do stuff like

'only scan for samba' or 'only scan for httpd and cgi' and do it

efficiently.
The cache then becomes the labels which are already part of the fs and

our existing labelling and context management.
Alan

--

On Tue, 5 Aug 2008 18:29:44 +0100
get either opened or exec'd...
this is post-compromise scenario; if you have enough root rights to do

that then it's game over.
--

One common use for scanning is to scan content not looking for executable

stuff but for things like malformed image files and the like. It's also

useful for indexing and in those cases you don't really want ld.so in the
You still want to know if you spot this. And the root rights thing

assumes no selinux. For a large case of uses I would agree however.
Alan

--

On Tue, 5 Aug 2008 21:12:43 +0100
if selinux wouldn't stop a "not really root" root from writing to ld.so

stuff you have a different problem ;-)
--

If you want to reach me at my work email, use arjan@linux.intel.com

For development, discussion and tips for power savings,

visit http://www.lesswatts.org

--

Are suid binaries something that you feel is necessary to scan from?
So, if this isn't really going to protect anything, how can anyone
No, your field definitions are incorrect.
You must use __u8 and friends for variables that cross the
Not doing this in the kernel at all.
Seriously.
I mean it.
Oh, and after that, not using a binary interface, have we not learned
audit passed the value in a binary structure from the kernel to
Oh, forgot about the fact that the code blocks.  That's probably a race
How long does this whole process take?  Seriously is it worth the added
And when you did run a foolish userspace client?
If you did it all in userspace, if the userspace code isn't being
Again, do it all in userspace (caching, and scanning).  I still really

don't see the need to do this in the kernel becides it being "the way

people have always done it."
thanks,
greg k-h

--

I don't see a reason why we can't use strings and key=value pairs for
open the magic "vetting" file RW and you are a client who can answer
Is it worth having 2 context switches for every open when none are
Maybe a new hook, maybe just a capability call, something to make root
In kernel cache has 0 context switches for every open.  Userspace

caching has 2.  Every open has to block, switch to the context of the

userspace client/cache, get that decisions, and then switch back to the

original process.
--

Should be OK from my point of view assuming we keep cache and basic

filesystem exclusions in kernel. Otherwise it would be too much work (I am

talking about CPU time) to do with each and every interception.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

Sure, but do you really want to put a parser in the kernel (well, make
Compared to the real time it takes in the "virus engine"?  I bet it's

totally lost in the noise.  Those things are huge beasts with thousands
Again, compared to what?  If you in userspace are doing big complex

things, such an overhead is trivial.
And again, realize that Linux has the fastest context switches _by far_

of any other operating system.  It is ok to do things in userspace, we

are used to that :)
thanks,
greg k-h

--

No, because we are talking about a case here where we don't want to do any

scanning. We want to detect if it is procfs (for example) as quickly as

possible and don't do anything. Same goes for any other filesystem where 
Again similar thing as above - In case of a cache we are not doing complex

things.
So I think you can't argue that because scanning is slow everything else

has to go to userspace. On a typical running system scanning is

exceptional and everything else benefits from being in the fast path.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

See previous messages about namespaces and paths for trying to figure this
I really can not judge as we have not seen an implementation yet.
thanks,
greg k-h

--

How are namespaces and pathnames relevant to exclusions based on

filesystem *type*? It is not about checking for /proc but checking if the 
As small as possible - just one extra field in the inode struct. 
And really you are talking about a different thing again and moving the

argument around. I answered you why your argument about putting a cache in

userspace since we do so much there already is wrong, because we don't do

a lot (anything really) in userspace for vast majority of opens if we have 
Did you mean "_I_ have not seen an implementation yet"? Because Eric

posted it so you can have a look at your leisure.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,

OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--

Didn't I already go over this?  The patch for FS exclusions would not be

namespace based, rather  dentry->d_inode->i_sb->fstype->name matching.
Lets not start name based discussions at this point in time.  Those

patches weren't proposed on this go and reading the write up of both of

the name based items (I think number 11 and 12) one I outright reject

and the other will require future discussion.
-Eric
--

We don't have notifiers for file segment changes that are scalable that

far. We don't have mechanisms for delaying an open for a scan.
There are various bits of this you can't just do in user space. This

doesn't just hurt virus scanners btw its also bad news for indexing disk

content.

--

I agree, but if we did, would that help out a lot here?  Lots of other

groups of people are needing/asking for something like this and if

someone can finally get it together to post something useful, that might

be a very good thing.
thanks,
greg k-h

--

On Tue, 5 Aug 2008 10:01:43 -0700
A scalable notification scheme would certainly sort out content indexing

systems more nicely. Open notifiers that scale let you do path indexing

("People who opened file X also opened file Y" - both for optimising disk

layouts and for application level 'what do I prompt the user with' stuff)
The only thing  I can see that is actually needed to get the whole thing

working sweetly even for the virus and HSM cases is an LSM willing to

bounce some opens via a user space helper. Even without that you could

label content 'dubious' on close and relabel it accordingly in the

asynchronous scanning app
Alan

--

Doesn't work very well really does it - ld.so loads files too and can be

attacked.

--

But that's an "attack" vector, which virus scanners are not addressing.

They are going for the "is this file corrupted" type issue.  The

"normal" LSM interface is for malware itself, taking control of a

system.
thanks,
greg k-h

--

So you are arguing against the defense in depth theory?  LSM should

solve it all so why bother?
I don't think that anyone is claiming that they don't address that

vector.  They may not be perfect but they are infinitely better than the

zero protection we offer today.  Clearly in the enterprise world the

most useful purpose of these scanners is looking at inflight data

crossing valid safe non-hacked linux processes, but the implementation I

have given is such that we can start doing some validation on our own

executables.  Remember the requirement wasn't just to scan data, it was

to scan everything that gets opened.
As an example of the usefulness of this approach as opposed to the

LD_PRELOAD/glibc approach is that I could be used to minimize the impact

of things like the recently much touted discussion about malicious

repository mirrors.  Although clearly there were some flaws in the

common conception of the problem, the ability to trick users into

downloading and installing trojaned libraries is not something we can

presently protect against with any mechanism.
Lets assume that the black magic in userspace was able to spot a

trojaned library running programs which would still be linked to the old

files on disk would continue to work but you would very quickly find out

there was trouble when everything that tried to open its shared library

was getting EPERM.  Yes, yes, even I can think of ways around it (bad

repo sends bad kernel first and waits until the machine is running the

bad kernel to disable scanning) but by that time they already won.  And

its possible that the userspace scanning could/would spot the trojaned

kernel and report on it during install time.
I'm going to run perf test this afternoon but I'm going to have to look

for a test that is a good mix of reads,writes, and opens.  I strongly

suspect that there will be a noticable perf lose in any other method

that doesn't include in kernel caching.  (how can there not be with an

extra context switch for every op...
[ message continues ]

No, I am saying I have yet to see a real requirement to justify that

this code goes into the kernel.
Your list shows no such requirement, in fact it overlaps with some

things that LSM already provides.  So why not just make it an LSM and be

done with it?
Oh wait, this is a commercial add-on for vendor kernels that already

have an LSM built in, that will not work.
But that's not what virus scanners on Linux do!  So again, don't bring
See my earlier comments about this.
thanks,
greg k-h

--

While I try to get someone to talk to me, lets consider even the most

simplistic threat model.  I'm not stating that this is the only threat

that vendors wish to protect against, but I think we can all agree it is

a meaningful threat.  Trying to get the AV vendors to talk about their

products actual uses is like pulling teeth.
This simple thread shows what I believe to be clear and compelling

evidence of the need for an in kernel solution.  Lets just consider that

we are a high input, high output, NFS file server with other OS's

mounting this NFS share RW.
Our goal is to stop, or at least reduce the throughput (I clearly

document and accept the open to read race, and until we get a working

revoke I don't see that changing) of malware across the NFS server.

This data will not be attacking the NFS server.  We wish to slow and

hopefully halt the spread of this data with minimal impact to the NFS

server.
Since the NFS server interacts directly with the VFS no purely userspace

solution is possible.  I certainly hope noone tells me we should hook

directly into nfsd and do everything else in userspace   :)
The purpose of this e-mail is not to ask others to find 'the perfect

solution for this one example' but merely to holp move away from the

ideas that this can be done in GLIBC or in LD_PRELOAD.
Maybe my code is all crap, I'm more than willing to accept that, it

wouldn't be the first time, but I do see the open on the NFS server and

I could do "something" with that file on the server.  I can continue to

define lots of other threats that my interface is useful for (even if

Greg dismissed one of them out of hand) but right now I'm trying to get

all of the AV vendors to define what it is they do (and I think we all

know they will claim to do exactly this)
-Eric
--

In this scenario, are you positing that you are worried about Windows

malware, or Linux malware?  What OS are the clients running?  I will

note that Windows has such a sucky NFS implementation that nearly all

Widows clients will be running CIFS/SMB, not NFS --- so the right

solution there is to integrate the virus checking with Samba ---

especially since the one AV vendor has already admitted the actual

virus signature checking has to be done in userspace.
For Linux clients, one question that immediately rises is the

end-to-end argument.  Wouldn't be far better to run whatever security

solution on the client?  After all, a Virus checking on an NFS server

isn't going to help the user if they accidentally track in the virus

on a USB stick.  (Especially if it is an infected Macro virus in an

office document.)  
							- Ted

--

I believe I specifically did not make any such claims at all about the

client OS and merely claimed the intended target was not the linux NFS

server.  I didn't make those claims because they are irrelevant and so

that people could not jump on those details and try to offload the

solution to the wrong place.  Maybe the client is not Windows but

another large desktop OS who actually has a reasonable NFS client?  How

do you turn this into a straw man argument then?  Remember, I'm not

claiming that my solution for the entirety of the threads that AV

vendors claim to want to protect again, I simply claim that a

GLIBC/LD_PRELOAD solution is easily shown to be infeasible for even the
<snide> I believe they all are going to claim it has to be in some
Your argument is irrelevant for the threat given and you seem to have

contorted the actual point of the statements to fit something else.  But

I'm sure you a fan of multiple layers of security that you don't

actually believe that "just check on the clients" is the right thing to

do.  Linux client side checking is most likely going to be something

that vendors claim to want to do but has no bearing on if out of kernel

scanning is feasible for NFS servers.  Nor if you want to look at the

"end-to-end argument" as you claim can excluding server side scanning be

a reasonable choice.
How many clients machines at your location are controlled by some IT

organization?  How many servers?  I think it's quite obvious that unless

the answer to the first question is "all" then we would want scanning on

both the client and the server.  I think there are many organizations in

which many, or even most, machines with access to an NFS server can be

controlled so as to enforce scanning, but its not reasonable, at least

in my mind, to throw out server side NFS scanning unless you can control

ALL of the clients.
-Eric
-Eric
--

I know you didn't say; that's why I asked.  :-)
I dispute your assertion that this quesiton is irrelevant.  It's

highly relevant, because if it's Windows clients, they ***won't*** be

using NFS.
As for other large desktop OS's, that would be MacOS and Linux;

anything else?  And the big, huge, vast difference between Windows and

MacOS/Linux is that with Windows, in practice people ran with

Administrator privileges because most applications (including at one

point Microsoft Visual Studio :-) died and/or completely refused to

install if you didn't have Administrator privileges.  So people very

regularly ran with Root privs.  With Vista, you no longer run with

root privileges by default --- instead, applications still assume they

have Administrator privileges, causing the Really Annoying Popup boxes

to pop up each time the application needs to do something that require

privileges --- which has trained users to mindlessly click "OK" each

time the Annoying Popup Box comes up.
Given that MacOS and Linux don't have these flaws with respect to

applications regularly expecting root privileges, will you admit that

perhaps some of the extreme scanning tactics that were required by

AntiVirus vendors might be not as necessary for "other desktops"?
Asking the question is important because if they are spending all of

their time on Windows virii, then your "elementary threat" is really

an "elementary strawman".  Or, at the very least, it's a low priority

effort, since the number of virii out in the field for Linux and MacOS

desktops is in the noise compared to Windows.  I know that it's

convenient for AV vendors to claim in their marketing literature that

this is only because Windows is more popular, but while that might be

part of it, it is also true that there are significant, structural
Giving up my water bottles and having to take off my shoes at airport

security has been justified in the name of "multiple layers of

security".  No, I'm NOT a fan of mindlessly using "defense in depth"

...
[ message continues ]

We are sort of talking past each other here, but I really am listening.
Absolutely, I think that our solution needs worry much less about an

actively attacking root process than Windows.  I think everyone on list

would tend to agree that our security model greatly helps in this

regard.  I think the problem quickly becomes intractable as soon as we

talk about a locally running actively attacking root process, which I

believe is what you are discussing.  I think that leaves 4 things
1) fileserver with no active attack on system

2) actively attacking non-root processes (run some process that tries to

screw people)

3) accidentally attacking, non-root process. (open a malicious

openoffice file)

4) accidentally attacking, properly functioning, root processes (my

thought on this would be a properly functioning non-exploited yum

program getting data from a bad repo)
For the purposes of this e-mail discussion can we only discuss #1?  I

think its the easiest problem to look at and is at the heart of stopping

#2, 3 and 4.  If we can keep the files off the disk we greatly reduce

(although clearly don't eliminate) the ability for all of the other
Remember my (contrived to prove a single point, but I think interesting)

goal was not to stop an active attack against any OS, which you appear

to be focusing on.  My goal was to make a Linux fileserver an

inhospitable place for data which may someday attack a system to live.

Our systems have almost infinitely many ingress and egress mechanisms

and I don't think its tractable to attempt to do this at the edge.  At a

minimum while I sit here I can think of smbd, nfs, ftp, http, smtp, ssh,

and rsync which are very likely ingress and egress points of data on a

Linux system.  Trying to move the solution to all of those places gets a

bit large and certainly buggy.  And I think we both agree those aren't
I guess step one is agreeing that the goal "harden linux to be an

inhospitable host for 'bad' data which may someday be used to attack

another ...
[ message continues ]

Note by the way that this assumption is being actively undermined by all

those companies releasing software released as big executable blobs that

you just have to chmod +x and run; as root if you want them in /opt, or

/usr/local/bin, or ...
Even when OpenOffice.org, IBM Lotus Symphony, RealPlayer, Flash, what

have you, might generally by themselves not be considered virusses both

the precedent they set and the opportunity for infecting systems by

offering those for re-download from elsewhere is worrying.
One of the more useful things the security crowd could do to keep the

above assumption valid would be working on a general "external software

installer" and getting all distributions to settle on it (which probably

needs a common divisor package and distro backends to feed it to the

native package manager).
Rene.

--

but you already say that said blob exists on disk?  Therefore by my most

basic of models it won't ever actually get to run since it will get

scanned right as you try to execute it and you will get EPERM instead of

a running evil process.  (all of that is assuming the userspace black

magic is useful, but I don't think that's really up for debate since we

have no way of knowing exactly what these closed source AV vendors

actually are doing....)
It looks in my mind that more and more the only real model that can even

attempt to be addressed is to make disks inhospitable to data which

might be intended to do ill to another machine.
maybe a good idea, but beyond my expertise or ability to push forward...
-Eric
--

Once the process is running we are talking about having lost.
Note, I did not follow this thread (closely) ...
Thing is just -- just wait for how long it takes said clueless user you

are so vigorously protecting to disable that which brings about your

model the first time if interferes with him running a cracked copy of an

expensive yet popular program, playing a game, installing a wiggling

nudies screensaver, ...
The difference here is just that Linux systems are particularly bad at

those tasks to begin with which in nice circular motions keeps those

clueless users away, obviating the need to protect ourselves from them.

If this stuff is to be discussed in a context as if Linux were relevant

on the desktop though, I believe it's rather unproductive to expect a

fundamental difference with Windows in this respect.
Fine though if you wouldn't insist on that context. As said, wasn't 
I'll leave it in just in case it spurs someone :)
Rene.

--

Just an observation about this...
Since I earn my living on the basis of users, clueless or not, I've

gotten into the habit of just taking them as they come and trying to go

out of my way to not refer to them as clueless -- except in a few

specific and particularly annoying cases.
But that's not my point.  My point is that Linux has become a

commercially viable environment with a lot of enterprise users, with a

significant number of enterprises are standardizing on it, or at least

officially supporting/allowing/encouraging its use.  Because of that,

for example, we have a significant number of user issues coming in that

indicate that there are actually plenty of clueless Linux users, whether

the OS was intended for them or not.
The fact that they are there is the main reason that Red Hat and Novell,

for example (at least by my observation from the outside -- I can't

speak at all about how they see if from the inside) seem to be putting

the bulk of their efforts into their enterprise editions, as opposed to

their traditional technologist editions.
The bottom line, then, is that there ARE way more clueless Linux users

out there than there used to be, which makes them a) vulnerable to

losses by virtue of their own mistakes, and b) vectors for the spread of

malware.  Which is kind of why we're here.
Jon Press
--

You say that as though you feel that calling someone clueless were a bad

thing. There are tons of subjects I'm completely and utterly clueless 
But not users with root access, which is the context in which my own

remark was. Enterprise users in corporations are not what I call the

desktop; I'd generally call those workstations, with the desktop being

your average home PC with the enormous amounts of cheap and buggy

hardware and the definite lack of central IT management.
It's also dependent on country. Over here in the Netherlands, corporate

adoption "on the workstation" is very low (and seemingly dropping again

after some initial attempts in local government) and adoption on the

desktop is for all intents and purposes 0. It's different especially in

eastern-europe.
Funny that really, how all that Free as in Speech stuff mostly works for 
Right, so that, then, is a threat model. I myself believe you are here

mostly to guard against 11-year old girls installing infected

screensavers of horses which given the fairly low adoption of Linux by

11-year old girls says something about my view of things.
But, yes, as I myself said as well, it might be sensible to discuss this

issue simply _as if_ lots of users were brushing their My Little Pony's

while waiting for their kernels to finish compiling if you're designing

something that _should_ protect them if they were.
Goes back really to the threat model question you were asked I guess.
Rene.

--

Well, in all honesty, sometimes when I think of someone as clueless,

there is a certain negative emotion that goes along with it.  However,

the point is more that THEY don't like to be called clueless -- both

because, for some reason they take it as an insult, and also because

there are many out there who "know enough to be dangerous" and think

they know more than they really do.  So I have to be careful not to say

anything to them that sounds like I think that, and to make sure that
You would be surprised how many users with root access are also

clueless.  I used the word "enterprise" very broadly.  It applies to

large companies/institutions with sophisticated IT departments, but it

also applies to small to medium organizations who said to themselves,

"Gee what's this Linux thing I keep hearing about -- maybe we ought to

get one of those."  And they end up with administrators who also don't

really know all the ins and outs they need to in order to create a

secure environment.
In a way, it's a price that Linux has paid for its growing acceptance.
I can't speak about every different country, but I would say that you

are right about Eastern Europe.  But also in the US and Canada we have
There are many gradations of users between the kernel pro and the

11-year-old girl.  
One is the guy right out of college who really likes computers and he

gets a job at a place where they use Linux, and he does a web search and

finds this really cool application that might help him do his job

better, so he installs it on the spot.  Uh-oh.
One is the guy who's been working there for a while and the head of IT,

tired of spending so much on Windows, tells him to install Linux on a

few machines, so he follows the instructions and he's now the

administrator.
The fact is that there are MILLIONS out there, and when you have

millions of anything, you are going to have lots of different kinds of

behavior that are hard to predict ahead of time.
--

See, that never happens here. Our guys use Linux while _in_ college (in

between the periods where they need to run Windows to get their college

work done ofcourse) and after graduation take a job collecting microsoft

certifications that their boss pays them to collect.
Then I come along a couple of years later and buy the old soundcards

that they put up for sale on our national auction site, mentioning I

want that stuff for Linux testing and they get all teary-eyed and

melancholic about the good old days when they had the time to play

around with linux. Those fun childhood days.
I saw that happening a few years ago here. By now, the small time shops

that I'm aware of have all gone back to Windows. Linux simply cost them

too much time which, if IT is not their business, they had no intention

whatsoever of spending on IT.
Do let me assure you though that I'm definitely aware that my personal

frame of refence might not be all that gobally applicable and bow out of

the discussion.
Rene.

--

Sorry, can't help but laugh at myself for typing "bite".
-Eric
--

Nack, please no pathname based idiocies.
--

I don't know when files get closed and can't preemptively scan to make

sure it is clean for the next open?  Any writes are going to invalidate
The data connected with the file being opened must as reasonably as

possible be the data the 'scanner' looks at.  Some foolish early

discussion wanted to do simplistic things like pass a pathname to a

scanner and have it call open on that path name.  I'm willing to

entertain any other method of making the scanner look at the data the
What? it allows a process to open a file that contains malware, how is

that horrible.  If a process says "I want to see malware" it can then

see malware.  Doesn't in any way affect other processes or the system

security as a whole.  If 'bad' data gets into a file its going to get
Go read the long explainations, I already rules out path based

inclusions.  I'm leaving exclusions up for grabs since I don't see it

weakening the security model.
--

No, I want a sane security policy in kernelsapce that doesn't look

at the content because doing security by content properly is equivalent

to solving the halting problem.  I couldn't give a rats a** about

windows viruses as they can't actually cause any harm on a Linux
Well, data can change all the time, as can the path name.  This whole
So make this opt-in and in userspace.  Just LD_PRELOAD some monster lib

doing all the horrible things you propose and use it wherever you want.
--

My guess is that wine is good enough these days to run many Windows

worms actually.
-Andi

--

On Wed, 06 Aug 2008 04:41:04 +0200
Firefox, Open Office and other applications are probably large and

feature rich enough that making worms for them might be possible.
Not being able to harm the operating system is not the same as not

being able to harm the user.  We still want some protection from

the latter...
--

All Rights Reversed

--

Go on then.. post patches.
I think your are being incredibly naïve. Our memory debugging is not 100%

solid but work by heuristic. Our lock analysis doesn't solve the halting
Rather tricky as the needed hooks don't exist and you need to get ahead

of even ld.so as well as protect suid apps. You've clearly not even

thought about the problem space before sounding off because there are

more elegant ways of tackling it even if you want to push it at

userspace, and ones that aren't implausible like LD_PRELOAD.
If you'd applied even 30 seconds thought you would at least be pointing

people at FUSE or a stacking fs.
Alan

--

Onus is not (or actually often is, but should not) be on reviewers

to do this. That effectively further reduces review bandwidth.
I can see why "feature" writers like the idea though. Either they

get someone to do their work for them, or negative reviews

disappear :)

--

Sure, but what's the point of partial security? It seems to me you're

not secure until you're fully secure, so why bother with almost?
Every bug caught with the debuggers is one caught, yay :-)
Every virus let through is a pawned system, aww :-(
--

Every bug missed is a crash. Security is not an absolute. If I burst into

your office with a machine gun and ask you for the password your security

system probably fails ...
Security is a risk/reward model.
Alan

--

Much better solution:
Use SELinux or another similar Mandatory Access Control labeling

system.  Mark some things as "trusted" or "privileged" or whatever

your particular labeling methodology requires.  Mark other things as

"untrusted", "unprivileged", "internet file", etc.  Disallow most

interaction between "trusted" and "untrusted" things.  Configure your

userspace virus-scanner which is allowed to read "untrusted" files and

create "semi-trusted" files in a particular directory, where they can

then be picked up by "trusted" programs.
Problem solved.  Untrusted and possibly-compromised files can't be

executed, or even if they could be they can't do anything

interesting/harmful.  In order to execute some junk you just

downloaded from the internet you have to click "Yes I accept the

security risk" and run it through whatever virus-scanner you want.

Then you copy it from the virus-scanner output directory into

somewhere else and run it.
You can do the same thing with software updates downloaded from the

internet, just replace "trusted" with "installed package",

"semi-trusted" with "valid package", "untrusted" with "just-downloaded

package file", and "virus scanner" with "package signature

verification tool".
I could easily come up with a bunch more examples if you really care that much.
Cheers,

Kyle Moffett

--

> Much better solution:
Two things

- Scripts

- Attacks based on compromising a live binary
You can use SELinux to control what is executed and it is a very

effective management control technique. However it doesn't control

javascript in web pages, exploits that popen perl and chat to it and so

on...

--