request for comment: generic kernel interface for malware vendors

request for comment: generic kernel interface for malware vendors

[Eric Paris]

First I'd like to thank Sophos who stepped up and originally wrote a lot
of this code.  They might not recognize it since I've gotten my hands on
it, but they were nice enough to get the ball rolling by giving me some
GPL code which addressed near every request people on the malware list
had.

At the moment all of the code (over)uses the name talpa.  I expect this
group of people to come up with a new name for this interface, but since
that's how the patches started and I couldn't come up with anything I
love the patches still say talpa.  So if nothing else, lets come up with
suggestions.  For a little bit I plan to carry these as purely out of
tree patches but can move development somewhere like a git tree as they
settle down.  Feel free to send me comments/patches in an manner you see
fit.  I'm here to help.

This is a request for comment.  This is a first stab and I'm here to
address all of the concerns that people have.  Please don't hold back,
I've got thick skin.  BUT, I don't want to hear 'this is how we have
been doing it, do it that way.'  I want to hear how this won't work for
your needs (and WHY) or how we can do it better.

you can find the patches at:
http://people.redhat.com/~eparis/talpa

(1, 3, and 9 are by FAR the most interesting)

FOR NOW it comes with no documentation.  This is just a code dump since
I'm just in a rush.  I fly out for OLS in 5 hours.  Speaking of OLS, I'm
going to be there.  If you are going to be there and want to talk about
these patches, other patches, your needs, or really anything let me
know.

So what's at that web site?  There are 10 patches against Linus's git
tree.

1 - ****hooks, basics, infrastructure
2 - configuration generic stuff for the other patches
3 - ****results caching
4 - exclusions based on the operation or filetype
5 - per process exclusions
6 - filesystem type exclusions
7 - patch exclusions, don't scan when accessed through certain path
8 - patch inclusions, only scanning selected things
9 - ****userspace vetting, the big stuff
10 - operating when userspace is broken

patch 8 i'm not a fan of.  I really don't like path name security and
while path exclusions means we might scan more than we should
considering how unreliable and useless path names are path inclusions
means we might miss things.  I always find missing things to be rather
unacceptable.  Unless someone feels strongly I plan to drop patch 8
altogether (I also haven't reviewed it at all since I got it from
Sophos)

After (or maybe during) this next week I'll try to explain how all of
this works but for now this is just a code dump.  1, 3 and 9 are by FAR
the most interesting patches.  Patch 9 includes an example userspace
client that denies access to the file /root/denyme if it contains
exactly the string "bad."

I am trying to get something (that works) out there as soon as I can, so
please, don't take what you see as set in stone.  Give me comments.
What should I have done better?  Both in terms of what I'm doing and
what you need?

-Eric

 Documentation/talpa/allow_most.c         |  135 ++++++++
 Documentation/talpa/tecat.c              |   50 +++
 Documentation/talpa/test_deny.c          |  356 ++++++++++++++++++++
 fs/fcntl.c                               |    2 +-
 fs/inode.c                               |    6 +
 fs/namei.c                               |    2 +
 fs/open.c                                |   10 +
 include/linux/fs.h                       |    8 +
 include/linux/sched.h                    |    1 +
 include/linux/talpa.h                    |  184 ++++++++++
 security/Kconfig                         |    1 +
 security/Makefile                        |    2 +
 security/talpa/Kconfig                   |  124 +++++++
 security/talpa/Makefile                  |   18 +
 security/talpa/talpa.h                   |  181 ++++++++++
 security/talpa/talpa_allow_calls.h       |   18 +
 security/talpa/talpa_cache.c             |  207 ++++++++++++
 security/talpa/talpa_cache.h             |   22 ++
 security/talpa/talpa_client.c            |  542 ++++++++++++++++++++++++++++++
 security/talpa/talpa_common.c            |  223 ++++++++++++
 security/talpa/talpa_configuration.c     |  157 +++++++++
 security/talpa/talpa_degraded.c          |  120 +++++++
 security/talpa/talpa_deny_calls.h        |   18 +
 security/talpa/talpa_evaluation_calls.h  |   73 ++++
 security/talpa/talpa_fs_exclude.c        |  104 ++++++
 security/talpa/talpa_interceptor.c       |  122 +++++++
 security/talpa/talpa_operation_exclude.c |  151 +++++++++
 security/talpa/talpa_path_exclude.c      |  108 ++++++
 security/talpa/talpa_path_include.c      |  100 ++++++
 security/talpa/talpa_thread_exclude.c    |   63 ++++
 30 files changed, 3107 insertions(+), 1 deletions(-)

