From: Daniel Brooks <db48x@db48x.net>
To: Marius Bakke <marius@gnu.org>
Cc: 44549@debbugs.gnu.org
Subject: [bug#44549] [PATCH] etc: updates for the guix-daemon SELinux policy
Date: Thu, 12 Nov 2020 13:45:10 -0800 [thread overview]
Message-ID: <87v9ea6yhl.fsf@db48x.net> (raw)
In-Reply-To: <87361ecm7f.fsf@gnu.org> (Marius Bakke's message of "Thu, 12 Nov 2020 22:13:56 +0100")
Marius Bakke <marius@gnu.org> writes:
> Hello Daniel,
>
> Thanks a lot for this.
You're welcome.
>
> 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…
>> +;; 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.
> 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?
> (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.
> (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.
>
> With this, I no longer have to go through 'guix pack' and 'podman' to
> run Guix packages on my RHEL workstation! :-)
Ideal :)
>
> Also, is it OK to add you to the list of contributors at the top of the
> file with this name and address?
Certainly.
db48x
next prev parent reply other threads:[~2020-11-12 21:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-10 9:42 [bug#44549] [PATCH] etc: updates for the guix-daemon SELinux policy Daniel Brooks
2020-11-12 21:13 ` Marius Bakke
2020-11-12 21:45 ` Daniel Brooks [this message]
2020-11-12 22:19 ` Marius Bakke
2020-11-12 23:56 ` Daniel Brooks
2020-11-13 14:52 ` Marius Bakke
2020-11-13 15:34 ` Daniel Brooks
2020-11-13 15:59 ` Marius Bakke
2020-11-13 0:01 ` [bug#44549] [PATCH v2] " Daniel Brooks
2020-11-13 0:07 ` [bug#44549] [PATCH v3] " Daniel Brooks
2020-11-14 14:57 ` [bug#44549] [PATCH v4] " Daniel Brooks
2020-11-15 22:19 ` bug#44549: " Marius Bakke
2020-11-14 16:49 ` [bug#44549] [PATCH v4] doc: add a note about relabling after upgrades to the guix deamon Daniel Brooks
2020-11-15 22:18 ` Marius Bakke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v9ea6yhl.fsf@db48x.net \
--to=db48x@db48x.net \
--cc=44549@debbugs.gnu.org \
--cc=marius@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.