[systemd-devel] [PATCH] Add SELinuxContext configuration item

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jan 03, 2014 at 11:48:49AM -0500, Daniel J Walsh wrote:
> >> Should systemd warn users if selinux is not installed,enabled and fail
> >> or?
> > 
> > It all depend. Either we are consistent with the other settings ( ie, 
> > setting a syscall filter will fail if not supported on the kernel ), and so
> > fail, or we decide that selinux is special and we should silently ignore
> > failure if it cannot be applied.
> > 
> > I choose the first one for the first patch, but adding a conditional would
> > be trivial if we decide to silently ignore if the setting cannot be
> > applied.
I think the usual style of "-" as the first character of RHS meaning that
the setting can be ignored should be used.

In general, if selinux=0 is used, or selinux support is not compiled
in, those options should not result in failure. So the algorithm should
be: if disabled, ignore, if enabled, and impossible to apply, fail, unless
"-" was prefixed.

> >> In anycase Lennart decides this to me this seems like a workaround being
> >>  put in systemd for a limitation in selinux or the concept there of with
> >>  the added complexity for administrators.
> > 
> > yes, that's put in systemd because placing this in every other possible 
> > place would be duplication. As i said, we could add this to jvm, to erlang,
> > etc, but it would scale ( ie, we would have more place to look for
> > configuration )
> > 
> Well thinking about this again, I think still to the single label.  Lets not
> break the field up into multiple labels.
Yes, this sounds nicer: easier to document, to configure, etc.

> And not make it SELinux specific.  Maybe the field could be SecurityLabel:
> 
> That would allow smack to also use the field and any other LSM that used a
> labeling system.
This would make it impossible to use the same unit file with more than
one security framework. This might be desirable, even if they cannot be enabled
at the same time.

Zbyszek