Complete SELinux support

[randomvariable]

Follow up to #199

Hi, so I've been looking into what it would take to complete SELinux support on containerd, and have come up with the following, after looking at CRI-O and Docker today:

ContainerD MCS SELinux Support

Goals

• Ensure that Containerd’s SELinux implementation is secure-by-default.
• Containerd assigns random MCS labels to containers by default to segregate file access per sandbox
• Produce a SELinux conformance test suite to be used across container runtimes

Requirements

Functional

When not specified, containerd MUST use MCS to assign containers their own individual categories

Non-functional

• There MUST exist an SELinux conformance test suite that can be used across different container runtimes
• containerd SHOULD allow the user to specify a range of labels that can be used for auto-assignment

and then in relation to kubernetes/kubeadm#279

• Kubernetes documentation SHOULD be updated for SELinux support
• Kubeadm SHOULD be updated to set appropriate category labels where appropriate

Current state

Containerd includes minimal support for SELinux. More accurately, it contains support to run ON systems using SELinux, but it does not make use of SELinux to improve container security.

All containers run with the system_u:system_r:container_runtime_t:s0 label, but no further segmentation is made

What do others do?

Both docker and cri-o will allocate random MCS categories to each container to improve isolation of processes. A container running with category c113,c196, will not be able to read files in a file system labelled c114,c197, preventing a class of host path escape attacks.

Proposed SELinux MCS design for containerd

Modify the sandbox.Store to contain a SELinux MCS map, of categories (strings), to a (int) count of the number of sandboxes running at that label, similar to what CRI-O and Docker are doing today. Updates to the store must be performed via a mutex. This store would be used in two scenarios:

On sandbox creation

1. Grab lock on sandbox store
2. Either
3. Set MCS label as requested OR
4. Allocate random MCS label:
5. Generate random category label, retry if label exists as key in sandbox store’s MCS label map
6. Return label
7. If there is no key for the label in the sandbox store in MCS label map:
   1. Create key entry in map, and set to 1
8. Else increment value of entry in map. This should only happen when consumer specifically allocates a label, and these are shared between sandboxes.
9. Release sandbox store lock
10. Start sandbox with MCS label

On sandbox destruction

1. Destroy sandbox
2. Grab lock on sandbox store
3. Find entry in MCS label map and decrement by 1 if value is greater than 1, or delete map entry
4. Release lock

[Random-Liu]

@randomvariable The proposal sounds good to me.

Would you like to contribute a PR for this? I'll help you review and get it in. :)

[Random-Liu]

@randomvariable One question about your proposal. When Selinux option is set in pod security context https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container, containerd should set the label correspondingly right?

Do you expect that even when no SELINUX option is set for the pod, containerd still allocate a random label?

[randomvariable]

Yes, that's right. If the user is explicit in the pod spec, follow what they've asked for, otherwise allocate a random label.

I could work on this, but may take a little while. Wanted to check my thinking in any case.

[Random-Liu]

@randomvariable Keeping behavior identical with Docker SGTM.

[perezjasonr]

Hey all, any updates on this? I just found this out the hard way xD
i assumed selinux-enable true would respect my selinuxOptions section but it didnt (although it doesn't get rejected either).

edit: i see it marked as a 1.4 milestone. So I assume when 1.4 drops I can try this out again?

[estesp]

I assume this should have been closed when #1487 was merged; however, it will not be available generally until 1.4 is released. It should be available to be tested using the latest 1.4 beta release today.

@crosbymichael should this be closed? Is there anything left to implement?

[dmcgowan]

Yeah, we should close this out. Try the beta releases, rc and ga will be soon.