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: <20080806014435.GF8224@mit.edu>
Date:	Tue, 5 Aug 2008 21:44:36 -0400
From:	Theodore Tso <tytso@....edu>
To:	Rik van Riel <riel@...hat.com>
Cc:	Eric Paris <eparis@...hat.com>, Greg KH <greg@...ah.com>,
	Al Viro <viro@...IV.linux.org.uk>,
	"Press, Jonathan" <Jonathan.Press@...com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, malware-list@...ts.printk.net,
	linux-security-module@...r.kernel.org
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro
	toalinuxinterfaceforonaccess scanning

On Tue, Aug 05, 2008 at 08:46:00PM -0400, Rik van Riel wrote:
> My real worry is that the anti-virus companies have been working
> with an enforcement policy that has been evolving slowly from the
> DOS days, while today's threat model has changed considerably.

... and which also doesn't into account some of the facilities which
Linux has, that DOS/Windows does not have.

Part of the problem I suspect is that the AV folks have managed to get
CIO's believe that all computer systems need to have anti-virus
software, of the same design that is needed for DOS/Windows systems.
This state of delusion is so bad that apparently some AV engineers
aren't even willing to reason from first principles what is necessary
or not to maintain a secure system.

And arguably, if the goal is security theater, much like the security
lines in airports, perhaps it doesn't matter.  If there are silly
CIO's that are willing to pay for such a thing, regardless of whether
or not it is actually *necessary* to maintain security, one school of
capitalism would say it doesn't matter if it actually provides any
functional value or not.

On the other hand, it seems pretty clear there are plenty of LKML
developers who aren't buying it.  :-)

It may be helpful to separate the threat model into at least three
different scenarios:

	The Linux Desktop (where clueless users may be tricked into
		running malware).

	The Linux File Server (where it is *highly* unlikely to have
		active running malware, since there are no clueless
		users running on said file server), but where malware
		may be stored and read over CIFS, NFS, etc.

	The Linux Mail server is really a restricted case of the Linux
		Fileserver; where the only way in is SMTP, and the
		only protocol out is IMAP/POP.  

Clamav arguably does a very nice job for the third case.  And the
number of ways in and out for a Linux fileserver is sufficiently small
(and there are no clueless users to start the malware program
running), that it's relatively easy to reason about.

In the Linux Desktop case, you do have to worry about clueless users,
but in general you don't have to worry about serving CIFS or NFS on
such boxes.

It seems that the AV folks are trying to argue for a worst case
scenario --- one where you have a clueless user, *and* you have a root
comproise, *and* it is also simultaneously serving as a high output
fileserver.  #1, I think it is questionable whether this is a
reasonable model, and #2, if root is compromised, no amount of
scanning software will helpyou, since the malware can simply directly
attach and disable the scanning software.

But it is specifically this sort of threat analysis and explicit
detailing of the assumptions of what capabilities the attacker has
which is critical for proceeding.  The fact at least one AV engineer
thinks it's pointless to do this sort of low-level design is
disappointing.

						- 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