Re: request for comment: generic kernel interface for malware vendors

[James Morris]

On Mon, 21 Jul 2008, Eric Paris wrote:

[ITYM anti-malware vendors...]

> First I'd like to thank Sophos who stepped up and originally wrote a lot
> of this code.  They might not recognize it since I've gotten my hands on
> it, but they were nice enough to get the ball rolling by giving me some
> GPL code which addressed near every request people on the malware list
> had.

We need a document explaining what the problem being solved actually is.  

What is the rationale for adding malware scanning to the Linux kernel?  
How does it benefit people?  Why does it need to be in the kernel?  What 
are the general requirements, and how does this interface meet those ?  
Does this interface represent an approach suitable to a range of 
anti-malware vendors ?

(I'm assuming the fundamental question of whether malware scanning is a 
good idea or not is not up for discussion, because there'll never be 
consensus).



- James
-- 
James Morris
<jmorris@namei.org>

Re: request for comment: generic kernel interface for malware vendors

[Christoph Hellwig]

On Mon, Jul 21, 2008 at 09:17:45PM +1000, James Morris wrote:
> (I'm assuming the fundamental question of whether malware scanning is a 
> good idea or not is not up for discussion, because there'll never be 
> consensus).

Actually except for the malare vendors there's a pretty huge consensus
that it's an pretty dumb idea.

Re: request for comment: generic kernel interface for malware vendors

[Rafael C. de Almeida]

Eric Paris wrote:
> First I'd like to thank Sophos who stepped up and originally wrote a lot
> of this code.  They might not recognize it since I've gotten my hands on
> it, but they were nice enough to get the ball rolling by giving me some
> GPL code which addressed near every request people on the malware list
> had.
> 
> At the moment all of the code (over)uses the name talpa.  I expect this
> group of people to come up with a new name for this interface, but since
> that's how the patches started and I couldn't come up with anything I
> love the patches still say talpa.  So if nothing else, lets come up with
> suggestions.  For a little bit I plan to carry these as purely out of
> tree patches but can move development somewhere like a git tree as they
> settle down.  Feel free to send me comments/patches in an manner you see
> fit.  I'm here to help.
> 
> This is a request for comment.  This is a first stab and I'm here to
> address all of the concerns that people have.  Please don't hold back,
> I've got thick skin.  BUT, I don't want to hear 'this is how we have
> been doing it, do it that way.'  I want to hear how this won't work for
> your needs (and WHY) or how we can do it better.
> 
> you can find the patches at:
> http://people.redhat.com/~eparis/talpa
> 
> (1, 3, and 9 are by FAR the most interesting)
> 
> FOR NOW it comes with no documentation.  This is just a code dump since
> I'm just in a rush.  I fly out for OLS in 5 hours.  Speaking of OLS, I'm
> going to be there.  If you are going to be there and want to talk about
> these patches, other patches, your needs, or really anything let me
> know.
> 
> So what's at that web site?  There are 10 patches against Linus's git
> tree.
> 
> 1 - ****hooks, basics, infrastructure
> 2 - configuration generic stuff for the other patches
> 3 - ****results caching
> 4 - exclusions based on the operation or filetype
> 5 - per process exclusions
> 6 - filesystem type exclusions
> 7 - patch exclusions, don't scan when accessed through certain path
> 8 - patch inclusions, only scanning selected things
> 9 - ****userspace vetting, the big stuff
> 10 - operating when userspace is broken
> 
> patch 8 i'm not a fan of.  I really don't like path name security and
> while path exclusions means we might scan more than we should
> considering how unreliable and useless path names are path inclusions
> means we might miss things.  I always find missing things to be rather
> unacceptable.  Unless someone feels strongly I plan to drop patch 8
> altogether (I also haven't reviewed it at all since I got it from
> Sophos)
> 
> After (or maybe during) this next week I'll try to explain how all of
> this works but for now this is just a code dump.  1, 3 and 9 are by FAR
> the most interesting patches.  Patch 9 includes an example userspace
> client that denies access to the file /root/denyme if it contains
> exactly the string "bad."
> 
> I am trying to get something (that works) out there as soon as I can, so
> please, don't take what you see as set in stone.  Give me comments.
> What should I have done better?  Both in terms of what I'm doing and
> what you need?
> 

I'm a newbie here, so don't take me too serious. But I don't see why
that needs a kernel interface, at least from the example on the
Documentation directory (patch 9). Seems to me you could just use file
permission to deny or allow the access for a certain file. The only
thing that would be a little trickier from user-space is to know when a
given file is read. So, talpa should do only that or you could take
advantage of preload like trickle does for bandwidth shapping.

