linux-kernel - RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 5 Aug 2008 10:41:44 -0400
From:	"Press, Jonathan" <Jonathan.Press@...com>
To:	"Eric Paris" <eparis@...hat.com>, "Greg KH" <greg@...ah.com>
Cc:	<linux-kernel@...r.kernel.org>, <malware-list@...ts.printk.net>
Subject: RE: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface foron access scanning

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@...sg.printk.net
[mailto:malware-list-bounces@...sg.printk.net] On Behalf Of Eric Paris
Sent: Monday, August 04, 2008 8:33 PM
To: Greg KH
Cc: linux-kernel@...r.kernel.org; malware-list@...ts.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/