Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfacefor on access scanning

[Eric Paris]

On Mon, 2008-08-04 at 20:26 -0400, Christoph Hellwig wrote:
> On Mon, Aug 04, 2008 at 03:32:49PM -0700, Greg KH wrote:
> > >   1. Intercept file opens (exec also) for vetting (block until
> > >   decision is made) and allow some userspace black magic to make
> > >   decisions.
> 
> NACK, this kind of policy should be done in kernelspace.

What?  You want to write and in kernel scanner for Window viruses?

> 
> > >   2. Intercept file closes for scanning post access
> 
> Not  even possible for mmap, and dumb otherwise, NACK.

I don't know when files get closed and can't preemptively scan to make
sure it is clean for the next open?  Any writes are going to invalidate
the allow/deny cache....

> 
> > >   6. Scan files directly not relying on path.  Avoid races and problems with namespaces, chroot, containers, etc.
> 
> Explain? 

The data connected with the file being opened must as reasonably as
possible be the data the 'scanner' looks at.  Some foolish early
discussion wanted to do simplistic things like pass a pathname to a
scanner and have it call open on that path name.  I'm willing to
entertain any other method of making the scanner look at the data the
process is about to get.

> 
> > >   9. Mark a processes as exempt from on access scanning
> 
> Nack, this completely defeats the purpose.

What? it allows a process to open a file that contains malware, how is
that horrible.  If a process says "I want to see malware" it can then
see malware.  Doesn't in any way affect other processes or the system
security as a whole.  If 'bad' data gets into a file its going to get
blocked from everything that doesn't actively choose to see it.

> 
> > >  11. Exclude sub-trees from scanning based on filesystem path
> > >  12. Include only certain sub-trees from scanning based on filesystem path
> 
> Nack, please no pathname based idiocies.

Go read the long explainations, I already rules out path based
inclusions.  I'm leaving exclusions up for grabs since I don't see it
weakening the security model.

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