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]

Date:	Wed, 06 Aug 2008 11:41:47 -0400
From:	Eric Paris <eparis@...hat.com>
To:	Greg KH <greg@...ah.com>
Cc:	tvrtko.ursulin@...hos.com, linux-kernel@...r.kernel.org,
	malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface
	for on access scanning

On Wed, 2008-08-06 at 08:25 -0700, Greg KH wrote:
> On Wed, Aug 06, 2008 at 10:37:06AM +0100, tvrtko.ursulin@...hos.com wrote:
> > Greg KH wrote on 05/08/2008 21:15:35:
> > 
> > > > > > Perf win, why bothering looking for malware in /proc when it can't
> > > > > > exist?  It doesn't take longer it just takes time having to do
> > > > > > 
> > > > > > userspace -> kernel -> userspace -> kernel -> userspace
> > > > > > 
> > > > > > just to cat /proc/mounts, all of this could probably be alliviated 
> > if we
> > > > > > cached access on non block backed files but then we have to come 
> > up with
> > > > > > a way to exclude only nfs/cifs.  I'd rather list the FSs that 
> > don't need
> > > > > > scanning every time than those that do....
> > > > > 
> > > > > How long does this whole process take?  Seriously is it worth the 
> > added
> > > > > kernel code for something that is not measurable?
> > > > 
> > > > Is it worth having 2 context switches for every open when none are
> > > > needed?  I plan to get numbers on that.
> > > 
> > > Compared to the real time it takes in the "virus engine"?  I bet it's
> > > totally lost in the noise.  Those things are huge beasts with thousands
> > > to hundreds of thousands of context switches.
> > 
> > No, because we are talking about a case here where we don't want to do any 
> > scanning. We want to detect if it is procfs (for example) as quickly as 
> > possible and don't do anything. Same goes for any other filesystem where 
> > it is not possible to store arbitrary user data.
> 
> See previous messages about namespaces and paths for trying to figure this
> kind of information out in a sane way within the kernel.

Didn't I already go over this?  The patch for FS exclusions would not be
namespace based, rather  dentry->d_inode->i_sb->fstype->name matching.

Lets not start name based discussions at this point in time.  Those
patches weren't proposed on this go and reading the write up of both of
the name based items (I think number 11 and 12) one I outright reject
and the other will require future discussion.

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