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
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.