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
network-facing.
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
projects.
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.
RHEL).
David
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
