Managing SELinux profiles

Create and manage SELinux profiles and bind them to workloads.

Creating SELinux profiles

Use the SelinuxProfile object to create profiles.

The SelinuxProfile object has several features that allow for better security hardening and readability:

  • Restricts the profiles to inherit from to the current namespace or a system-wide profile. Because there are typically many profiles installed on the system, but only a subset should be used by cluster workloads, the inheritable system profiles are listed in the spod instance in spec.selinuxOptions.allowedSystemProfiles.

  • Performs basic validation of the permissions, classes and labels.

  • Adds a new keyword @self that describes the process using the policy. This allows reusing a policy between workloads and namespaces easily, as the usage of the policy is based on the name and namespace.

  • Adds features for better security hardening and readability compared to writing a profile directly in the SELinux CIL language.

Procedure

  1. Create a policy that can be used with a non-privileged workload by creating the following SelinuxProfile object:

    1. apiVersion: security-profiles-operator.x-k8s.io/v1alpha2
    2. kind: SelinuxProfile
    3. metadata:
    4.   name: nginx-secure
    5.   namespace: nginx-deploy
    6. spec:
    7.   allow:
    8.     '@self':
    9.       tcp_socket:
    10.       - listen
    11.     http_cache_port_t:
    12.       tcp_socket:
    13.       - name_bind
    14.     node_t:
    15.       tcp_socket:
    16.       - node_bind
    17.   inherit:
    18.   - kind: System
    19.     name: container

  2. Wait for selinuxd to install the policy by running the following command:

    1. $ oc wait --for=condition=ready -n nginx-deploy selinuxprofile nginx-secure

    Example output

    1. selinuxprofile.security-profiles-operator.x-k8s.io/nginx-secure condition met

    The policies are placed into an emptyDir in the container owned by the Security Profiles Operator. The policies are saved in Common Intermediate Language (CIL) format in /etc/selinux.d/<name>_<namespace>.cil.

  3. Access the pod by running the following command:

    1. $ oc -n openshift-security-profiles rsh -c selinuxd ds/spod

Verification

  1. View the file contents with cat by running the following command:

    1. $ cat /etc/selinux.d/nginx-secure_nginx-deploy.cil

    Example output

    1. (block nginx-secure_nginx-deploy
    2. (blockinherit container)
    3. (allow process nginx-secure_nginx-deploy.process ( tcp_socket ( listen )))
    4. (allow process http_cache_port_t ( tcp_socket ( name_bind )))
    5. (allow process node_t ( tcp_socket ( node_bind )))
    6. )

  2. Verify that a policy has been installed by running the following command:

    1. $ semodule -l | grep nginx-secure

    Example output

    1. nginx-secure_nginx-deploy

Applying SELinux profiles to a pod

Create a pod to apply one of the created profiles.

For SELinux profiles, the namespace must be labelled to allow privileged workloads.

Procedure

  1. Apply the scc.podSecurityLabelSync=false label to the nginx-deploy namespace by running the following command:

    1. $ oc label ns nginx-deploy security.openshift.io/scc.podSecurityLabelSync=false

  2. Apply the privileged label to the nginx-deploy namespace by running the following command:

    1. $ oc label ns nginx-deploy --overwrite=true pod-security.kubernetes.io/enforce=privileged

  3. Obtain the SELinux profile usage string by running the following command:

    1. $ oc get selinuxprofile.security-profiles-operator.x-k8s.io/nginx-secure -n nginx-deploy -ojsonpath='{.status.usage}'

    Example output

    1. nginx-secure_nginx-deploy.process%

  4. Apply the output string in the workload manifest in the .spec.containers[].securityContext.seLinuxOptions attribute:

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: nginx-secure
    5.   namespace: nginx-deploy
    6. spec:
    7.   containers:
    8.     - image: nginxinc/nginx-unprivileged:1.21
    9.       name: nginx
    10.       securityContext:
    11.         seLinuxOptions:
    12.           # NOTE: This uses an appropriate SELinux type
    13.           type: nginx-secure_nginx-deploy.process

    The SELinux type must exist before creating the workload.

Applying SELinux log policies

To log policy violations or AVC denials, set the SElinuxProfile profile to permissive.

This procedure defines logging policies. It does not set enforcement policies.

Procedure

  • Add permissive: true to an SElinuxProfile:

    1. apiVersion: security-profiles-operator.x-k8s.io/v1alpha2
    2. kind: SelinuxProfile
    3. metadata:
    4.   name: nginx-secure
    5.   namespace: nginx-deploy
    6. spec:
    7.   permissive: true

Binding workloads to profiles with ProfileBindings

