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]

Date:	Thu, 14 Aug 2008 14:56:13 +0200
From:	Pavel Machek <pavel@...e.cz>
To:	tvrtko.ursulin@...hos.com
Cc:	Arjan van de Ven <arjan@...radead.org>,
	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>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a
	linuxinterfaceforon access scanning

On Wed 2008-08-13 15:16:12, 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. :)

Yes, there are about 5 suid binaries on typical linux system. Link
them to libmalware by hand.

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

That is does not work?

(Neither does LD_PRELOAD; it still has the old mmap problem. Too bad,
but at least you get 99.9% coverage of all the apps). 
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/