On Wed, 2005-11-16 at 21:41, 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.'
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.
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.
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.
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.
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?
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.
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.
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 do a raid sync to an external firewire of the backuppc drive (which otherwise is next-to-impossible to copy because of all the hardlinks) weekly, but I wouldn't want to to that for every box running any services.
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.
I've done this to repair on-line raids but I've also had machines crash when hot-swapping SCSIs. Not often, but its enough of a risk that I wouldn't do it to a production machine unless something was already broken.
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.
You can actually mount the underlying partition of the md raid1 directly. I can mount my backuppc mirror in my laptop (where I also have backuppc installed) and restore from there. But it isn't going to deal with those extended attributes because the actual copies are done with tar and rsync.