linux-kernel - Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE

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: <alpine.LFD.2.01.0906030936350.4880@localhost.localdomain>
Date:	Wed, 3 Jun 2009 09:44:30 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Eric Paris <eparis@...isplace.org>
cc:	Christoph Lameter <cl@...ux-foundation.org>,
	"Larry H." <research@...reption.com>, linux-mm@...ck.org,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Rik van Riel <riel@...hat.com>, linux-kernel@...r.kernel.org,
	pageexec@...email.hu
Subject: Re: Security fix for remapping of page 0 (was [PATCH] Change 
 ZERO_SIZE_PTR to point at unmapped space)

On Wed, 3 Jun 2009, Eric Paris wrote:
> >
> > We probably should, since the "capability" security version should
> > generally essentially emulate the regular non-SECURITY case for root.
> 
> Will poke/patch this afternoon.

Btw, a perhaps more interesting case would be to _really_ make the 
"!SECURITY" case just be essentially a hardcoding of the capability case.

Right now the Kconfig option is actually actively misleading, because it 
says that "if you don't enable SECURITY, the default security model will 
be used". 

And that's not automatically true, as shown by this example. You can 
easily get out of sync between security/capability.c and the hardcoded 
non-security rules in include/linux/security.h.

Wouldn't it be kind of nice if the "security/capability.c" file would work 
something like 

 - make the meat of it just a header file ("<linux/cap_security.h>")

 - if !SECURITY, the functions become inline functions named 
   "security_xyz()", and the header file gets included from 
   <linux/security.h>

 - if SECURITY, the functions become static functions named "cap_xyz()", 
   and get included from security/capability.c.

IOW, we'd _guarantee_ that the !SECURITY case is exactly the same as the 
SECURITY+default capabilities case, because we'd be sharing the source 
code.

Hmm? Wouldn't that be a nice way to always avoid the potential "oops, 
!SECURITY has different semantics than intended".

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