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

Hi!


> > Proposed kernel solution did not work -- there still was write
> > vs. read race. You are right that it is not ok for each application to
> > do its own malware scanning, but libmalware.so that handles the
> > scanning seems very reasonable.
> > 
> > And as applications _need_ to be modified for the write vs. read race
> > to be solved, libmalware.so looks like a way forward.
> 
> 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.  

As I said, that does not work. Proposed solution blocked open, while
you'd have to block read() and you still could not handle mmap.
So sorry, no kernel solution can work.

> 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
> malware hole.  The only solution that really works is one that

So you make sure all apps are modified. Distros are good at that, and
modifications are not that hard.

Plus, proposed solution already has three unacceptable holes:

1) it only catches known signatures

2) write vs. read race mentioned above

3) mmap problem

. Making sure all apps use libmalware.so is trivial compared to
solving 3).

							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/