Bug 1660141 - SELinux policy change not not visible to systemd until daemon-reexec or reboot
Summary: SELinux policy change not not visible to systemd until daemon-reexec or reboot
Keywords:
Status: CLOSED DUPLICATE of bug 1197886
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 30
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-17 15:38 UTC by Maciek Borzecki
Modified: 2020-03-01 13:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-01 13:08:41 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github systemd systemd issues 9997 None closed ListenStream doesn't honor SELinux policy changes until restart 2020-03-01 13:06:16 UTC

Description Maciek Borzecki 2018-12-17 15:38:36 UTC
Description of problem:

I stumbled upon this when working on snapd SELinux policy. When a snap with a socket activated service is installed, we generate a proper socket unit file for systemd, call daemon-reload and start the unit. Socket activated snaps are only allowed to have the socket files under $SNAP_{DATA,COMMON}, i.e. /var/snap/<snap>/.., labeled as snappy_var_t. I have noticed that even though, the snappy policy came with corresponding rules to allow access for init_t, systemd would still fail with denials like this:

----                                                                                                                                                                                                                                                                                                                                                       
time->Mon Dec 17 14:55:47 2018                                                                                                                                                                                                                                                                                                                             
type=AVC msg=audit(1545058547.616:321): avc:  denied  { create } for  pid=1 comm="systemd" name="other" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:var_t:s0 tclass=dir permissive=0                                                                                                                                                   
----                                                                                                                                                                                            

Note, that incorrect target context is used, even though, /var/snap/test-snap/dir is labeled as snappy_var_t.

Rebooting or running systemctl daemon-reexec makes the problem go away.

There is an upstream bug report too: https://github.com/systemd/systemd/issues/9997 The ticket also comes with a simple example to demonstrate the problem.

Version-Release number of selected component (if applicable):
systemd-239-6.git9f3aed1.fc29.x86_64

How reproducible:
always

Additional info:
There is a workaround to the problem, but calling daemon-reexec in %post does not sound too appealing. Any suggestions on what could be done by the package maintainer instead?

Comment 1 Maciek Borzecki 2019-05-13 06:04:57 UTC
Verified the bug to be still present in Fedora 30. Relevant package versions:

systemd-241-8.git9ef65cb.fc30.x86_64

Comment 2 Zbigniew Jędrzejewski-Szmek 2020-03-01 13:08:41 UTC

*** This bug has been marked as a duplicate of bug 1197886 ***


Note You need to log in before you can comment on or make changes to this bug.