[CentOS] SELinux threads, cynicism, one-upmanship, etc.
lesmikesell at gmail.com
Thu Nov 17 05:49:17 UTC 2005
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
> 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
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
> 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
> 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
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.
lesmikesell at gmail.com
More information about the CentOS