Re: request for comment: generic kernel interface for malware vendors

[Christian Borntraeger]

Am Montag, 21. Juli 2008 schrieb Eric Paris:
> First I'd like to thank Sophos who stepped up and originally wrote a lot
> of this code.  They might not recognize it since I've gotten my hands on
> it, but they were nice enough to get the ball rolling by giving me some
> GPL code which addressed near every request people on the malware list
> had.

I have not looked at the code, but if I remember correctly there was another 
GPLed code for file access scanning. It was called dazuko. Google gave me  
http://en.wikipedia.org/wiki/Dazuko

Maybe you can get some ideas from there as well?

Christian

Re: request for comment: generic kernel interface for malware vendors

[Eric Paris]

On Mon, 2008-07-21 at 20:14 +0200, Christian Borntraeger wrote:
> Am Montag, 21. Juli 2008 schrieb Eric Paris:
> > First I'd like to thank Sophos who stepped up and originally wrote a lot
> > of this code.  They might not recognize it since I've gotten my hands on
> > it, but they were nice enough to get the ball rolling by giving me some
> > GPL code which addressed near every request people on the malware list
> > had.
> 
> I have not looked at the code, but if I remember correctly there was another 
> GPLed code for file access scanning. It was called dazuko. Google gave me  
> http://en.wikipedia.org/wiki/Dazuko
> 
> Maybe you can get some ideas from there as well?

Maybe ideas, but it works by disabling mandatory access controls.  No
SELinux, no AppArmor, no SMACK, no TOMOYO, and therefore a non-starter.

I certainly don't think its a good idea to take a box that I am using to
try to increase organization wide security and have to lower its
individual security properties.

-Eric

Re: request for comment: generic kernel interface for malware vendors

[Ray Lee]

On Sun, Jul 20, 2008 at 9:18 PM, Eric Paris <eparis@redhat.com> wrote:
> 1 - ****hooks, basics, infrastructure
> 2 - configuration generic stuff for the other patches
> 3 - ****results caching
> 4 - exclusions based on the operation or filetype
> 5 - per process exclusions
> 6 - filesystem type exclusions
> 7 - patch exclusions, don't scan when accessed through certain path
> 8 - patch inclusions, only scanning selected things
> 9 - ****userspace vetting, the big stuff
> 10 - operating when userspace is broken

If, along the way, you can also address the needs provided by the
fschange patches (system-wide inotify, in essence, without having to
register individual watches), that'd be gravy. I haven't looked at
either the patches above or the fsnotify ones, so I can't speak to
whatever overlap they may have, except that it certainly seems like
the anti-malware stuff would be a superset.

   http://stefan.buettcher.org/cs/fschange/index.html

~r.

Re: request for comment: generic kernel interface for malware vendors

[Greg KH]

On Mon, Jul 21, 2008 at 12:18:07AM -0400, Eric Paris wrote:
> 
> This is a request for comment.  This is a first stab and I'm here to
> address all of the concerns that people have.  Please don't hold back,
> I've got thick skin.  BUT, I don't want to hear 'this is how we have
> been doing it, do it that way.'  I want to hear how this won't work for
> your needs (and WHY) or how we can do it better.
> 
> you can find the patches at:
> http://people.redhat.com/~eparis/talpa

You need to actually send the code to the mailing list if you expect
anyone to read it :)

And we need to know what you are trying to achieve here, without that,
there is no way to evaluate if the implementation matches this or not.

thanks,

greg k-h

Re: [malware-list] request for comment: generic kernel interface for malware vendors

[Jon Masters]

On Mon, 2008-07-28 at 20:39 -0700, Greg KH wrote:
> On Mon, Jul 21, 2008 at 12:18:07AM -0400, Eric Paris wrote:
> > 
> > This is a request for comment.  This is a first stab and I'm here to
> > address all of the concerns that people have.  Please don't hold back,
> > I've got thick skin.  BUT, I don't want to hear 'this is how we have
> > been doing it, do it that way.'  I want to hear how this won't work for
> > your needs (and WHY) or how we can do it better.
> > 
> > you can find the patches at:
> > http://people.redhat.com/~eparis/talpa

Ouch. Adds a bunch of hooks outside of LSM - what's the plan here wrt.
LSM, because LKML folks are going to ask :)

Jon.

Re: [malware-list] request for comment: generic kernel interface for malware vendors

[tvrtko.ursulin]

malware-list-bounces@dmesg.printk.net wrote on 29/07/2008 05:50:58:

