On Wed, 2005-11-16 at 15:53, 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.
That's not the only thing affected by SELinux, though. It changes all
the assumptions of any process you let it manage. These programs
may have configurations and data in places that developed over
decades and access patterns that no current sysadmin understands
all working just fine with user/group permissions.
If you have no existing services in place and are starting
from scratch you might not have the same issues.
> No single user should ever have 'do
> everything' rights once the system is running multiuser.
That's fine if you are willing to pay 3 people to do one job and
spy on each other. So far no place I've worked has done that.
> 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.
How many people should it take to do a restore? If it is one, that
person ultimately controls what's on your disk.
> > 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.
There are ways to go wrong with user/group permissions and suid but
things that work don't mysteriously stop working.
> > 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?
Yes, it matters whether or not it affects your system.
> 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.
My experience says don't turn it on while many other users are
frequently reporting surprises. That still seems to be the
case. When the reports of problems become rare and are
answered immediately with the correct response to work around
or avoid the problem, it is time to start thinking about using
code in production.
> > Speaking of backups, have you tested the method you use to make sure
> > it restores the attributes SELinux needs to work?
>
> Yes.
Which filesystem(s) and method(s) have you verified?
--
Les Mikesell
lesmikesell@xxxxxxxxx
