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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Errors writing large files via NFS
    ... files larger than a certain size to a NFS server. ... client systems, although the definition of "too large" varies. ... network paths involved, I'm pretty sure we're not seeing a network problem. ...
    (Tru64-UNIX-Managers)
  • Re: Frustrated with Trend CSM!
    ... You must exclude them from Officescan, ... Click on your SBS computer icon, and set the client priveliges to your ... settings for the server versus the clients. ... > "Virus successfully detected, but infected file can neither be cleaned nor ...
    (microsoft.public.windows.server.sbs)
  • Re: Still getting NFS client locking up
    ... > the same NFS lockups. ... > Reading from the server works perfectly all the time. ... > NFS CLIENT: ... in particular, look at traces for any client blocked in NFS, ...
    (freebsd-current)
  • Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram
    ... it gets the first ENOSPC error back from the server at around 1.5GB ... the data that gets ENOSPC errors is ... I'm no great expert but isn't this a design flaw in NFS? ... corruption because the NFS client thinks it has written the data ...
    (Linux-Kernel)
  • Re: Problems mounting nfs from freebsd to Mac.
    ... Problems mounting nfs from freebsd to Mac. ... I've got an nfs server that's refusing to mount one client - via one ... That elimintes NFS on the client, and -most- of the NFS config on the ...
    (freebsd-questions)