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
Archive powered by MHonArc 2.6.16.