> 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
