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

[Marius Bakke <marius@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 5505 bytes --]

Daniel Brooks <db48x@db48x.net> writes:

>> Daniel Brooks <db48x@db48x.net> writes:
>>
>>>>From 7dd9ed6da01c5bf125c95592f4978b579198731a Mon Sep 17 00:00:00 2001
>>> From: Daniel Brooks <db48x@db48x.net>
>>> Date: Mon, 9 Nov 2020 07:03:42 -0800
>>> Subject: [PATCH] etc: updates for the guix-daemon SELinux policy
>>>
>>> * etc/guix-daemon.cil.in: I can't promise that this is a complete list of
>>> everything that guix-daemon needs, but it's probably most of them. It can
>>> search for, install, upgrade, and remove packages, create virtual machines,
>>> update itself, and so on. I haven't tried creating containers yet, which might
>>> reveal more things to add.
>>
>> This commit message is somewhat unorthodox.  :-)
>>
>> Perhaps it can be shortened to:
>>
>> * etc/guix-daemon.cil.in (guix_daemon): Specify more permissions for
>> guix-daemon to account for daemon updates and newer SELinux.
>
> I suppose. Personally I dislike the changelog style commit messages, but
> when in Rome…

It's not a very strong opinion.  I think it would be fine without the
first person style.

>>> +;; In particular, you can run semanage permissive -a guix_daemon.guix_daemon_t
>>> +;; to allow guix-daemon to do whatever it wants. SELinux will still check its
>>> +;; permissions, and when it doesn't have permission it will still send an
>>> +;; audit message to your system logs. This lets you know what permissions it
>>> +;; ought to have. Use ausearch --raw to find the permissions violations, then
>>> +;; pipe that to audit2allow to generate an updated policy. You'll still need
>>> +;; to translate that policy into CIL in order to update this file, but that's
>>> +;; fairly straight-forward. Annoying, but easy.
>>
>> I'm not sure about the second paragraph.  It's mainly a rehash of the
>> blog post, no?  And there are many other ways to go about
>> troubleshooting SELinux (I did not use ausearch at all).
>
> True. I just wanted a quick summary somewhere in the source so that
> future us won't have to rely on a random blog post, even one from Dan
> Walsh.

Fair point.  I can imagine a scenario when I'm stuck on a SELinux system
without an internet connection.

>> diff --git a/etc/guix-daemon.cil.in b/etc/guix-daemon.cil.in
>> index 666e5677a3..b5909f1b18 100644
>> --- a/etc/guix-daemon.cil.in
>> +++ b/etc/guix-daemon.cil.in
>> @@ -84,6 +84,9 @@
>>    (allow init_t
>>           guix_daemon_t
>>           (process (transition)))
>> +  (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?

>>    (allow init_t
>>           guix_store_content_t
>>           (file (open read execute)))
>> @@ -166,6 +169,9 @@
>>    (allow guix_daemon_t
>>           root_t
>>           (dir (mounton)))
>> +  (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.

>>    (allow guix_daemon_t
>>           fs_t
>>           (filesystem (getattr)))
>> @@ -348,7 +354,12 @@
>>                                getopt setopt)))
>>    (allow guix_daemon_t
>>           self
>> -         (tcp_socket (accept listen bind connect create setopt getopt getattr ioctl)))
>> +         (netlink_route_socket (read write)))
>> +  (allow guix_daemon_t
>> +         self
>> +         (tcp_socket (accept
>> +                      listen bind connect create read write
>> +                      setopt getopt getattr ioctl)))
>
> These are fine; in fact I discovered these myself this morning and was
> going to send a patch.
>
>> Can you test these additional changes on Fedora?
>
> Yes, I'll let you know if there are any problems. Also, I'll investigate
> the socket file some more.

Awesome, thanks a lot!

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

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

Not sure what that's about.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 507 bytes --]