You can use the ProfileBinding resource to bind a security profile to the SecurityContext of a container.

Procedure

  1. To bind a pod that uses a quay.io/security-profiles-operator/test-nginx-unprivileged:1.21 image to the example SelinuxProfile profile, create a ProfileBinding object in the same namespace with the pod and the SelinuxProfile objects:

    1. apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
    2. kind: ProfileBinding
    3. metadata:
    4.   namespace: my-namespace
    5.   name: nginx-binding
    6. spec:
    7.   profileRef:
    8.     kind: SelinuxProfile (1)
    9.     name: profile (2)
    10.   image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    1The kind: variable refers to the name of the profile.
    2The name: variable refers to the name of the profile.

  2. Label the namespace with enable-binding=true by running the following command:

    1. $ oc label ns my-namespace spo.x-k8s.io/enable-binding=true

  3. Delete and re-create the pod to use the ProfileBinding object:

    1. $ oc delete pods test-pod && oc create -f pod01.yaml

Verification

  • Confirm the pod inherits the ProfileBinding by running the following command:

    1. $ oc get pod test-pod -o jsonpath='{.spec.containers[*].securityContext.seLinuxOptions.type}'

    Example output

    1. profile_nginx-binding.process

Replicating controllers and SecurityContextConstraints

When deploying SELinux policies for replicating controllers, such as deployments or daemon sets, note that the Pod objects spawned by the controllers are not running with the identity of the user who creates the workload. Unless a ServiceAccount is selected, the pods might revert to using a restricted SecurityContextConstraints (SCC) which does not allow use of custom security policies.

Procedure

  1. Create the following RoleBinding object to allow SELinux policies to be used in the nginx-secure namespace:

    1. kind: RoleBinding
    2. apiVersion: rbac.authorization.k8s.io/v1
    3. metadata:
    4.   name: spo-use-seccomp-scc
    5.   namespace: nginx-secure
    6. subjects:
    7. - kind: ServiceAccount
    8.   name: spo-deploy-test
    9. roleRef:
    10.   kind: Role
    11.   name: spo-use-seccomp-scc
    12.   apiGroup: rbac.authorization.k8s.io

  2. Create the Role object:

    1. apiVersion: rbac.authorization.k8s.io/v1
    2. kind: Role
    3. metadata:
    4.   creationTimestamp: null
    5.   name: spo-use-seccomp-scc
    6.   namespace: nginx-secure
    7. rules:
    8. - apiGroups:
    9.   - security.openshift.io
    10.   resources:
    11.   - securitycontextconstraints
    12.   resourceNames:
    13.   - privileged
    14.   verbs:
    15.   - use

  3. Create the ServiceAccount object:

    1. apiVersion: v1
    2. kind: ServiceAccount
    3. metadata:
    4.   creationTimestamp: null
    5.   name: spo-deploy-test
    6.   namespace: nginx-secure

  4. Create the Deployment object:

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4.   name: selinux-test
    5.   namespace: nginx-secure
    6.   metadata:
    7.     labels:
    8.       app: selinux-test
    9. spec:
    10.   replicas: 3
    11.   selector:
    12.     matchLabels:
    13.       app: selinux-test
    14.   template:
    15.     metadata:
    16.       labels:
    17.         app: selinux-test
    18.     spec:
    19.       serviceAccountName: spo-deploy-test
    20.       securityContext:
    21.         seLinuxOptions:
    22.           type: nginx-secure_nginx-secure.process (1)
    23.       containers:
    24.       - name: nginx-unpriv
    25.         image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    26.         ports:
    27.         - containerPort: 8080
    1The .seLinuxOptions.type must exist before the Deployment is created.

    The SELinux type is not specified in the workload and is handled by the SCC. When the pods are created by the deployment and the ReplicaSet, the pods will run with the appropriate profile.

Ensure your SCC is only usable by the correct service account. Refer to Additional resources for more information.

Recording profiles from workloads

The Security Profiles Operator can record system calls with ProfileRecording objects, making it easier to create baseline profiles for applications.

When using the log enricher for recording SELinux profiles, verify the log enricher feature is enabled. See Additional resources for more information.

A container with privileged: true security context restraints prevents log-based recording. Privileged containers are not subject to SELinux policies, and log-based recording makes use of a special SELinux profile to record events.

