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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
