selinux rant, compressed version (Was Re: kernels won't boot)
Steve Grubb
sgrubb at redhat.com
Fri Jan 4 01:17:54 UTC 2008
On Thursday 03 January 2008 17:46:51 David Zeuthen wrote:
> > #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
I don't think this is true at all. semodule being slow has nothing to do with
people thinking about security. It takes time and testing a lot of variations
of config options to arrive at what the application is supposed to do. Some
people also may not recognize when an avc means the code needs to change
instead of allowing the behavior.
I think that #4 is the real killer. Dan did a major reworking of policy in F8
to merge what was the strict policy with targeted. The way that roles work
was beefed up. If this had to be coordinated with every single package
maintainer, it probably wouldn't have gotten done as quickly or as uniformly.
> and the fact that the policy is way too big and the whole system is way too
> complicated.
This is more a fact of it telling you that software in general is complicated.
SE Linux is describing the allowed behavior at a level that is slightly above
the syscall level. If the syscalls a program makes change, the policy may
need reworking.
This is probably why you run into problems frequently as you are developing
and testing new code (with new syscalls) that is central to many programs.
I wonder if a tool could be developed to do something like nmap and compare
current syscalls with an older version. It wouldn't be able to track resource
usage (files/sockets), which is another thing selinux regulates, but it could
tell you a little about if a new version is going to have problems. If we
could simply tell that a new package required policy changes, that would be
half the battle.
-Steve
More information about the fedora-devel-list
mailing list