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

[David Zeuthen]

On Thu, 2008-01-03 at 17:07 -0500, Daniel J Walsh wrote:
> Well there are several problems with allowing the individual maintainers
> manage their own policy.
> 
> #1 they won't.
> #2 when they do, they do a very bad job of it.  Or basically just end up
> with unconfined_t.
> #3 The tools are too slow.  Having 100 semodule -i will cause the
> installation to take for ever.
> #4 Interaction between confined domains does not work well when multiple
>   maintainers writing policy.
> sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver,
> pyzor ... All interact in very complex ways.
> #5 conflicts on file_context directories/files

See.. cause and effect.. #1 and #2 are the effects of #3 and the fact
that the policy is way too big and the whole system is way too
complicated.

Besides.. I have asked probably more than ten times (both electronically
and in person) about maintaining the selinux policy for hal in the
_upstream_ tarball but I've always been told that it's not possible or
I've been told to wait. In the meantime it's business as usual; things
are broken and people turn off SELinux.

Here's a challenge:  Send me a patch against the hal git repo and the
RPM spec with the SELinux bits... Then I'll be happy to maintain it;
including spending time on learning SELinux well enough to do a good
job. Is this even possible? Should it be possible?

> David, You are writing an application that is trying to do things on
> behalf of the user as root.  These activities will cause conflicts and
> need to be well controlled.  So you are likely to run into problems with
> SELinux.

Sigh. Do you really honestly think this is a good answer for upstream
maintainers that are _willing_ to help?

     David