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: <20080813141618.696833764EA@pmx1.sophos.com>
Date:	Wed, 13 Aug 2008 15:16:12 +0100
From:	tvrtko.ursulin@...hos.com
To:	Arjan van de Ven <arjan@...radead.org>
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

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?

--
Tvrtko A. Ursulin
Senior Software Engineer, Sophos

"Views and opinions expressed in this email are strictly those of the 
author.
 The contents has not been reviewed or approved by Sophos."
 

Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.

Company Reg No 2096520. VAT Reg No GB 348 3873 20.

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