SELinux threads, cynicism, one-upmanship, etc.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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@xxxxxxxxx



[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux