Hi Laura,
> My log shows that
> SELinux would have prevented the daemon from running, like when I had
> it in enforcing mode:
Thank you, the log is helpful (even though it looks like your mail
client reformatted it, which makes it very hard to read).
Searching for “denied” we see the following classes of errors:
1) accessing libnss (for NSCD communication)
2) modifying the database
3) linking temp files (I don’t know what this is about)
4) invoking the “substitute” helper
5) connecting to the substitute servers via HTTPS
While the policy template file etc/guix-daemon.cil.in misses a couple of
labels and transitions (e.g. for database and substitute servers), I
think something’s wrong with your file labels.
The log shows me that
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libnss_files-2.28.so
doesn’t have the SELinux context that I expect according to the policy
file.
The policy file template contains this rule:
(filecon "@storedir@/[^/]+/.+"
any (unconfined_u object_r guix_store_content_t (low low)))
Once configured as etc/guix-daemon.cil the rule should be
(filecon "/gnu/store/[^/]+/.+"
any (unconfined_u object_r guix_store_content_t (low low)))
I would expect that this matches
/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libnss_files-2.28.so.
The guix_store_content_t type is used for all files in the store. The
policy says that the daemon (which is labeled with the “guix_daemon_t”
type) can access these files using various syscalls:
--8<---------------cut here---------------start------------->8---
;; Access to store items
(allow guix_daemon_t
guix_store_content_t
(dir (reparent
create
getattr setattr
search rename
add_name remove_name
open write
rmdir)))
(allow guix_daemon_t
guix_store_content_t
(file (create
lock
setattr getattr
execute execute_no_trans
link unlink
map
rename
open read write)))
(allow guix_daemon_t
guix_store_content_t
(lnk_file (create
getattr setattr
link unlink
read
rename)))
--8<---------------cut here---------------end--------------->8---
According to your audit log file access using “map” (among others) was
denied, even though the policy explicitly allows it (see above):
> type=AVC msg=audit(1559870056.930:262): avc: denied { map } for
> pid=750 comm="guix-daemon"
> path="/gnu/store/h90vnqw0nwd0hhm1l5dgxsdrigddfmq4-glibc-2.28/lib/libnss_files-2.28.so"
> dev="dm-0" ino=559457 scontext=system_u:system_r:init_t:s0
> tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=1
“scontext” means “source context” (i.e. the context of the guix-daemon
process), “tcontext” means “target context” (i.e. the context of the
file). Here we see that both contexts are wrong, the one for the daemon
(“system_u:system_r:init_t:s0”) and the one for the target file
(“unconfined_u:object_r:user_tmp_t:s0”).
We want these to be “…:guix_daemon_t:…” and
“unconfined_u:object_r:guix_store_content_t:…”, respectively. (You can
check the context of a file with “ls -alZ”.)
Did you run “restorecon” on the store to recursively label all files?
Labeling files can take a long time (> 10 mins). When SELinux is
enabled and a policy is loaded it should automatically label new files
according to the policy, so perhaps these files were created while
SELinux was disabled?
I hope these comments are helpful in understanding the policy and
SELinux. If you are confused by any of this please ask and I’ll try to
explain the basic concepts you need to know to understand enough of
SELinux.
--
Ricardo
