Privileged container spc_t optional

[patsys]

Hello,

on my kubernetes I will label all privileged container with a more strict label then spc_t, for this case it must the automatic transition to spc_t optional.

Position: https://github.com/SELinuxProject/refpolicy/blob/9c3fca3bed8f5c4aeba860682ddfd152344d5254/policy/modules/services/container.te#L955-L957C77

issue with CRI-O, trying to make it work with containerd: cri-o/cri-o#5501

[0xC0ncord]

While this is a relatively simple change to implement I'm not sure this would be within the scope of refpolicy as opposed to a custom policy. I think if this were added, I would make the relevant rules tunable and make this tunable enabled by default. Disabling this tunable would effectively break all privileged containers though until you implement your own transition rules.

This got me curious though, as I would imagine it should be possible to deploy a workload like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-selinux
  labels:
    environment: test
spec:
  selector:
    matchLabels:
      environment: test
  template:
    metadata:
      labels:
        environment: test
    spec:
      containers:
        - name: busybox
          image: busybox
          command:
            - /bin/sleep
          args:
            - infinity
          securityContext:
            privileged: true
            seLinuxOptions:
              type: container_t

Note the presence of privileged: true and the manually specified SELinux type. Unfortunately this still creates a container running as spc_t in my testing (at least with CRI-O 1.26.0) which is unfortunate.

[patsys]

Thanks for the quick answer.

Make this tunable enabled by default, is what I want.
When it is set from the distro policy, it is not simple to overwrite for me.

By cri-o it should work with 1.27.0+, but I have not get it running in the moment.

Edit:
On my setup with cri-o 1.29.0 I have get also a spc_t

[0xC0ncord]

@pebenito What do you think? While I think this is technically out of scope for refpolicy, I'm of the opinion that more flexibility is always nice as long as it doesn't break existing stuff.

[pebenito]

We can't totally remove the domain by tunables (type decls can't be tunable). How about a tunable that would remove all of the privilege from spc_t, making it a regular unpriv container, the same as container_t?

[0xC0ncord]

We can't totally remove the domain by tunables (type decls can't be tunable). How about a tunable that would remove all of the privilege from spc_t, making it a regular unpriv container, the same as container_t?

Wouldn't a tunable that removes the type_transition to spc_t work?

[pebenito]

We can't totally remove the domain by tunables (type decls can't be tunable). How about a tunable that would remove all of the privilege from spc_t, making it a regular unpriv container, the same as container_t?

Wouldn't a tunable that removes the type_transition to spc_t work?

That works, but still completely breaks privileged containers instead of only breaking the privileged operations.

[0xC0ncord]

That works, but still completely breaks privileged containers instead of only breaking the privileged operations.

That's true, but unfortunately doesn't address @patsys' desire to have a completely custom type in place of spc_t.

It is certainly possible though to go through the privileges spc_t has and put as much of them as (realistically) possible behind tunables. I don't mind volunteering towards that effort.

[pebenito]

That works, but still completely breaks privileged containers instead of only breaking the privileged operations.

That's true, but unfortunately doesn't address @patsys' desire to have a completely custom type in place of spc_t.

@patsys would you clarify your needs? is your need to have a completely custom type, not even using the container_template()?

It is certainly possible though to go through the privileges spc_t has and put as much of them as (realistically) possible behind tunables. I don't mind volunteering towards that effort.

I don't think this is necessary, at least at this time.

[patsys]

Hello,
thanks for the response.

In the moment I have in my Kubernetes only 1 case where need a privileged containers for Longhorn, for all other container it was possible to remove privilege and set a custom type.

Remove the not needed previlege is for me a good step, to get custom labels would be better, but not so good possible.

[github-actions]

This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.

[github-actions]

Closing stale PR.