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: <20080814125410.GA2262@elf.ucw.cz>
Date:	Thu, 14 Aug 2008 14:54:10 +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

Hi!

Okay, so goal of libmalware.so is to "not allow data in the black list
to pass through Linux server". Threat model is windows machines trying
to copy infected files through the server. Viruses are not expected to
have shell access to either root or normal users on the server.

> Big snip since I am really only curious about libmalware.so.
> 
> > Plus, proposed solution already has three unacceptable holes:
> > 
> > 1) it only catches known signatures
> > 2) write vs. read race mentioned above
> 
> Discussions about perfect, better or no security are in danger of becoming 
> boring.
> 
> > 3) mmap problem
> > 
> > . Making sure all apps use libmalware.so is trivial compared to
> > solving 3).
> 
> You haven't answered what exactly is this libmalware.so, since you are the 
> only one mentioning it? It would be interesting to learn how it solves the 
> mmap problem, provides perfect security so it is acceptable, handles the 
> kernel NFS server serving malicious files, caters for applications which 
> do not use it, is better (more secure) than the kernel solution, provides 
> reasonalbe performance and is easier to maintain for the community? To 
> list only some of the requirements which have been mentioned so far.

mmap problem: libmalware.so would not offer mmap() to applications (or
maybe it would do copy of the file, then allow mmap on the copy).

kernel NFS server is not handled; don't use it for serving Windows
clients. Not that you need performance for that, anyway.

Obviously libmalware.so will not help applications not using it. With
distributions, that's not a problem.

Unlike kernel solution, it does not contain races with read/write/mmap
-- untrusted files access is made through methods that can be safe.

You can query helper daemon for cache info; that should provide good
enough performance.

I never claimed it is easier to maintain than kernel solution; but
unlike kernel solution it actually _works_, 100% of time, for apps
using it.
								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/