selinux audit log flooded with avc denials to /tmp tmpfs when user is set to user_r

Question

I want to learn to create a role based on user_r for my custom motion daemon. The daemon works fine as unconstrained, but I want to lock it down further. I am on fedora 38 coreos.

Selinux tutorials and docs are a bit thin on the ground, but I have found:

custom role creation : http://www.selinuxproject.org/page/RefpolicyBasicRoleCreation

constraints : https://wiki.gentoo.org/wiki/SELinux/Constraints (there are few useful selinux gentoo pages).

So, I have switched my user to the user_u role as a start, but I start getting the following avc denials in audit.log

type=AVC msg=audit(1686738596.953:155): avc:  denied  { relabelto } for  pid=1054
comm="systemd" name="tmp" dev="tmpfs" ino=302 scontext=user_u:user_r:user_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0

audit2allow tells me:

#============= user_t ==============

#!!!! This avc is a constraint violation.  You would need to modify the attributes of
either the source or target types to allow this access.
#Constraint rule: 
#   constrain dir { create relabelfrom relabelto } ((u1 == u2 -Fail-)  or (t1 ==
 can_change_object_identity -Fail-) ); Constraint DENIED

#   Possible cause is the source user (user_u) and target user (system_u) are different.
allow user_t tmp_t:dir relabelto;

So, there is a constraint violation as some part of the user_r role is blocking some part of my user's need to access /tmp (I think). I thought that /tmp would be accessible by user_r, but obviously I am wrong.

I don't want to add can_change_object_identity to my user_r templated custom role and even if I did, I have been unable to find any info on how to do it. I have found this command : seinfo -acan_change_object_identity -x which lists which types have can_change_object_identity, but where is the file that defines these, or what is the command that allows them?

The thing is, I don't really want to add can_change_object_identity to my custom_role, so what can I do to mitigate this avc denial?

And finally, please let me know if I am barking up the wrong tree completely, as apart from the fact that selinux is massively complex anyway (seemingly to the novice), I just can't find authoritative complete and/or easy to follow selinux tutorials/info. Any pointers in that direction greatly appreciated...

MTIA

Answer 1

This is from my question asked at #selinux irc on liberachat...

the source context user_u:user_r:user_t:s0 is not allowed to relabel to the system_u identity

for a good reason

that context is meant to be associated with processes that are (almost never) associated with root or root privileges so it does not make sense to allow it because that would require root access anyway there is a domain_obj_id_change_exemption (or something along those lines) which allows you to get around it and piping the avc denial into audit2allow -W should, amongst other things, tell you that

ie:

echo '(typeattributeset can_change_object_identity user_t)' > mytest.cil && sudo semodule -i mytest.cil

the gist is that systemd --user runs with the wrong context

might be a pam issue

or old policy

since its fedora 38 its probably some kind of pam issue

i dont use fedora so i am not sure

regardless the mytest.cil should "fix" the immediate issue (but running systemd --user in user_t domain is opening up a can of worms)

not totally sure but unless things changed drastically in fedora then: confined users suchs as user_t and staff_t etc are an after thought in fedora. the main focus is on unconfined users. and the confined users are (barely) usable for minimal shells (ie sessions that do not have a systemd --user instance , have no gui etc) simple ssh login shells

so consider instead:

systemctl mask user@id -u USER.service systemctl mask user-runtime-dir@id -u USER.service

where USER is the username of the confined login user

that should work fine for confined ssh logins

either that or find out whether systemd --user should be running in the user_t domain as it does in your case or whether you hit a bug and systemd --user should be running in its own private user_systemd_t domain

if the systemd --user domain runs in its own private domain then you can associate the rules needed to use this functionality with just that private domain instead of user_t

posted to #selinux by kcinimod (reproduced with permission)...