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: <20080815004335.GF13048@mit.edu>
Date:	Thu, 14 Aug 2008 20:43:35 -0400
From:	Theodore Tso <tytso@....edu>
To:	Rik van Riel <riel@...hat.com>
Cc:	Pavel Machek <pavel@...e.cz>,
	"Press, Jonathan" <Jonathan.Press@...com>, davecb@....com,
	Adrian Bunk <bunk@...nel.org>,
	Mihai Don??u <mdontu@...defender.com>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	linux-security-module@...r.kernel.org,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to alinuxinterfaceforon
	access scanning

On Thu, Aug 14, 2008 at 08:00:05PM -0400, Rik van Riel wrote:
> > Yes, that's the part libmalware.so proposal solves. Given scary number
> > of 0 Linux viruses in wild, it seems to solve the problem pretty well.
> 
> If you're trolling, you're not being very good at it.
> 
> Just because you cannot easily infect a Linux system from a
> user application does not mean malware cannot do all kinds
> of damage with user privileges.  Think of a key sniffer (using
> the same interface that the X screensavers use) or a spam bot
> running with user privileges.

But Pavel is raising a good question.  In Eric's proposed threat
model, he claimed the only thing that he was trying to solve was
"scanning".  Just file scanning.  That implies no root privileges, but
it also implied that he wasn't worried about malware running with user
privileges, either.  Presumbly, that would be caught and stopped by
the file scanner before the malware had a chance to run; that is the
execve(2) system call would also be blocked until the executable was
scanned.

So if that is the threat model, then the only thing libmalware.so
doesn't solve is knfsd access, and it should be evaluated on that
basis.  If the threat model *does* include malware which is **not**
caught by the AV scanner, and is running with user privileges, then
there are a whole host of other attacks that we have to worry about.
So let's be real clear, up front, what the threat model is, and avoid
changing the model around to rule out solutions that don't fit the
initially preconceived one.  That's how you get to the TSA
confiscating water bottles in airport security lines.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