A compelling selinux narrative


#1

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


#2

+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 <
alan.milligan@last-bastion.net> 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.

Regards,
Alan


#3

I haven’t looked at the monkey patch branch…

How well does chef (and ruby) handle overrides? Would it be possible to
have a cookbook resource provider override the file provider in a way that
template uses it? Could add handler code to grab the current label, call
out to the overridden parent, then restore the label…
On Apr 29, 2012 12:42 AM, “Alan Milligan” alan.milligan@last-bastion.net
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.

Regards,
Alan