linux-kernel - Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon 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: <20080813072859.752a4819@infradead.org>
Date:	Wed, 13 Aug 2008 07:28:59 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	tvrtko.ursulin@...hos.com
Cc:	"Adrian Bunk" <bunk@...nel.org>, davecb@....com,
	"Greg KH" <greg@...ah.com>,
	"Press, Jonathan" <Jonathan.Press@...com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	malware-list@...ts.printk.net,
	"Mihai Don??u" <mdontu@...defender.com>,
	"Pavel Machek" <pavel@...e.cz>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon
 access scanning

On Wed, 13 Aug 2008 15:16:12 +0100
tvrtko.ursulin@...hos.com wrote:

> Arjan van de Ven <arjan@...radead.org> wrote on 13/08/2008 14:54:01:
> 
> > > I am not sure what you are suggesting, and I may have missed the
> > > libmalware proposal (I don't see any mention of that specific
> > > idea in any other message).  However, just to be clear...  At no
> > > point did we suggest that the kernel would do any scanning.  What
> > > we have been interested in is a mechanism that can allow a
> > > scanning application to be notified by the kernel of specific i/o
> > > events, for those events to be blocked by the kernel until a
> > > user-space scan is done, and then the user-space scan sends back
> > > allow or deny, at which point the i/o event returns to the caller
> > > -- either success or error.  This is the only way that malware
> > > can be guaranteed of being detected when it is used (for local
> > > application purposes or for transmission to another platform) or
> > > created. 
> > 
> > this is a very broad statement that ignores the LD_PRELOAD approach,
> > and thus not true.
> 
> LD_PRELOAD does not solve at least knfsd and suid binaries. But we
> are going in circles. :)
>  
> > > Also, a solution that requires applications to be modified will
> > > not work, because there is no way that we would be able to get ALL
> > > applications on the machines to be modified in the required
> > > ways.  If ANY applications are not so modified, then you have an
> > > unacceptable
> > 
> > you don't need to modify applications to make them use a library...
> 
> Same is true for a kernel solution. Plus, it also works for those who
> make system calls directly, knfsd and suid binaries, and we can have
> cheap and ultra-efficient caching. Not much kernel code, even less
> complex kernel code and unmeasurable impact when not used and
> compiled in. What are the big technical objections to that?
> 

the biggest objection is the lack of security model description.
STILL nobody has answered Ted's questions.

And still the AV side of the argument keeps making circular arguments.


I'm not saying the kernel shouldn't be involved at all.
I can totally see a solution where we have a
sys_virus_scan(int fd)
that glibc calls at appropriate places (say every read() and mmap())
and that on the kernel side uses a cache to store which virus signature
version it was last scanned with, and if not new enough.. punts to some
userspace scanner for vetting.

but first someone needs to answer Ted's very basic questions or the
TALPA side really does look like a donkey in this argument.





-- 
If you want to reach me at my work email, use arjan@...ux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/