If you’ve been following along with me, I’ve been doing my best to test out SELinux in it’s various forms. To sum up, I have installed Debian Etch into a virtual machine (VM) along with X and the XFCE4 desktop (due to limited RAM). Immediately following this, I began following the Debain SELinux howtos and successfully got the “targeted” SELinux policy installed and enforced without incident. Now, I’ve migrated to the “strict” policy and, much to my surprise, nothing has broken. I figure, this can mean one of two things…Either SELinux is so well implemented that it knows how to interfere only when appropriate or I’ve done something wrong and haven’t yet realized it yet. In fear of the latter option, I’ve been desperately searching for an error but have found none thus far. Which, is very promising considering that security *should not* be so difficult that no one will attempt to improve or implement it. On the topic of easier security integration, I have been working on an idea involving better SELinux policy management in Linux distros such as Debian. What if every package could somehow contain the relevant policy information files which could then be copied to the SELinux policy source directory. The idea is that when a machine is being setup, the policy files would be automagically added to the source tree. Then when the configuration is complete, the policy could be compiled and loaded. Any subsequent changes would, naturally, alter the source tree and require a recompile. However, because SELinux policies are versioned by default, changes should be easy to track. I’m still on the fence about whether the policy files should be self contained within a package or whether they should be included by some sort of conditional dependency mechanism in the package tree itself. For example, the apache-selinux package is only required if both the apache and selinux packages are both installed. Although, this might not be possible; apparently, software dependency resolution is an NP-hard problem (go figure).