lkml.org 
[lkml]   [2008]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning
Date
From
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
foron access scanning
>
> > 9. Process exclusion
> > --------------------
> > Sometimes it is necessary to exclude certain processes from being
> > intercepted. For example it might be a userspace root kit scanner
which
> > would not be able to find root kits if access to them was blocked by
the
> > on-access scanner.
> >
> > To facilitate that we have created a special file a process can open
and
> > register itself as excluded. A flag is then put into its kernel
> > structure (task_struct) which makes it excluded from scanning.
> >
> > This implementation is very simple and provides greatest
performance. In
> > the proposed implementation access to the exclusion device is
controlled
> > though permissions on the device node which are not sufficient. An
LSM
> > call will need to be made for this type or access in a later patch.
>
> 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
> programs on the system are to be excluded?

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.




\
 
 \ /
  Last update: 2008-08-05 17:01    [from the cache]
©2003-2011 Jasper Spaans