Daemons writing into HOME_DIR

Daemons writing into HOME_DIR

[Stefan Schulze Frielinghaus]

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

Re: Daemons writing into HOME_DIR

[Chris PeBenito]

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

Re: Daemons writing into HOME_DIR

[Stefan Schulze Frielinghaus]

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