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

Hello Daniel,

Thanks a lot for this.

Daniel Brooks <db48x@db48x.net> writes:

This commit message is somewhat unorthodox. :-)

Perhaps it can be shortened to:

guix-daemon to account for daemon updates and newer SELinux.

[...]

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).

Anyway! I tried it on RHEL8, and had to do a few more tweaks to get it

working:

Can you test these additional changes on Fedora?

With this, I no longer have to go through 'guix pack' and 'podman' to

run Guix packages on my RHEL workstation! :-)

Also, is it OK to add you to the list of contributors at the top of the

file with this name and address?

Thanks! It's really great to get this in before 1.2.0.

Marius Bakke <marius@gnu.org> writes:

You're welcome.

I suppose. Personally I dislike the changelog style commit messages, but

when in Rome…

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.

This one is a little unusual; is your service file symlinked or something?

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.

These are fine; in fact I discovered these myself this morning and was

going to send a patch.

Yes, I'll let you know if there are any problems. Also, I'll investigate

the socket file some more.

Ideal :)

Certainly.

db48x

Daniel Brooks <db48x@db48x.net> writes:

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

first person style.

Fair point. I can imagine a scenario when I'm stuck on a SELinux system

without an internet connection.

Hmm. Could it be because /etc/systemd/system/guix-daemon.service refers

to /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon?

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.

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.

Marius Bakke <marius@gnu.org> writes:

That was it. Not sure how I left that one out, in fact.

Ok, I figured this one out. When the socket file is created it is

labeled at guix_daemon_conf_t, but the filecon rules will cause that to

be relabeled to guix_daemon_socket_t at some point in the future. When

the guix-daemon process stops it tries to delete the socket file, but

can't. I'll go ahead and include the rule.

Will do.

The first two are already covered by the new policy, and the third is

inconsequential. The kernel checks on our behalf to see if our child

processes are allowed to inherit our signal state. That's usually

disallowed, so that rule is marked 'dontaudit' so that it doesn't spam

the logs; you probably had that disabled. I'm not going to add a rule

allowing that one; It would just cause accidents.

db48x

Daniel Brooks <db48x@db48x.net> writes:

OK.

Thanks for investigating.

Interestingly, after updating the system (both RHEL8 and Guix) and

rebooting, I got new SELinux troubles!

I had to add these additional rules to make guix-daemon start again:

Do these look sane to you? I can squash them into the commit if so.

Marius Bakke <marius@gnu.org> writes:

At some point we should track down why that one is necessary, perhaps

Guile has a JIT compiler or something?

This one looks pretty suspicious. I think it would allow any file

labeled guix_store_content_t to run in the init_t domain? We wouldn't

want that.

db48x

Daniel Brooks <db48x@db48x.net> writes:

Ding ding ding.

https://wingolog.org/archives/2019/05/24/lightening-run-time-code-generation

Right. The guix_store_content_t file in question was 'guile', which I

suppose is a kind of special case. Can you think of any workarounds

for this?

Are you testing with the latest version of guix-daemon?

This update adds a filecon rule for the guix-daemon shell script in the store.

Daniel Brooks <db48x@db48x.net> writes:

I reworded this slightly and pushed to 'master'.

Daniel Brooks <db48x@db48x.net> writes:

Pushed to the 'version-1.2.0' branch, which will show up on 'master'

eventually. Thank you!