linux-kernel - Re: Preview of changes to the Security susbystem for 2.6.36

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]

Date:	Mon, 2 Aug 2010 08:24:21 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	James Morris <jmorris@...ei.org>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	Christoph Hellwig <hch@...radead.org>,
	Al Viro <viro@....linux.org.uk>,
	Kees Cook <kees.cook@...onical.com>
Subject: Re: Preview of changes to the Security susbystem for 2.6.36

On Mon, Aug 02, 2010 at 12:18:46PM +1000, James Morris wrote:
> On Fri, 30 Jul 2010, James Morris wrote:
> 
> > One issue which needs to be addressed is to confirm that there is 
> > consensus on the new Yama LSM module.  I had thought there was, based on 
> > list discussion, but have since had differing feedback.
> 
> I'm going to revert the Yama stuff for 2.6.36 -- Christoph has nacked it 
> to me off-list.

I'm also happy to do it on-list, but I really didn't want to do it
before I've actually validated the patches in your tree still are the
same that were objected before.

As mentioned a few times during the past discussion moving broken
code into a LSM doesn't magically fix it.  In fact YAMA is not any kind
of (semi-)coherent security policy like Selinux, smack or similar but
just a random set of hacks that you didn't get past the subsystem
maintainers.

Al gave you some very clear advice how a the sticky check should be
done for symlinks (if we need it at all, which I tend to disagree with),
and the ptrace check completely breaks crash handlers that we have
in all kinds of applications.  If you can get it into the main ptrace
code past Roland and Oleg that's fine, but just pushing it out into
a tree that has percieved easier merge criteria doesn't work.
--
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/