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

[Alan Milligan < >]

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.

Regards,
Alan