Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 8BIT
Subject: RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning
Date: Tue, 5 Aug 2008 10:41:44 -0400
Message-ID: <2629CC4E1D22A64593B02C43E855530304807431@USILMS12.ca.com>
In-Reply-To: <1217896374.27684.53.camel@localhost.localdomain>
Thread-Topic: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning
Thread-Index: Acj2ktcZzLYHQ7a2SvWPFQElo0VCFwAcjPoQ
References: <1217883616.27684.19.camel@localhost.localdomain><20080804223249.GA10517@kroah.com> <1217896374.27684.53.camel@localhost.localdomain>
From: "Press, Jonathan" <Jonathan.Press@ca.com>
To: "Eric Paris" <eparis@redhat.com>, "Greg KH" <greg@kroah.com>
Cc: <linux-kernel@vger.kernel.org>, <malware-list@lists.printk.net>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2827
Lines: 73

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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/