[chef-dev] Re: A compelling selinux narrative ...

Chronological Thread 
  • From: Ranjib Dey < >
  • To: Alan Milligan < >
  • Cc:
  • Subject: [chef-dev] Re: A compelling selinux narrative ...
  • Date: Sun, 29 Apr 2012 11:03:30 +0530

+1 for pushing security context up in the stack (file, template etc). The current options (either use sean's branch or your own monkey patched ones ) are limited (as already mentioned in the thread) only to certain use cases. We have a CI grid setup and we  would love to test out any community supported selinux compatible cookbooks. 


On Sun, Apr 29, 2012 at 10:12 AM, Alan Milligan < " target="_blank"> > wrote:
In order for Chef to play in the enterprise RHEL space, something needs to be done to transparently support selinux in Enforce mode.

Sean Omeara's monkeypatch branch to the selinux cookbook goes quite some way toward meeting this, but it's a rather complex problem.

Whilst this cookbook will apply a selinux label, it will not retain a pre-existing label.  It's default labelling is also not terribly smart (especially for newly created files - where it's quite likely to return nil).

But when enforcement is turned off, the cookbook ignores all selinux labelling altogether.  This means that should one attempt to turn on enforcement at a later date, any file touched by any cookbook almost assuredly has screwed up selinux attributes.

I believe the only solution to this problem is to move selinux management up the stack into template and file providers (for selinux-supported operating systems).  Existing labels should *always* be retained, *unless* you've specified a label.  Better guessing of labels needs to be implemented for new files.  A simple heuristic such as applying the label from another file in the directory, or perhaps the label of the directory itself would prove quite successful.

This way, if one elects to use the selinux recipe at some point, the underlying file-system(s) haven't been irrevocably tainted by chef runs.

There are a range of security considerations around all of this (including what selinux context chef-client should have for example) and I am keen to see an encompassing solution arise from this discussion.  I am willing to contribute patches for such solution.


Archive powered by MHonArc 2.6.16.