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
<[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
