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: <1217897224.27684.66.camel@localhost.localdomain>
Date:	Mon, 04 Aug 2008 20:47:04 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	Greg KH <greg@...ah.com>, 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 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/