> On Mon, 2008-07-28 at 20:39 -0700, Greg KH wrote:
> > On Mon, Jul 21, 2008 at 12:18:07AM -0400, Eric Paris wrote:
> > > 
> > > This is a request for comment.  This is a first stab and I'm here to
> > > address all of the concerns that people have.  Please don't hold 
back,
> > > I've got thick skin.  BUT, I don't want to hear 'this is how we have
> > > been doing it, do it that way.'  I want to hear how this won't work 
for
> > > your needs (and WHY) or how we can do it better.
> > > 
> > > you can find the patches at:
> > > http://people.redhat.com/~eparis/talpa
> 
> Ouch. Adds a bunch of hooks outside of LSM - what's the plan here wrt.
> LSM, because LKML folks are going to ask :)

What is the plan with LSM is also a question? Is it gonna stay or be 
removed? Stacking looks like it will never happen and so it really doesn't 
cut it for this kind of use. Although it has hooks at the right places 
(I'm pretty sure but haven't looked in a while) for this first iteration. 

Tvrtko

P.S. How much is a bunch? I think there are just two hooks in this 
prototype.


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

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

Re: [malware-list] request for comment: generic kernel interface for malware vendors

[Greg KH]

On Wed, Jul 30, 2008 at 12:13:36PM +0100, tvrtko.ursulin@sophos.com wrote:
> malware-list-bounces@dmesg.printk.net wrote on 29/07/2008 05:50:58:
> 
> > On Mon, 2008-07-28 at 20:39 -0700, Greg KH wrote:
> > > On Mon, Jul 21, 2008 at 12:18:07AM -0400, Eric Paris wrote:
> > > > 
> > > > This is a request for comment.  This is a first stab and I'm here to
> > > > address all of the concerns that people have.  Please don't hold 
> back,
> > > > I've got thick skin.  BUT, I don't want to hear 'this is how we have
> > > > been doing it, do it that way.'  I want to hear how this won't work 
> for
> > > > your needs (and WHY) or how we can do it better.
> > > > 
> > > > you can find the patches at:
> > > > http://people.redhat.com/~eparis/talpa
> > 
> > Ouch. Adds a bunch of hooks outside of LSM - what's the plan here wrt.
> > LSM, because LKML folks are going to ask :)
> 
> What is the plan with LSM is also a question? Is it gonna stay or be 
> removed?

LSM is staying, no need to remove it.

> Stacking looks like it will never happen and so it really doesn't cut
> it for this kind of use.

Agreed, stacking is probably never going to happen.

thanks,

greg k-h

Re: request for comment: generic kernel interface for malware vendors

[Bodo Eggert]

Rafael C. de Almeida <almeidaraf@gmail.com> wrote:
> Eric Paris wrote:

>> [Kernel support for malware scanners]

> I'm a newbie here, so don't take me too serious. But I don't see why
> that needs a kernel interface, at least from the example on the
> Documentation directory (patch 9). Seems to me you could just use file
> permission to deny or allow the access for a certain file. The only
> thing that would be a little trickier from user-space is to know when a
> given file is read. So, talpa should do only that or you could take
> advantage of preload like trickle does for bandwidth shapping.

How do you ensure that the LD_PRELOAD variable stays intact and will be
honored by all applications - including that commercial one supplying it's
own libc, by suid-binaries and by programs written in a non-libc-language?

Re: request for comment: generic kernel interface for malware vendors

[Arjan van de Ven]

On Wed, 23 Jul 2008 14:43:09 +0200
Bodo Eggert <7eggert@gmx.de> wrote:

> Rafael C. de Almeida <almeidaraf@gmail.com> wrote:
> > Eric Paris wrote:
> 
> >> [Kernel support for malware scanners]
> 
> > I'm a newbie here, so don't take me too serious. But I don't see why
> > that needs a kernel interface, at least from the example on the
> > Documentation directory (patch 9). Seems to me you could just use
> > file permission to deny or allow the access for a certain file. The
> > only thing that would be a little trickier from user-space is to
> > know when a given file is read. So, talpa should do only that or
> > you could take advantage of preload like trickle does for bandwidth
> > shapping.
> 
> How do you ensure that the LD_PRELOAD variable stays intact and will
> be honored by all applications - including that commercial one
> supplying it's own libc, by suid-binaries and by programs written in
> a non-libc-language?

neither approach is fool proof for that matter
it's just a matter of how high you want to put the bar.

that's why it's really important to see the design ideas for this
code... to figure out what it is supposed to do ;)

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