[bug#44549] [PATCH] etc: updates for the guix-daemon SELinux policy

[Daniel Brooks]

Marius Bakke <marius@gnu.org> writes:

>>> +  (allow init_t
>>> +         guix_store_content_t
>>> +         (lnk_file (read)))
>>
>> This one is a little unusual; is your service file symlinked or something?
>
> Hmm.  Could it be because /etc/systemd/system/guix-daemon.service refers
> to /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon?

That was it. Not sure how I left that one out, in fact.

>>> +  (allow guix_daemon_t
>>> +         guix_daemon_socket_t
>>> +         (sock_file (unlink)))
>>
>> That shouldn't be a problem, though we don't have any other rules for
>> guix_daemon_socket_t. Possibly that is because my socket file is labeled
>> guix_daemon_conf_t, for unknown reasons. Perhaps it was not labeled
>> correctly when created, and hasn't been relabeled since.
>
> It could also be an artifact from my ancient experiments with Guix and
> SELinux on this system.  Perhaps we should test on a "clean" system to
> verify, I can do that next week.

Ok, I figured this one out. When the socket file is created it is
labeled at guix_daemon_conf_t, but the filecon rules will cause that to
be relabeled to guix_daemon_socket_t at some point in the future. When
the guix-daemon process stops it tries to delete the socket file, but
can't. I'll go ahead and include the rule.

> Can you "squash" the relevant changes from my patch and send a new patch
> when you are done?

Will do.

>
> As a side note, I've seen a couple other audit messages from
> guix-daemon, although though they don't seem to cause a problem in
> practice.
>
> type=AVC msg=audit(1605189801.627:8637388): avc: denied { read } for
> pid=2312896 comm="guix-daemon" path="socket:[74336318]" dev="sockfs"
> ino=74336318 scontext=system_u:system_r:guix_daemon.guix_daemon_t:s0
> tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
> permissive=0
> type=AVC msg=audit(1605189801.627:8637388): avc: denied { read } for
> pid=2312896 comm="guix-daemon" path="socket:[74336318]" dev="sockfs"
> ino=74336318 scontext=system_u:system_r:guix_daemon.guix_daemon_t:s0
> tcontext=system_u:system_r:init_t:s0 tclass=unix_stream_socket
> permissive=0
> type=AVC msg=audit(1605189801.627:8637388): avc: denied { siginh } for
> pid=2312896 comm="guix-daemon" scontext=system_u:system_r:init_t:s0
> tcontext=system_u:system_r:guix_daemon.guix_daemon_t:s0 tclass=process
> permissive=0

The first two are already covered by the new policy, and the third is
inconsequential. The kernel checks on our behalf to see if our child
processes are allowed to inherit our signal state. That's usually
disallowed, so that rule is marked 'dontaudit' so that it doesn't spam
the logs; you probably had that disabled. I'm not going to add a rule
allowing that one; It would just cause accidents.

db48x