Skip to content

Conversation

@Mashimiao
Copy link

Signed-off-by: Ma Shimiao mashimiao.fnst@cn.fujitsu.com

Signed-off-by: Ma Shimiao <mashimiao.fnst@cn.fujitsu.com>
@Mashimiao Mashimiao force-pushed the config-linux-mountlabel branch from 1db10c0 to 203473c Compare May 23, 2017 05:48
Copy link
Contributor

@wking wking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related discussion in #843.


**`mountLabel`** (string, OPTIONAL) will set the Selinux context for the mounts in the container.
**`mountLabel`** (string, OPTIONAL) will set the SELinux context for the mounts in the container.
If `mountLabel` is specified and SELinux is enabled, the runtime MUST set `mountLabel` for the mounts in the container.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want “and SELinux is enabled”. Runtimes that don't support SELinux will not be compliant, just like runtimes that don't support cgroups will not be compliant. These runtimes might still be useful in certain contexts, and not all hosts may support SELinux (in which case configs that set mountLabel will likely crash in create), but in order to be a compliant runtime, you MUST support this property. If we want compliance labeling for runtimes that don't support this property, we'd need a new selinux compliance track.

And instead of the still-unclear-to-me “MUST set mountLabel for the mounts”, I'd rather focus on how we test that this happened. For example:

If `mountLabel` is set, `lgetxattr(2)` with `security.selinux` for `name` MUST return this value when called from the container mount namespace (or context, or whatever) on `/` and all `mounts[].destination`.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What you said makes me confused.
SELinux is enabled or not is not runtimes' business, that's host's business. If SELinux is enabled on host and users specified mountLabel, rutimes MUST apply it, that's runtimes' business.
I'm not sure how you think about "runtime support SELinux or not"? In my opinion, the support means "When SELinux label is specified, and SELinux is enabled on host, runtime can apply the label correctly", and also we can say the runtime is compliant.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how you think about "runtime support SELinux or not"? In my opinion, the support means "When SELinux label is specified, and SELinux is enabled on host, runtime can apply the label correctly", and also we can say the runtime is compliant.

That makes sense to me. I was thinking of runtime support like runC's selinux build tag. I think we need to require runtimes to respect this property on hosts where SELinux is enabled. I care less about hosts where SELinux is not available, but would like runtimes to error out during create if mountLabel (or other SELinux-based option) was set in a config on those hosts. I think my proposed wording is fine for this already. Or do you want to qualify it based on having a mounted selinuxfs in the host mount namespace or some such?

@mrunalp
Copy link
Contributor

mrunalp commented Jun 1, 2017

It is better to leave this as it is. We need to consider the platform, selinux modes and whether runtime has been compiled with SELinux.

@mrunalp mrunalp closed this Jun 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants