> On Wed, 2005-11-16 at 15:53, Lamar Owen wrote: > 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. Buffer overflows don't care about programs' assumptions. They are just trying to get root because root can do anything. 'Anything' here means 'grab me a backdoor and hold it open with a rootkit.' >> 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. User!=person. Daemon users are users, too, and any daemon that for some reason (like binding to ports below 1024, or delivering mail to users, or any number of other things) has to run euid 0, should be limited in what it can do to those things it normally does. And the original developer of SELinux really does get 3 people doing one job and actively distrusting each other; this works very well in practice for that particular application. > How many people should it take to do a restore? That has nothing to do with what I'm talking about. > If it is one, that > person ultimately controls what's on your disk. User!=person. A person (the Real Root) running a restore would be treated differently from say sendmail running as root being exploited by a buffer overflow. That is the whole point to SELinux; root!=root under all instances of euid 0. > 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. > Which filesystem(s) and method(s) have you verified? Software RAID1 hotswap (that is, break the mirror, swap out a drive, swap in a new, reestablish the mirror). Doable with many SCSI controllers, including the popular NCR/Symbios family. I keep hotswap carriers for the purpose. The RAID1 mirror is filesystem-agnostic. Cheaper than tape or DVD. When SATA hotswap works will do it with SATA carriers; currently the hardware will allow the hotplug, but the kernel has problems dealing with it. If FireWire or USB drives could reliably join a software RAID, would use that, but those are troublesome. I haven't had trouble with SCSI devices, as long as I do things in order (sync;hotdrop the drive;stop the drive with the SCSI ioctls; pull the carrier (the carriers I use are made by StorCase under the brand 'Data Express'; I have the 68-pin Ultra2 SCSI versions with the bus isolator/repeater cards for true hotswap); push in new drive in carrier;rescan/add the SCSI drive using the SCSI ioctls; add drive to RAID1 and activate). It works, and I've used it. For restoring files, rather than hotadding to the same RAID1 add it to a different md device and mount it as a degraded array. To restore whole disks, the trick is to remember that a RAID1 is not limited to two drives. Works here on my hardware. I have some other controllers that I'm going to try where the break/rebuild is more automatic, but haven't had time to do much with them as yet. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu