[CentOS] SELinux threads, cynicism, one-upmanship, etc.

[Lamar Owen]

> But hardly anything runs as root all the time anymore.   What it affects
> instead is all the carefully crafted suid-so-you-can-run-under-cgi
> programs that have a myriad of users with different file areas all
> under the same httpd process that have taken years to get right - and
> now they break under SELinux because it isn't just filesystem
> permissions involved.

And they are broken.  SELinux serves a valid need; at least in Red Hat's
opinion.  I happen to share that opinion.

SELinux didn't break the programs to which you refer; your description
pretty much says outright that they are broken.  Seems to me the purveyors
of such programs need to learn to work within the system as it stands; but
then again web-based administration ala Webmin isn't the most secure thing
in the world to begin with.  But that's somewhat philosophical, and
certainly quite off-topic.

What is on-topic is the simple fact that CentOS ships with SELinux on by
default; this is the way things are, whether you or I like it or not.  I
happen to like it; YMMV.  I quite strongly disagree that the answer to
SELinux problems should be 'turn it off' as this is the lazy way out.

> Yes, but it took years to get the uid/permission/limits right with one
> model and it will take more to overlay that with another layer.  It
> isn't that it's a bad idea, it just isn't practical to drop into a
> working complex system.

Yet it has been dropped into a working complex system, and apparently it
is working fine for lots of people (myself included).  There have been
issues, certainly (the closest one to me was the PostgreSQL initdb-related
one; simple enough to fix once you are aware of it).  Turning it off isn't
the answer; learning to live with it and learn to use its strengths is the
answer.  It is Red Hat's default; thus it is (at least has been) CentOS's
default.  The targeted policy works pretty well most of the time, and it
isn't too difficult to work with.  I think it's pretty cool to restrict
what a program can do beyond the very coarse-grained user-based
permissions.

Deny by default; allow only what is needed.  If every single program and
process in the system were to follow that simple mantra, viruses and worms
simply would cease to exist.

> The ones to worry about are ssh and login.  Sendmail hasn't had an
> exploit in a long time and only runs as root to open port 25.  How
> can SELinux determine that it is or isn't me logging in?

If through ssh or by command line login, it can't.  But it can present
restrictions on what can be done once you are logged in; once you
configure them.  But, as it has already been observed, password-based ssh
login is passe anyway, RSA/DSA-only auth is the way to go.  Carry your
keys on that USB key for use.

However, other things run as root:
samba
syslog
various RPC daemons
xinetd
cupsd
portmap
httpd starts as root and leaves a process running as root (at least on
this CentOS4 box).

What some seem to not realize is that perhaps much of the permissions
spaghetti we have now could be avoided entirely (I'm thinking local mail
delivery for one, print spooling for another, CD recording, USB devices,
etc....) with SELinux policies.

>> > Which filesystem(s) and method(s) have you verified?

>> Software RAID1 hotswap (that is, break the mirror, swap out a drive,

> But how can you scale that?  I've got a dozen machines being backed up
> to tape with amanda and 30 or so by backuppc.

You asked what I used and if I had verified it.  I answered the question. 
I have a smaller number of boxes to deal with; they are large boxes in
some cases (14 CPU Sun E6500 with 16GB RAM for one running Aurora Kashmir)
but a smaller quantity.  I have a mere 25 or so, and most are Windows
boxes storing stuff on the main fileserver, which has the RAID1 trick
being used.

In most cases the portions that SELinux is dealing with aren't necessary
to backup in the first place.  I want to protect user's data using
backups; star seems capable of doing that easily enough with EA support. 
But even then a restore and relabel for non-EA backups of user data isn't
likely to be a real problem.  And programs can be restored with other
methods.

SELinux is at its best preventing programs from opening unauthorized
network sockets or listening on unauthorized ports, or enforcing read-only
access to certain portions of the file system from non-interactive
programs, etc.

Special policies for yum, for instance, could be written to allow yum to
do its work but not allow other programs run from the root shell to
overwrite essential things in areas like /bin, /sbin, /lib/modules, and
/boot.  Rootkit Prevention 101: read-only system files.  System Updating
101: frequent updates.  But how do you allow updates while making your
system files read-only?  My understanding of SELinux is that it can do
this, with the proper policies in place.  This cannot be done using
traditional permissions without wierd things being done (although SELinux
might qualify as a wierd thing in your book... :-)).

But the fact again is that this discussion is pretty pointless in light of
the fact that CentOS does ship with SELinux; the default is targeted and
enforcing, and that this behavior is desirable for the upstream
distributor (and CentOS has thus far had a policy of remaining close to
the upstream distributor).
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu