|
| From: | Catonano |
| Subject: | Re: [PATCH] Add SELinux policy for guix-daemon. |
| Date: | Tue, 13 Feb 2018 16:30:44 +0100 |
Hi Guix,
attached is a patch that adds an SELinux policy for the guix-daemon.
The policy defines the guix_daemon_t domain and specifies what labels
may be accessed and how by processes running in that domain.
These file labels are defined:
* guix_daemon_conf_t
for Guix configuration files (in localstatedir and sysconfdir)
* guix_daemon_exec_t
for executables spawned by the daemon (which are allowed to run in the
guix_daemon_t domain)
* guix_daemon_socket_t
for the daemon socket file
* guix_profiles_t
for the contents of the profiles directory
The “filecon” statements near the bottom of the file specify which
labels are to be used for what file names.
I tested this with “guix build --no-grafts --check hello”, “guix build
samtools”, “guix gc -C 1k”, and “guix package -p ~/foo -i hello”;
no operations were blocked by SELinux.
If you want to test this on Fedora, set SELinux to permissive, and make
sure to configure Guix properly (i.e. set localstatedir, prefix, and
sysconfdir). Then install the policy with “sudo semodule -i
etc/guix-daemon.cil”. Then relabel the filesystem (at least /gnu,
$localstatedir, $sysconfdir, and $prefix) with something like this:
sudo restorecon -R /gnu $localstatedir $sysconfdir $prefix
This will take a very long time (a couple of hours).
Restart the daemon. Check that it now runs in the guix_daemon_t
context:
ps -Zax | grep /bin/guix-daemon
This should return something like this
system_u:system_r:guix_daemon.guix_daemon_t:s0 14886 ? Ss 0:00 /root/.guix-profile/bin/guix- daemon --build-users-group=guix- builder
Check the audit log for violations:
sudo tail -f /var/log/audit/audit.log | grep x-daemon
And then use Guix:
guix build --no-grafts --check hello
The audit log shouldn’t show you any complaints. At this point you
could probably switch to enforcing mode, but I haven’t tested this
myself for no particular reason.
Open issues:
* guix_daemon_socket_t isn’t actually used. All of the socket
operations that I observed involve contexts that don’t have anything
to do with guix_daemon_socket_t. It doesn’t hurt to have this unused
label, but I would have preferred to define socket rules for only this
label. Oh well.
* “guix gc” cannot access arbitrary links to profiles. By design, the
file label of the destination of a symlink is independent of the file
label of the link itself. Although all profiles under $localstatedir
are labelled, the links to these profiles inherit the label of the
directory they are in. For links in the user’s home directory this
will be “user_home_t” (for which I’ve added a rule). But for links
from root’s home directory, or /tmp, or the HTTP server’s working
directory … this won’t work. “guix gc” would be prevented from
reading and following these links.
* I don’t know if the daemon’s TCP listen feature still works. I didn’t
test it and assume that it would require extra rules, because SELinux
treats network sockets differently from files.
* Is this all correct? I don’t know! I only just learned about the
SELinux Common Intermediate Language (CIL), and the documentation is
very sparse, so I have no idea if I did something stupid. It seems
fine to me, but I must admit that I find it a bit uncomfortable to see
so many access types in the rules.
* I allowed type transitions from init_t to guix_daemon_t via
guix_daemon_exec_t, but also from guix_store_content_t to
guix_daemon_t via guix_daemon_exec_t. Type transitions are necessary
to get from an allowed entry point to a domain. On Fedora “init_t” is
the domain in which processes are that are spawned by the init
system. With the first type transition I permit these processes to
transition to the guix_daemon_t domain when the executables are
labeled as guix_daemon_exec_t (such as the daemon executable itself,
and all the helpers it spawns).
This much is obvious. But the second type transition is less obvious.
It is needed to make sure that we can enter the guix_daemon_t domain
even when running the daemon from an executable in the store (which
will be running in the “guix_store_content_t” domain). Thinking of
this, I wonder if maybe that’s actually a mistake and shouldn’t be
permitted.
* A possible problem is that I assign all files with a name matching
“/gnu/store/.+-(guix-.+|profile)/bin/guix-daemon” the label
“guix_daemon_exec_t”; this means that *any* file with that name in any
profile would be permitted to run in the guix_daemon_t domain. This
is not ideal. An attacker could build a package that provides this
executable and convince a user to install and run it, which lifts it
into the guix_daemon_t domain. At that point SELinux could not
prevent it from accessing files that are allowed for processes in that
domain (such as the actual daemon).
This makes me wonder if we could do better by generating a much more
restrictive policy at installation time, so that only the *exact* file
name of the currently installed guix-daemon executable would be
labelled with guix_daemon_exec_t, instead of using a regular
_expression_ like that. This means that root would have to
install/upgrade the policy at installation time whenever the Guix
package that provides the effectively running guix-daemon executable
is upgraded. Food for thought.
Without further ado, here’s the patch:
--
Ricardo
| [Prev in Thread] | Current Thread | [Next in Thread] |