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