guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SELinux log


From: Ricardo Wurmus
Subject: Re: SELinux log
Date: Fri, 07 Jun 2019 22:46:38 +0200
User-agent: mu4e 1.2.0; emacs 26.2

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]