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: <1218058081.5837.49.camel@localhost.localdomain>
Date:	Wed, 06 Aug 2008 17:28:01 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Theodore Tso <tytso@....edu>
Cc:	Greg KH <greg@...ah.com>, 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 Wed, 2008-08-06 at 17:02 -0400, Theodore Tso wrote:
> On Wed, Aug 06, 2008 at 02:49:57PM -0400, Eric Paris wrote:
> > 
> > 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.
> 
> In this scenario, are you positing that you are worried about Windows
> malware, or Linux malware?  What OS are the clients running?  I will
> note that Windows has such a sucky NFS implementation that nearly all
> Widows clients will be running CIFS/SMB, not NFS

I believe I specifically did not make any such claims at all about the
client OS and merely claimed the intended target was not the linux NFS
server.  I didn't make those claims because they are irrelevant and so
that people could not jump on those details and try to offload the
solution to the wrong place.  Maybe the client is not Windows but
another large desktop OS who actually has a reasonable NFS client?  How
do you turn this into a straw man argument then?  Remember, I'm not
claiming that my solution for the entirety of the threads that AV
vendors claim to want to protect again, I simply claim that a
GLIBC/LD_PRELOAD solution is easily shown to be infeasible for even the
most elementary of threats.

> --- so the right
> solution there is to integrate the virus checking with Samba ---
> especially since the one AV vendor has already admitted the actual
> virus signature checking has to be done in userspace.

<snide> I believe they all are going to claim it has to be in some
userspace proprietary application for them to keep making money </snide>

> For Linux clients, one question that immediately rises is the
> end-to-end argument.  Wouldn't be far better to run whatever security
> solution on the client?  After all, a Virus checking on an NFS server
> isn't going to help the user if they accidentally track in the virus
> on a USB stick.  (Especially if it is an infected Macro virus in an
> office document.)

Your argument is irrelevant for the threat given and you seem to have
contorted the actual point of the statements to fit something else.  But
I'm sure you a fan of multiple layers of security that you don't
actually believe that "just check on the clients" is the right thing to
do.  Linux client side checking is most likely going to be something
that vendors claim to want to do but has no bearing on if out of kernel
scanning is feasible for NFS servers.  Nor if you want to look at the
"end-to-end argument" as you claim can excluding server side scanning be
a reasonable choice.

How many clients machines at your location are controlled by some IT
organization?  How many servers?  I think it's quite obvious that unless
the answer to the first question is "all" then we would want scanning on
both the client and the server.  I think there are many organizations in
which many, or even most, machines with access to an NFS server can be
controlled so as to enforce scanning, but its not reasonable, at least
in my mind, to throw out server side NFS scanning unless you can control
ALL of the clients.

-Eric

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