Re: Security fix for remapping of page 0 (was [PATCH] Change ZERO_SIZE_PTR to point at unmapped space)

Linus Torvalds
2009-06-03T16:44:54Z

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