On Tue, May 03, 2022 at 02:19:17PM -0400, Chris PeBenito wrote: > On 5/3/22 13:01, Stefan Schulze Frielinghaus wrote: > > Hi all, > > > > In short I'm wondering what the refpolicy way is to let a daemon write into > > HOME_DIR and how those files---especially the SELinux user part---should be > > labeled? > > > > Currently I have a daemon (systemd service) running under context > > > > system_u:system_r:foobar_t:s0 > > > > and the policy contains > > > > init_daemon_domain(foobar_t, foobar_exec_t) > > > > The daemon reads and writes files under HOME_DIR/foobar which are labeled as > > foobar_rw_t and the policy has the following file context entry: > > > > HOME_DIR/foobar(/.*)? gen_context(system_u:object_r:foobar_rw_t,s0) > > > > However, newly created files still seem to have a wrong user according to > > restorecon (the daemon runs under Linux user marge which is assigned to SELinux > > user user_u): > > > > $ restorecon -FRvn /home/marge/foobar > > Would relabel /home/marge/foobar/baz from system_u:object_r:foobar_rw_t:s0 to user_u:object_r:foobar_rw_t:s0 > > > > It looks like as if user_u wins over system_u for files under HOME_DIR. This > > does not have any effect on the functionality of the daemon, however, it still > > feels wrong to me. > > This is genhomedircon setting the seuser of the files to match the seuser > mapping in `semanage login`. You want this behavior, especially if you have > UBAC turned on, otherwise UBAC doesn't provide a benefit, since system_u is > excluded from UBAC. > > > > So I'm wondering how to fix this and thought about: > > > > 1) Can/Should a daemon run under a different SELinux user than system_u? > > If this is a system daemon, e.g. started by systemd (pid 1) then that is not > expected in refpolicy, not generally suggested. If this is a daemon running > out of a user session, such as systemd --user, then yes, it should have the > user's seuser, e.g. user_u. > > > > 2) Another option, which I think is worse, would be to the change the SELinux > > user from user_u to system_u for Linux user marge under which the daemon runs. > > Running an interactive user as system_u is contrary to system_u's purpose, > which is for non-interactive system processes only. Good point. User marge is actually a non-interactive user and the whole purpose of it is to run the daemon via systemd (pid 1) only. I was afraid to associate system_u to marge due to "Administrators must never associate this system_u user and the system_r role to a Linux user" [1]. Though, maybe that statement referred to interactive users only, i.e., it is acceptable to associate system_u to non-interactive users? Cheers, Stefan > > > 3) A third option would be to keep the users as is, i.e., let the daemon run > > under system_u and let marge be assigned to user_u, but tweak the policy to keep > > the file context labels under HOME_DIR with system_u. > > See my first comment. > > > Any thoughts? > > You could change the default_user[1] so the seuser comes from the parent > directory, but that would change it for the entire system which may have > unintended and worse consequences. > > You're seeing the behavior I expect to see for this type of policy design. > > > [1] https://github.com/SELinuxProject/selinux-notebook/blob/main/src/default_rules.md#default_user > > -- > Chris PeBenito [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/managing-confined-and-unconfined-users_using-selinux
