On Tue, Aug 05, 2008 at 02:56:42PM -0400, Eric Paris wrote:
quoted text
> On Tue, 2008-08-05 at 10:03 -0700, Greg KH wrote:
> > On Tue, Aug 05, 2008 at 12:23:28PM +0100, Alan Cox wrote:
> > > > > It may be possible to do in glibc, LD_PRELOAD doesn't exactly work for
> > > > > suid binaries
> > > > 
> > > > Are suid binaries something that you feel is necessary to scan from?
> > > > 
> > > > I don't see it on the list above :)
> > > 
> > > Doesn't work very well really does it - ld.so loads files too and can be
> > > attacked.
> > 
> > But that's an "attack" vector, which virus scanners are not addressing.
> > They are going for the "is this file corrupted" type issue.  The
> > "normal" LSM interface is for malware itself, taking control of a
> > system.
> 
> 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.

Your list shows no such requirement, in fact it overlaps with some
things that LSM already provides.  So why not just make it an LSM and be
done with it?

Oh wait, this is a commercial add-on for vendor kernels that already
have an LSM built in, that will not work.

Is that really the community's issue?  :)

quoted text
> I don't think that anyone is claiming that they don't address that
> vector.  They may not be perfect but they are infinitely better than the
> zero protection we offer today.  Clearly in the enterprise world the
> most useful purpose of these scanners is looking at inflight data
> crossing valid safe non-hacked linux processes, but the implementation I
> have given is such that we can start doing some validation on our own
> executables.  Remember the requirement wasn't just to scan data, it was
> to scan everything that gets opened.

/me points at a fixed inotify.

quoted text
> As an example of the usefulness of this approach as opposed to the
> LD_PRELOAD/glibc approach is that I could be used to minimize the impact
> of things like the recently much touted discussion about malicious
> repository mirrors.  Although clearly there were some flaws in the
> common conception of the problem, the ability to trick users into
> downloading and installing trojaned libraries is not something we can
> presently protect against with any mechanism.

Exactly, so don't try to bring it up when it does not even pertain here.

quoted text
> Lets assume that the black magic in userspace was able to spot a
> trojaned library running programs which would still be linked to the old
> files on disk would continue to work but you would very quickly find out
> there was trouble when everything that tried to open its shared library
> was getting EPERM.

But that's not what virus scanners on Linux do!  So again, don't bring
up things that are outside the threat model!

quoted text
> I'm going to run perf test this afternoon but I'm going to have to look
> for a test that is a good mix of reads,writes, and opens.  I strongly
> suspect that there will be a noticable perf lose in any other method
> that doesn't include in kernel caching.  (how can there not be with an
> extra context switch for every open?)

See my earlier comments about this.

thanks,

greg k-h
--
unsubscribe notice
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/