> 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