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. 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?
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.
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.
Any thoughts?
(PS: the daemon cannot be reconfigured in order to write into a different
directory than HOME_DIR)
Cheers,
Stefan
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.
> 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