Procedure

  1. Label the namespace with enable-recording=true by running the following command:

    1. $ oc label ns my-namespace spo.x-k8s.io/enable-recording=true

  2. Create a ProfileRecording object containing a recorder: logs variable:

    1. apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
    2. kind: ProfileRecording
    3. metadata:
    4.   name: test-recording
    5. spec:
    6.   kind: SelinuxProfile
    7.   recorder: logs
    8.   podSelector:
    9.     matchLabels:
    10.       app: my-app

  3. Create a workload to record:

    1. apiVersion: v1
    2. kind: Pod
    3. metadata:
    4.   name: my-pod
    5.   labels:
    6.     app: my-app
    7. spec:
    8.   containers:
    9.     - name: nginx
    10.       image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    11.       ports:
    12.         - containerPort: 8080
    13.     - name: redis
    14.       image: quay.io/security-profiles-operator/redis:6.2.1

  4. Confirm the pod is in a Running state by entering the following command:

    1. $ oc -n openshift-security-profiles get pods

    Example output

    1. NAME     READY   STATUS    RESTARTS   AGE
    2. my-pod   2/2     Running   0          18s

  5. Confirm the enricher indicates that it receives audit logs for those containers:

    1. $ oc -n openshift-security-profiles logs --since=1m --selector name=spod -c log-enricher

    Example output

    1. I0517 13:55:36.383187  348295 enricher.go:376] log-enricher "msg"="audit" "container"="redis" "namespace"="my-namespace" "node"="ip-10-0-189-53.us-east-2.compute.internal" "perm"="name_bind" "pod"="my-pod" "profile"="test-recording_redis_6kmrb_1684331729" "scontext"="system_u:system_r:selinuxrecording.process:s0:c4,c27" "tclass"="tcp_socket" "tcontext"="system_u:object_r:redis_port_t:s0" "timestamp"="1684331735.105:273965" "type"="SELinux"

Verification

  1. Remove the pod:

    1. $ oc -n openshift-security-profiles delete pod my-pod

  2. Confirm the Security Profiles Operator reconciles the two SELinux profiles:

    1. $ oc get selinuxprofiles -n my-namespace

    Example output

    1. NAME                   USAGE                                       STATE
    2. test-recording-nginx   test-recording-nginx_my-namespace.process   Installed
    3. test-recording-redis   test-recording-redis_my-namespace.process   Installed

Merging per-container profile instances

By default, each container instance records into a separate profile. The Security Profiles Operator can merge the per-container profiles into a single profile. Merging profiles is useful when deploying applications using ReplicaSet or Deployment objects.

Procedure

  1. Edit a ProfileRecording object to include a mergeStrategy: containers variable:

    1. apiVersion: security-profiles-operator.x-k8s.io/v1alpha1
    2. kind: ProfileRecording
    3. metadata:
    4.   # The name of the Recording is the same as the resulting SelinuxProfile CRD
    5.   # after reconciliation.
    6.   name: test-recording
    7. spec:
    8.   kind: SelinuxProfile
    9.   recorder: logs
    10.   mergeStrategy: containers
    11.   podSelector:
    12.     matchLabels:
    13.       app: sp-record

  2. Create the workload:

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4.   name: nginx-deploy
    5. spec:
    6.   replicas: 3
    7.   selector:
    8.     matchLabels:
    9.       app: sp-record
    10.   template:
    11.     metadata:
    12.       labels:
    13.         app: sp-record
    14.     spec:
    15.       serviceAccountName: spo-record-sa
    16.       containers:
    17.       - name: nginx-record
    18.         image: quay.io/security-profiles-operator/test-nginx-unprivileged:1.21
    19.         ports:
    20.         - containerPort: 8080

  3. To record the individual profiles, delete the deployment by running the following command:

    1. $ oc delete deployment nginx-deploy

  4. To merge the profiles, delete the profile recording by running the following command:

    1. $ oc delete profilerecording test-recording

  5. To start the merge operation and generate the results profile, run the following command:

    1. $ oc get selinuxprofiles -lspo.x-k8s.io/recording-id=test-recording

    Example output

    1. NAME                          USAGE                                         STATE
    2. test-recording-nginx-record   test-recording-nginx-record_mytest1.process   Installed

  6. To view the permissions used by any of the containers, run the following command:

    1. $ oc get selinuxprofiles test-recording-nginx-record -o yaml

About seLinuxContext: RunAsAny

Recording of SELinux policies is implemented with a webhook that injects a special SELinux type to the pods being recorded. The SELinux type makes the pod run in permissive mode, logging all the AVC denials into audit.log. By default, a workload is not allowed to run with a custom SELinux policy, but uses an auto-generated type.

To record a workload, the workload must use a service account that has permissions to use an SCC that allows the webhook to inject the permissive SELinux type. The privileged SCC contains seLinuxContext: RunAsAny.

In addition, the namespace must be labeled with pod-security.kubernetes.io/enforce: privileged if your cluster enables the Pod Security Admission because only the privileged Pod Security Standard allows using a custom SELinux policy.

Additional resources