linux-kernel - Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode information cache

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] [day] [month] [year] [list]

Date:	Thu, 28 Oct 2010 00:35:07 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Al Viro <viro@...IV.linux.org.uk>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	John Stoffel <john@...ffel.org>,
	Christoph Hellwig <hch@...radead.org>,
	"J.H." <warthog9@...nel.org>, Eric Paris <eparis@...hat.com>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, zohar@...ibm.com,
	david@...morbit.com, kyle@...artin.ca, hpa@...or.com,
	akpm@...ux-foundation.org, mingo@...e.hu
Subject: Re: [PATCH 01/11] IMA: use rbtree instead of radix tree for inode
 information cache

On Tue, 26 Oct 2010, Al Viro wrote:

> FWIW, I'm OK with that.  My general opinion about the quality and
> usefulness of security/* is a separate story, but if we are stuck
> with that shit in the tree, let's at least trim down what can be
> trimmed down.

If you have any specific concerns about code in security/ then please do 
explain them (in a different thread), so we can address them.

Note that if code is not being used, and/or has serious technical issues, 
it can be removed.  This already happened once with the BSD secure levels, 
which was basically unused, unmaintained, and had unfixable security 
issues -- it was taken out and shot.

Unfortunately, we have to deal with the fact that Unix was not designed 
with security primarily in mind, and that the security it does have is 
inherently flawed (all according to Ritchie c. 1970s).  We have to 
maintain decades of backward compatibility, address underlying flaws, and 
also address new forms of security threats which could not have even been 
imagined at the time.  We have to do all this without maybe using more 
than a few extra bytes in any major core data structure, and with nobody 
really agreeing on how to do it.

Expecting perfection out of this process is probably unreasonable, alas.

- James
-- 
James Morris
<jmorris@...ei.org>
--
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/