[Novalug] October Talk -- SELinux for your (grand)parents

[Paul W. Frields]

On Tue, Sep 28, 2010 at 07:19:04PM -0400, James Ewing Cottrell 3rd wrote:
>   On 9/28/2010 11:15 AM, Paul W. Frields wrote:
> > Actually, the percentage of people disabling has dropped significantly
> > since it was introduced.  (Most people disable because a Random Person
> > on the Internet tells them so, although it's almost never necessary.)
> > Our smolt statistics show about 56% have it enabled nowadays, and that
> > probably includes a lot of older boxes.
> 
> First, let me say that the current versions of RHEL/Fedora/CentOS
> abstract and water down SELinux to the point where the
> out-of-the-box version is almost invisible to most users. You only
> need to tweak a few settings if you run the services that are
> unsecure, such as FTP and NFS, maybe TFTP as well.

Water down?  Not really, IME.  The policy is *tuned* (it's actually
quite a bit of work) to be effective yet sensible for most users.  And
agreed, I find I only have to tune a few things when I run services,
and they're the things that make sense (like allowing my web server to
send out email).

> But what is smolt? Is that the software that mails off your 
> configuration to somewhere right after installation? Given that you 
> don't get the opportunity to actually manually disable SELinux, all your 
> non-kickstart reports are going to mention it as being enabled.

http://smolts.org
https://fedorahosted.org/smolt/
http://www.google.com/search?q=smolt

Smolt reports monthly by default.  Records in the database will show
the current setting, not the setting after installation.  If I disable
SELinux, the smolt record will show it as disabled.

> > Almost no one needs to disable, and when you do so, if you re-enable
> > it later you will have problems because of the disablement.  You can
> > switch SELinux to 'permissive' mode to avoid these future problems,
> > yet be able to run things unsafely.
> By your logic later on, a relabelling ought to fix things.

Absolutely correct!

> Or simply modify the kernel to let any process do a setuid(nobody).

Yikes, which would then break all sorts of things like cgroups, using
which processes can be more effective tracked/audited and all sorts of
performance quota'd based on system policy.  Not to mention all sorts
of security concerns here.

> Or better yet, treat Users like Networks. Each user gets a subuser mask, 
> and can setuid any to any user within their
> user network (as well as extend the subusermask). Log me in with a UID 
> of 654.0, and allow me to setuid to 654.1 thru 654.255. Works for FM and 
> TV stations.
> 
> User.0 can access anything within user.x, but not vice versa, nor can 
> subusers setuid back. User ownership equivalance is tested for by anding 
> the subusermask with the object owner and comparing it to the existing UID
> 
> When userspace is exhausted, we can create Userv6  :)

Again, I would think this is a security nightmare in terms of
satisfying common audit requirements.

> Oh, and By The Way, while SELinux CAN be user to keep your clients out 
> of each other's hair, so far it's only used for Servers, not Clients? Or 
> are you saying that's changing?

I'm not sure there's a distinction to be made here.  Your local system
processes are affected by it whether or not they're services for
someone else or just things you use locally.

> But seriously....look how easy it is to come up with Rational, even 
> Beautiful Alternatives without pissing all over the filesystem.

Given the above concerns, I must differ with the qualification of
"easy." :-)

> > I have several systems in the house that are used by my family
> > exclusively and they are all SELinux enabled.  I know from personal
> > experience that it's rare to have any problems with SELinux, and on
> > those rare occasions I find a relabeling fixes everything.
> >
> > This is a truly worthwhile technology, and personally I'd be leery of
> > advice from someone who tells me to simply disable it for expediency's
> > sake.
> I would also be leery of random people on the Internet telling me I was 
> Dangerously At Risk without the latest and greatest Security Technology.

Hardly latest and greatest -- SELinux was introduced something like 6
years ago.  Compared to UNIX, sure it's the new kid on the block.  But
in terms of being tried and true, SELinux is an incredibly mature
technology, in use in thousands of major Linux installations (not
counting the millions of home users using it unaware), most
importantly places where security is Not Shrugged At. ;-)

> P.S. You didn't answer My Big Question either, altho in fairness, it 
> wasn't directed to you specifically. Do all vendors use The Same Labels 
> on The Same Files? I want my Filesystems to be used by several different 
> OS, possibly at the same time.

SELinux is not vendor-specific, certainly not Fedora or Red Hat.  The
upstream is a collaborative project that involves Linux vendors,
government folks, and commercial interests.  Vendors should be
shipping the same policy packages, and as a matter of security
shipping the latest ones, although there's obviously no way to force
that to happen in every case.  You'll have to look at the distros you
use to see whether they're doing their part.

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
          Where open source multiplies: http://opensource.com