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.
--
Les Mikesell
lesmikesell at gmail.com