On Wednesday 16 November 2005 15:45, Les Mikesell wrote:
> On Wed, 2005-11-16 at 14:12, Lamar Owen wrote:
> > The main reason I think sysadmins in general seem to hate SELinux is the
> > 'Mandatory' part of 'Mandatory Access Control' : that is, superuser power
> Not exactly. In my case I just realize that there are 30 years of
> history behind expecting all unix access control to be in the
> filesystem in the owner, group and modes of the files.
A single superuser who can do anything is, IMHO at least, the single worst
feature of Unix-like systems. No single user should ever have 'do
everything' rights once the system is running multiuser. Of course, there
should be administrator oversight on making sure that 'someone' can do
'anything' that might need to be done while in multiuser, but some things are
best done in singleuser mode, where a superuser actually makes some sense.
> It will
> take a while to rewrite everything based on different assumptions,
> and meanwhile things will mysteriously not work.
Judging from the contents of many messages to several lists I am on, the
standard permissions system has its own share of 'mysteriously not work'
issues. Yes, with more control comes more responsibility.
> > AND THAT IS A GOOD THING. Yes, it really is. The buffer overflow
> > exploit for those root-running daemons doesn't stand a chance even if it
> > gains root, as long as the selinux policies are set properly.
> We are talking about bugs here. Why are you so convinced that the
> new code you just introduced to enforce this new policy does not
> in fact introduce new bugs?
There will always be one more bug. (There's you a one-liner, Peter Farrow.)
Is the bug in the filesystem? Is it in the policies themselves? Does it
matter where the bug is/will be? Regardless of code maturity, there will be
bugs; it is a red herring to say 'turn it off' because there might be bugs in
it; you might as well never boot at all if you really believe that mindset.
As to why am am convinced about the stability of SELinux in particular, well,
the original developer is known for being thorough in auditing code and
practices. The original SELinux developer wrote the book (which is probably
classified!) on code auditing. The built-in distrust of the original
developer means that more qualified eyes are on this code that virtually any
other major piece of code in the kernel. Is it perfect? No, and will never
be perfect. Is it an improvement over permissions? Yes, and it augments
them nicely.
> Have you watched the changelogs to see if in fact any problems have been
> found and fixed so far?
In a cursory manner, yes.
> > The Real Root should take the time to configure in to the policies those
> > things the Real Root would normally do (you know, things like backups and
> > the like, along with other normal activities),
> Speaking of backups, have you tested the method you use to make sure
> it restores the attributes SELinux needs to work?
Yes.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
