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

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

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.


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