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

selinux rant, compressed version (Was Re: kernels won't boot)

On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote:
> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote:
> > I'm not running SELinux enforcing mode on any of my machines..
> That's too bad -- it's hard to gage the usability of a system
> without it on, since it is enabled by default for most people. 

Well, the kernel bits of SELinux is great. The user space bits never
ever worked for me; neither as a user, nor RPM package maintainer and
definitely not as an upstream developer of highly modular software that
is designed to be locked down (e.g. hald and it's helper processes)

Some problems from a 50,000 feet point of view

 - the policy is way too complicated; really, I think it's kinda futile,
   at this point, to attempt to lock down bits that are not even

   As a result someone decided "oh, we're just going to let people turn
   of it". And this is where we are now. Total cop out. Might as well
   not ship it.

   Seriously. Just go ahead and look at the policy. No wonder it often
   doesn't work given it's so complex.

 - the policy is centrally maintained; e.g. the maintainer of the policy
   for hald (Dan Walsh) and, hey, all of the policy often have to guess
   how to lock things down and often, despite Dan being a great
   engineer, these guesses are just wrong. Seriously, no one can blame
   Dan for this - you cannot expect a single person to know all the
   kinks of all the software in Fedora.

   -> Ideally every upstream project can maintain it's own policy. That
      has the nice side effect of, gosh, teaching other distributions
      about the benefits of MCA.

      -> If upstream don't want to include SELinux policy, just include
         it as a patch in the RPM

   Typical responses:
     - "rpm cannot handle SELinux policy": <- bullshit; it's not much
       different from other file meta data; do we store file modes and
       permissions centrally too? No.

     - "uh, then you would have deps on policy": Like, for example, the
       policy for hald would depend on the policy for, say, dbus. Not
       a problem, the real world contains dependencies already and most
       these deps are handled just fine already by the upstream

I'm not even going to go into the language used for defining policy. 

In short, SELinux just doesn't work for me. I'm not denying it may work
well on a tightly-controlled servers where features never change (e.g.


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