linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on 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]

Message-Id: <1218048597.27684.276.camel@localhost.localdomain>
Date:	Wed, 06 Aug 2008 14:49:57 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Greg KH <greg@...ah.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, malware-list@...ts.printk.net,
	linux-kernel@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface
	for on access scanning

On Tue, 2008-08-05 at 13:30 -0700, Greg KH wrote:
> On Tue, Aug 05, 2008 at 02:56:42PM -0400, Eric Paris wrote:

> > So you are arguing against the defense in depth theory?  LSM should
> > solve it all so why bother?
> 
> No, I am saying I have yet to see a real requirement to justify that
> this code goes into the kernel.

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

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