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: <20080813102802.GC27074@atrey.karlin.mff.cuni.cz>
Date:	Wed, 13 Aug 2008 12:28:02 +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!

> >   Perhaps I could try: the AV folks are trying to prevent the
> > execution of either modified normal binaries/files or
> > specifically exploit binaries/files, by machines for which the
> > files are executable or interpretable.
> > 
> >   The experience of those communities is predominantly
> > with DOS/Windows executables and interpretable files, which
> > they have difficulty generalizing from.
> > 
> >   In principle, they could be targeted at any machine, so any
> > mechanisms should be applicable to native executables and
> > interpretables as well as foreign ones.
> 
> 
> You know, that's actually a very good statement of the model.
> 
> I think everyone understands one side of the threat model, that is Linux machines being carriers of infections aimed at other platforms.  There are many ways that such infections can be stored, and many ways in which they can be communicated to the target machines.  There are so many that it would not be effective or efficient for each such transfer application to be able to handle its own malware scanning, which is the short statement of why centralized AV protection with notification assistance from the kernel is appropriate.
> 

No.

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