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

[Paul W. Frields]

On Thu, Sep 30, 2010 at 11:13:42AM -0400, James Ewing Cottrell 3rd wrote:
>   On 9/30/2010 9:14 AM, Paul W. Frields wrote:
> > 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.
> 
> Hmmm, I didn't realize that. I don't mind sharing my configuration with 
> you ONCE, but I'm not sure I want a daemon sending all my configuration 
> For All Time.

The information gets more sensitive over time?

> > Absolutely correct!
> 
> Right, but you did mention that if you turned it off, it might screw 
> things up.

If you don't relabel, it does.  Not everyone knows how to relabel, and
frequently they take the "guru" advice of disabling SELinux without
knowing how to effectively prepare for re-enabling.  That's why
staying enabled and simply switching the mode to permissive is an
improvement -- it avoids the whole problem, for the people who really
must run without an enforced policy.

> >> 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.
> 
> cgroups? Never heard of them. Just googled them. I don't like them either.
> 
> Remember DMR's design criteria? It's just as important what was left out 
> as what was put in.
>
> I don't like quotas either. And if you want Performance, get your own 
> machine.

OK, fortunately you're able to choose and run old technology as long
as you like.  I'll be over here working with new stuff that's being
developed to meet real business challenges and conquer the world. ;-)

> > Again, I would think this is a security nightmare in terms of
> > satisfying common audit requirements.
> 
> Why? Users can create subusers, where each subuser has less privileges 
> than their parents. Privileges can only be restricted, not expanded. 
> This is equivalent to what the original setuid system call does, except 
> that we generalize in to regular users as well.
> 
> The netmask idea gives a way to specify the relationship between users 
> and subusers numerically, as well as a method of checking permissions in 
> a computationally easy way. Auditing wise, they are all the same
> user.

I'm not sure how that solves the problem when you have daemons running
as root.  Even if that weren't a problem, this scheme seems far more
complex both in terms of implementation and user tooling, and I saw
elsewhere in the thread you were arguing for less complexity, but
forgive me if I got that wrong.

> >> 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.
> Yes, but the targeted policy only affects Server Processes, not client 
> processes, right?

Not in every case, and keep in mind SELinux is also a framework and
the targeted policy is simply one implementation of policy.  For
instance, wrapped Firefox plugins on the browser client have policy
applied.

> But you know, Servers are actually comparatively EASY to configure. In 
> fact, some servers run Everything as root, and
> just chroot the services they are worried about. The examples being used 
> here are Clients.

Servers running as root is a case SELinux is specifically designed to
handle better.  But maybe I'm missing your point here.

> Guess what? I am tempted to say that if my IM client messes up steals my 
> browser passwords, It's My Own Fault! But sooner than later I, or most 
> likely some non-technical user will be tricked by some seductive but 
> malicious code, and there will be a problem.
> 
> But subusers would solve that. When I log in, I would be 654.0, my IM, 
> would be 654.1, and browser would be 654.2. I (654.0) could write each 
> of their files, but they could only write their own. Simple to
> understand.
[...snip...]

I wonder if SELinux sandboxing is already answers this need.  Honestly
I don't know that much about it but the little I know seems to point
in this direction.


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