selinux type super_t not given on our cluster

[schlichtanders]

Hi there, I think this is just asking for some documentation about how mountpoint-s3 depends on selinux. The default config sets the type to super_t, however on our k8s cluster there isn't such a policy setup.

Would be great to know which other type to use instead or how to define it.

EDIT: for others to find this easier. The actual error is quite confusing it looks like

error during container init: write /proc/self/attr/keycreate: invalid argument: unknown"

And this other issue was helping me to pin down that it might have something todo with the selinux type

/triage support

[schlichtanders]

Is this an attack done twice by different users/bots? Looks weird

[unexge]

SELinux is not fully supported at the moment and the support is tracked with https://github.com/awslabs/mountpoint-s3-csi-driver/issues/169.

I think the type to use depends on your OS and the SELinux policies you install (it seems like super_t mainly targets Bottlerocket). For example, if you install container-selinux, you could try using container_t or spc_t. spc_t is similar to super_t and gives more access - which might be needed until we fully support SELinux as we mount /proc/mounts currently.

The other comments indeed seem like spam, I removed them.

[schlichtanders]

Thank you for pointing to spc_t. Indeed that is available on our machines. :+1:

[schlichtanders]

I tried using spc_t, but now run into another permission problem.

mount-s3-1.8.0-0a115c2c-e0fc-4cb2-9a5b-536171ad00e7.service: Failed to set up standard output: Permission denied
mount-s3-1.8.0-0a115c2c-e0fc-4cb2-9a5b-536171ad00e7.service: Failed at step STDOUT spawning /opt/mountpoint-s3-csi/bin/mount-s3: Permission denied

unfortunately those services are super short lived, so I have no clue what STDOUT is actually set to and why the permissions may be wrong... any help is highly appreciated.

EDIT: it seems that mount-s3 is actually never run, but this permission problem makes the systemd process fail immediately.

[schlichtanders]

I also tried using container_t now, it is also available. But even fails earlier within the s3 daemonset

failed to start systemd supervisor: Failed to connect to systemd: dial unix /run/systemd/private: connect: permission denied

[schlichtanders]

I found out that ausearch -m avc -ts recent lists the selinux denials.

type=AVC msg=audit(1724744095.232:385753): avc:  denied  { open } for  pid=21922 comm="(mount-s3)" path="/dev/pts/6" dev="devpts" ino=9 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=0

I have a hard time to parse this... any help is highly appreciated

---

ausearch -m avc -ts recent | audit2allow further outputs the following

#============= init_t ==============
allow init_t devpts_t:chr_file open;

not sure what to do out of this either

[schlichtanders]

Apparently a similar issue is already reported at another issue https://github.com/awslabs/mountpoint-s3-csi-driver/issues/108#issuecomment-1875882741 so this really seems to be the thing :)

[unexge]

We currently create pseudo-terminal to get stdout/stderr of mount-s3 process and most SELinux installations blocks it I think. We'll handle that as part of https://github.com/awslabs/mountpoint-s3-csi-driver/issues/169, but meanwhile, would you be able to use the workaround from the comment you shared using audit2allow?

[schlichtanders]

yes indeed that workaround seems to work :+1:

[unexge]

Closing this issue for now. Will be sharing updates regarding SELinux in https://github.com/awslabs/mountpoint-s3-csi-driver/issues/169.