Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

[James Morris <jmorris@namei.org>]

On Tue, 18 Apr 2006, Crispin Cowan wrote:

> >> SELinux has NSA legacy, and that is reflected in their inode design: it
> >> is much better at protecting secrecy, which is the NSA's historic
> >> mission.
> >>     
> > No.  The inode design is simply correct.
> >   
> "Correct" for what? inode access control is correct if data secrecy is
> your number one objective. It is not necessarily correct for other purposes.

It's correct for deterministically and safely applying security policy 
when accessing a file.

With pathnames, there is an unbounded and unknown number of effective 
security policies on the system, as there are an unbounded and unknown 
number of ways of viewing the files via pathnames.

> > What if Unix DAC security was implemented via pathnames, using a 
> > configuration file and regexp matching enginer in the kernel, invoked 
> > during file access, rather than the existing scheme of checking inode 
> > ownership and permission attributes?
> >   
> What of it? That sounds very close to the AppArmor design, except for
> the "discretionary" part. Just what is wrong with it? If your main
> complaint is that you would miss having chmod and umask, then I agree:
> we are not proposing to remove classic DAC. So what's your point?

The point is to illustrate the basic AppArmor mechanism, using a security 
model which people already know and understand.


> > SELinux labels objects directly because it's the right thing to do.
> >   
> Security design by Wilford Brimley: emphatic assertion :)

As Arjan already pointed out, pathname security doesn't work for:

* hardlinks
* chroot
* namespaces
* bind mounts
* unlink of open files
* fd passing over unix sockets
* relative pathnames
* multiple threads (where one can unlink+replace file while the other is
  in the validation code)


Direct object labeling is the only mechanism which allows you to perform 
reliable access control checks against those objects.


> However, I assert (emphatically :) that the broader user community has
> integrity and availability as higher priorities than secrecy, and that
> pathname-based access control is a better way to achieve that.

Integrity control is a fundamental aspect of SELinux, implemented via Type 
Enforcement.  Please refer to:

  W. Boebert and R. Yain. "A Practical Alternative to Hierarchical 
  Integrity Policies." In Proceedings National Computer Security 
  Conference, 1985.


> I want to offer Linux users the choice of pathname-based access control 
> if they want it. Why do you want to prevent them from having that 
> choice?

My opinion is that it's fundamentally broken as the core mechanism of an 
access control mechanism, although there are places where it can make 
sense.

All I'm doing at this stage is responding to your comments on SELinux, as 
unfortunately, from prior experience, if they go unchallenged, many people 
will believe them to be correct.



- James
-- 
James Morris
<jmorris@namei.org>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/