SELinux label on the mounted volume

[zhouhaibing089]

There is a field named SELinuxOptions in PodSecurityContext, however this is only used for the running process in containers.

For example, the following spec:

apiVersion: v1
kind: Pod
metadata:
  name: ubuntu3
  labels:
    app: ubuntu
spec:
  containers:
  - image: ubuntu:14.04
    command:
    - sleep
    - "3600"
    imagePullPolicy: IfNotPresent
    name: ubuntu
    volumeMounts:
    - name: log-dir
      mountPath: /var/log/ubuntu3
  volumes:
  - name: log-dir
    hostPath:
      path: /var/log/ubuntu3
  restartPolicy: Always
  securityContext:
    seLinuxOptions:
      user: system_u
      role: object_r
      type: svirt_sandbox_file_t
      level: s0:c100,c200

What I am hoping is that the files under /var/log/ubuntu3 would have type svirt_sandbox_file_t, however it was set on the process, not the volumes.

# ps auxZ | grep sleep
system_u:object_r:svirt_sandbox_file_t:s0:c100,c200 root 8633 0.1  0.0 4348 636 ? Ss 10:12   0:00 sleep 3600

My question is: Is there a way to set selinux labels for the volumes(something like -v ${hostpath}:${containerpath}:z in docker)?

[zhouhaibing089]

I have no idea on who should I mention, so @erictune (security-related) and @saad-ali (volume-related), what do you think?

Extend this a little bit further, if the docker has selinux enabled, then all the containers already get a unique level settings with something like system_u:system_r:svirt_lxc_net_t:s0:c152,c382, and actually I feel the ability to set selinux labels on the volumes is more urgent, say if we have selinux enabled on each nodes, and due to the policy specifies svirt_lxc_net_t domain could only access part of some files:

The default type for a confined container process is svirt_lxc_net_t, this
type is permitted to read and execute all files types under /usr and most
types under /etc, svirt_lxc_net_t is permitted to use the network but is
not permitted to read content under /var, /home, /mnt..., svirt_lxc_net_t
is permitted to write only files labeled svirt_sandbox_filt_t and docker_var_lib_t,
all files in a container are labeled by default as svirt_sandbox_file_t, Access
to docker_var_lib_t is permitted in order to allow the use of docker volumes.

And the configMap, secrets(which are both stored at /var/lib/kubelet) features are all unavailable. We have to change its type to be svirt_sandbox_filt_t.

[saad-ali]

CC @pmorie

[zhouhaibing089]

It looks like setting the selinuxOptions would affect too many things, for example, almost all the files in the container(except the mounted volume) are all with type svirt_sandbox_filt_t, thus the process could not read any files.

So it is really confusing on why setting selinux for the process?? /cc @chengyli @ashw7n

[zhouhaibing089]

cc @derekwaynecarr

Atomic OS carries with kubernetes distro with selinux enabled by default, what's the way to ensure the volumes are accessible with SELinux enabled?

[zhouhaibing089]

Reading through the proposal here: https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/selinux.md and atomic issues here: projectatomic/adb-atomic-developer-bundle#117.

It looks like the selinux support for volume is still incomplete. specifically, @pmorie I read through your proposal, the question in my mind is: should there be two seLinuxOptions? one for setting the process, and another one for setting the volume label.

[wied03]

I think Dan's post describes pretty well what Docker does.

I think if Kubernetes just had a "SELinuxVolume" flag, it could even infer whether to pass Z or z to Docker based on the access mode of the persistent volume (assuming persistent volumes here).

ReadWriteOnce sort of implies Z whereas ReadWriteMany implies z

[wied03]

I think my last comment is pointless. The proposal doc referenced above describes it pretty well.

[pizzarabe]

I am confused. If you can not label volumes at the moment, why is https://kubernetes.io/docs/user-guide/security-context/ talking about that?

Another functionality of pod level security context is that it applies those settings to volumes where applicable. Specifically fsGroup and seLinuxOptions are applied to the volume as follows:
[...]

selinuxOptions

Volumes which support SELinux labeling are relabeled to be accessible by the label specified unders seLinuxOptions. Usually you will only need to set the level section. This sets the SELinux MCS label given to all containers within the pod as well as the volume.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[wied03]

@zhouhaibing089 - Did anything ever happen with this?

[zhouhaibing089]

@wied03: not I am aware of.. I will check later..

[wied03]

I haven't tested this but I think this issue still remains because the docs @pizzarabe mentions talk about specifying the label. The "desired" behavior that Docker does is the container runs as a random, unused MCS label and then the Z flag has Docker relabel the volume with the MCS label it chose for the container.

There are mount options in K8s now (could Z be passed in there) but it looks like those are at the node level, not container specific.

[luckyfengyong]

It sounds like currently to mount local PV with Docker selinux enabled, user has to manually add label to local path. An example is openshift user doc https://docs.openshift.org/latest/install_config/configuring_local.html#local-volume-mounting-local-volumes.

Any concern, Kubernetes local volume supports it automatically.

Can we /reopen the ticket or we need open a new one?

[WanLinghao]

same problems in my case