On Mon, Jul 13, 2015 at 1:46 AM, S. Lockwood-Childs <s...@dent.vctlabs.com> wrote: > I'd appreciate feedback on a blog-style article[1] talking about > how CIL is going to improve SELinux policy maintenance, and in > particular, the last section where I try to point out how good Gentoo > is for experimenting with SELinux technologies. The article is > maintained as an rst file in github[2], so corrections/additions > could be submitted as a pull request if desired (though plain old > mailing list replies are equally welcome). > > [1] http://vctlabs.com/posts/2015/Jul/12/selinux_cil/ > [2] > https://github.com/VCTLabs/vct-web/blob/master/content/articles/selinux_cil.rst
It's always nice to see posts on SELinux and Gentoo. Some points of attention though. The commercial usage isn't hindered by the three bullet points you mention (not that those bullet points are wrong). It's hindered because the policy implementation that is currently used (and I don't mean this demeaning towards the policy) focuses on fine-grained access controls with a rigid almost peer-reviewed process for policy enhancements, and is meant to be fully encompassing. Any commercial product owner who wants to support his application in a SELinux-enabled system would need to provide a policy that matches the principles of this policy. Sadly, this is extremely difficult, especially when the product can be used in a very broad manner. Try creating a policy for an Oracle DB within one company and then reuse it in another company. Developing policies means to get (and expose!) insights in how a product works (and also doesn't work). Although this information can be retrieved from profiling the application, many companies do not want to "fix" their product behaviour within a policy. Products evolve, and policies should evolve with them, but most product development does not hold any roles for security policy developments. Hell, many product vendors don't even have a nice overview of the firewall rules needed to get their product components to interact with each other. Let alone a policy approach. The third bullet in your overview (poor support for preserving local changes) might need more explanation. Local changes can be semanage changes, and can be policy changes. Locally made semanage changes can be exported/imported using "semanage export" and "semanage import", and policy changes - well, those will require a software management or configuration management system anyway. Not even CIL would simplify this. Wkr, Sven Vermeulen
