Bug 1880948 - SELinux is preventing chronyd from 'read' accesses on the soubor wlp4s0.sources.
Summary: SELinux is preventing chronyd from 'read' accesses on the soubor wlp4s0.sources.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 33
Hardware: x86_64
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:8d0a5a1f335f33f2a126e37bf30...
: 1877629 1917515 (view as bug list)
Depends On:
Blocks: F33FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2020-09-21 08:26 UTC by Karel Volný
Modified: 2021-05-09 01:15 UTC (History)
24 users (show)

Fixed In Version: selinux-policy-3.14.6-29.fc33 selinux-policy-3.14.6-37.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-09 01:15:00 UTC
Type: ---


Attachments (Terms of Use)

Description Karel Volný 2020-09-21 08:26:53 UTC
Description of problem:
This just began appearing after upgrade to F33, I do not know why, but I'm getting it a few times a day ...
SELinux is preventing chronyd from 'read' accesses on the soubor wlp4s0.sources.

*****  Plugin catchall (100. confidence) suggests   **************************

Pokud jste přesvědčeni, že má chronyd mít ve výchozím stavu přístup read na wlp4s0.sources file.
Then měli byste tento problém nahlásit jako chybu.
Abyste přístup povolili, můžete vygenerovat lokální modul pravidel.
Do
prozatím tento přístup povolíte příkazy:
# ausearch -c 'chronyd' --raw | audit2allow -M my-chronyd
# semodule -X 300 -i my-chronyd.pp

Additional Information:
Source Context                system_u:system_r:chronyd_t:s0
Target Context                system_u:object_r:initrc_var_run_t:s0
Target Objects                wlp4s0.sources [ file ]
Source                        chronyd
Source Path                   chronyd
Port                          <Neznámé>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            <Neznámé>
Local Policy RPM              selinux-policy-targeted-3.14.6-27.fc33.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.8.9-301.fc33.x86_64 #1 SMP Mon
                              Sep 14 19:30:07 UTC 2020 x86_64 x86_64
Alert Count                   2
First Seen                    2020-09-21 10:24:33 CEST
Last Seen                     2020-09-21 10:24:33 CEST
Local ID                      d85e431d-6724-4bff-8441-8988db60e57a

Raw Audit Messages
type=AVC msg=audit(1600676673.810:75540): avc:  denied  { read } for  pid=994 comm="chronyd" name="wlp4s0.sources" dev="tmpfs" ino=2165454 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0


Hash: chronyd,chronyd_t,initrc_var_run_t,file,read


Additional info:
component:      selinux-policy
reporter:       libreport-2.14.0
hashmarkername: setroubleshoot
kernel:         5.8.9-301.fc33.x86_64
type:           libreport

Comment 1 Milos Malik 2020-09-21 09:26:55 UTC
Can you find out where is the wlp4s0.sources file located?

# find / -inum 2165454

Thank you.

Comment 2 Karel Volný 2020-09-21 15:01:23 UTC
(In reply to Milos Malik from comment #1)
> Can you find out where is the wlp4s0.sources file located?
> 
> # find / -inum 2165454
> 
> Thank you.

this doesn't work (yes, I also took the ino from the most recent error I got), however searching by name, I see this one:

# ls -lZ /run/chrony-dhcp/wlp4s0.sources
-rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 29 21. zář 16.55 /run/chrony-dhcp/wlp4s0.sources

Comment 3 Karel Volný 2020-09-22 07:30:43 UTC
ok, looks like the file gets deleted/recreated periodically, and the error happens right after the file gets created

I just got the report at 09:25:34, and seraching immediately, I see the file time 9:25 -

[root@kvolny ~]# find / -inum 5503764
/run/chrony-dhcp/wlp4s0.sources
find: ‘/run/user/1000/doc’: Operace zamítnuta
find: ‘/proc/571956/task/571956/net’: Nepřípustný argument
find: ‘/proc/571956/net’: Nepřípustný argument
[root@kvolny ~]# ls -lZ /run/chrony-dhcp/wlp4s0.sources
-rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 29 22. zář 09.25 /run/chrony-dhcp/wlp4s0.sources
[root@kvolny ~]# cat /run/chrony-dhcp/wlp4s0.sources
server 10.192.206.245 iburst

Comment 4 Zdenek Pytela 2020-09-23 18:07:34 UTC
Karle,

There certainly is something to adjust in the selinux policy. I noticed you reported not being aware why, but still can you somehow help to isolate the problem? Is there something special/non-default in your environment?

What additionally confuses me a bit is the type of /run/chrony-dhcp/wlp4s0.sources: it should be just var_run_t (which is incorrect anyway), according to current rules. Did you run chcon/restorecon on the directory, the semanage-fcontext command, or created a custom policy module?

  # ls -laZ /run/chrony-dhcp/ 

We have an unnamed transition for a file only though in the policy:

  # sesearch -T -s NetworkManager_t -t NetworkManager_initrc_exec_t -c process
type_transition NetworkManager_t NetworkManager_initrc_exec_t:process initrc_t;
  # sesearch -T -s initrc_t -t var_run_t | grep "_t;"
type_transition initrc_t var_run_t:file initrc_var_run_t;
  # sesearch -T -s initrc_t -t var_run_t | grep chrony
<>

Comment 5 Karel Volný 2020-09-24 12:38:37 UTC
(In reply to Zdenek Pytela from comment #4)
> There certainly is something to adjust in the selinux policy. I noticed you
> reported not being aware why, but still can you somehow help to isolate the
> problem? Is there something special/non-default in your environment?

well, I believe the answer to "non-default" probably lies in the initial description - this is not a clean installation but rather an upgrade, and there are always problems with upgrades ;-)

I've used msuchy's fedora-upgrade with the online method, which isn't the one preferred ...

> What additionally confuses me a bit is the type of
> /run/chrony-dhcp/wlp4s0.sources: it should be just var_run_t (which is
> incorrect anyway), according to current rules. Did you run chcon/restorecon
> on the directory, the semanage-fcontext command, or created a custom policy
> module?

no, I haven't done anything special

>   # ls -laZ /run/chrony-dhcp/ 

[root@kvolny ~]# ls -laZ /run/chrony-dhcp/
celkem 8
drwxr-xr-x.  2 root root system_u:object_r:var_run_t:s0          80 24. zář 14.08 .
drwxr-xr-x. 49 root root system_u:object_r:var_run_t:s0        1260 24. zář 09.10 ..
-rw-r--r--.  1 root root system_u:object_r:initrc_var_run_t:s0   50 24. zář 09.08 ens1u1.sources
-rw-r--r--.  1 root root system_u:object_r:initrc_var_run_t:s0   29 24. zář 14.08 wlp4s0.sources

running sesearch queries, the same results on my system

Comment 6 Christian Labisch 2020-09-25 15:40:05 UTC
SELinux is preventing chronyd from read access on the file wlp3s0.sources.
Plugin catchall (100. confidence) suggests

If you believe that chronyd should be allowed read access on the wlp3s0.sources file by default.
Then you should report this as a bug. You can generate a local policy module to allow this access.
Do allow this access for now by executing:

ausearch -c 'chronyd' --raw | audit2allow -M my-chronyd
semodule -X 300 -i my-chronyd.pp

sudo ausearch -c 'chronyd'

time->Fri Sep 25 08:09:14 2020 type=AVC msg=audit(1601014154.941:198): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.370:274): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.390:276): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.586:296): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:09:15 2020 type=AVC msg=audit(1601014155.606:297): avc: denied { read } for pid=863 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=34309 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.084:187): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.784:262): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.807:264): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.929:284): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

time->Fri Sep 25 08:14:27 2020 type=AVC msg=audit(1601014467.948:285): avc: denied { read } for pid=866 comm="chronyd" name="wlp3s0.sources" dev="tmpfs" ino=35165 scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:object_r:initrc_var_run_t:s0 tclass=file permissive=0

Comment 7 dirk koehler 2020-09-25 15:51:39 UTC
I can confirm what Christian Labisch reported

Comment 8 Christian Labisch 2020-10-01 10:25:11 UTC
Upgraded to selinux-policy 3.14.6-28.fc33 ... nothing changed - getting the same messages.
The alerts appear after booting and logging in, and also after starting a virtual machine.

Comment 9 Jonathan Haas 2020-10-01 13:08:50 UTC
Similar problem has been detected:

Happened randomly in background

hashmarkername: setroubleshoot
kernel:         5.8.11-300.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-27.fc33.noarch
reason:         SELinux is preventing chronyd from 'read' accesses on the Datei enp3s0.sources.
type:           libreport

Comment 10 Dominik 'Rathann' Mierzejewski 2020-10-07 09:23:44 UTC
Similar problem has been detected:

This appeared after upgrade from F32 to F33 with updates-testing enabled on Oct 7th.

My DHCP server hands out NTP servers if that's relevant.

hashmarkername: setroubleshoot
kernel:         5.8.13-300.fc33.x86_64
reason:         SELinux is preventing chronyd from 'read' accesses on the file wlp1s0.sources.
type:           libreport

Comment 11 Gwendal 2020-10-08 13:56:05 UTC
Same problem here with a freshly installed and updated (today) Fedora 33. Time never gets udpated because of this bug.

Just to be sure, I did a `sudo setenforce 0`, followed by disabling/enabling the feature in the control center, and this time chrony managed to update my clock correctly.

Comment 12 Kevin Wolf 2020-10-14 09:02:29 UTC
Similar problem has been detected:

This happens every time I boot the machine. I suppose it might be in the context of bringing up the network interface.

hashmarkername: setroubleshoot
kernel:         5.8.14-300.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-28.fc33.noarch
reason:         SELinux is preventing chronyd from 'read' accesses on the Datei ens1u2u1u2.sources.
type:           libreport

Comment 13 Jonathan Haas 2020-10-14 10:45:15 UTC
Similar problem has been detected:

Alter appeared randomly in background

hashmarkername: setroubleshoot
kernel:         5.8.13-300.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-28.fc33.noarch
reason:         SELinux is preventing chronyd from 'read' accesses on the Datei enp3s0.sources.
type:           libreport

Comment 14 Fedora Blocker Bugs Application 2020-10-14 15:53:42 UTC
Proposed as a Freeze Exception for 33-final by Fedora user dustymabe using the blocker tracking app because:

 It would be nice to be able to get NTP server's from DHCP for Fedora 33.

Comment 15 Kamil Páral 2020-10-14 16:09:32 UTC
Does this problem have any consequences for chrony functionality, can somebody check? If you disable NTP, change the system time and then enable NTP again, will it sync to the proper time? (I think that's how this is supposed to work). With SELinux enforcing, of course.

Comment 16 Dusty Mabe 2020-10-14 16:24:11 UTC
(In reply to Kamil Páral from comment #15)
> Does this problem have any consequences for chrony functionality, can
> somebody check? If you disable NTP, change the system time and then enable
> NTP again, will it sync to the proper time? (I think that's how this is
> supposed to work). With SELinux enforcing, of course.

I think this depends on the user's environment. This bug causes NTP servers provided by their DHCP server to not get applied. If they have access to the public internet then they will probably still get a correct time setting, though with servers that aren't preferred. If they don't have access to the public internet then they could get no NTP server at all.

Comment 17 Zdenek Pytela 2020-10-14 21:11:11 UTC
I've submitted rawhide PRs to address the issue:
https://github.com/fedora-selinux/selinux-policy-contrib/pull/344
https://github.com/fedora-selinux/selinux-policy/pull/456

Comment 18 Adam Williamson 2020-10-14 21:15:50 UTC
+5 votes in https://pagure.io/fedora-qa/blocker-review/issue/173 , marking as accepted. Zdenek, can you backport to F33 and do a build/update for F33?

Comment 19 Zdenek Pytela 2020-10-14 21:22:23 UTC
Surely I'll backport the PRs (if accepted) to F33 and create builds so that it can be tested in different scenarios/environments as I cannot make sure the suggested fix is complete and covers all possible usage.

Comment 20 Dusty Mabe 2020-10-15 00:30:30 UTC
I'll be happy to test once a build is available for F33. We have a test that runs in the Fedora CoreOS build pipeline that will tell us if it's working.

Comment 21 Zdenek Pytela 2020-10-15 10:05:19 UTC
A scratchbuild is available here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=53505109

Comment 22 Dominik 'Rathann' Mierzejewski 2020-10-15 11:36:22 UTC
(In reply to Zdenek Pytela from comment #21)
> A scratchbuild is available here:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=53505109

That's selinux-policy-3.14.6-24.200.bz1880948.fc33, but the latest build for F33 is selinux-policy-3.14.6-28.fc33 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1617771).

So, technically, this is a downgrade.

Comment 23 Dusty Mabe 2020-10-16 03:58:11 UTC
That scratch build passes the test.

Comment 24 Alvin 2020-10-17 11:41:11 UTC
Similar problem has been detected:

SELinux errors on default install of Fedora 33 beta.

hashmarkername: setroubleshoot
kernel:         5.8.15-301.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-28.fc33.noarch
reason:         SELinux is preventing chronyd from 'read' accesses on the file enp0s31f6.sources.
type:           libreport

Comment 25 Fedora Update System 2020-10-20 08:52:11 UTC
FEDORA-2020-5cd3fad6d5 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5cd3fad6d5

Comment 26 Christian Labisch 2020-10-20 09:05:06 UTC
selinux-policy 3.14.6-29.fc33 solved the problem ... thank you, Zdenek !

Comment 27 Fedora Update System 2020-10-23 22:17:57 UTC
FEDORA-2020-5cd3fad6d5 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 28 Doncho Gunchev 2021-01-18 09:22:22 UTC
Similar problem has been detected:

Happend right after switching to another WiFi AP.

hashmarkername: setroubleshoot
kernel:         5.10.7-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-34.fc33.noarch
reason:         SELinux is preventing chronyd from 'read' accesses on the file wlp1s0.sources.
type:           libreport

Comment 29 Doncho Gunchev 2021-01-18 09:29:54 UTC
This just appeared after selinux-policy-targeted-3.14.6-33.fc33_3.14.6-34.fc33.noarch.drpm / selinux-policy-targeted-3.14.6-34.fc33.noarch

Comment 30 Luc Van Hecke 2021-01-18 15:59:04 UTC
*** Bug 1917515 has been marked as a duplicate of this bug. ***

Comment 31 Zdenek Pytela 2021-02-22 20:09:26 UTC
*** Bug 1877629 has been marked as a duplicate of this bug. ***

Comment 32 James Ralston 2021-03-04 18:48:06 UTC
Reopening, because this is not resolved.

The core problem is that the labels for /run/chrony and /run/chrony-dhcp are different:

$ ls -lsadZ /run/chrony*
0 drwxr-x---. 2 chrony chrony system_u:object_r:chronyd_var_run_t:s0 80 Mar  4 13:20 /run/chrony/
0 drwxr-xr-x. 2 root   root   system_u:object_r:var_run_t:s0         60 Mar  4 10:40 /run/chrony-dhcp/

chronyd_t has wide permissions to chronyd_var_run_t:

$ sesearch --allow --source chronyd_t --target chronyd_var_run_t
allow chronyd_t chronyd_var_run_t:dir { add_name create ioctl link lock read remove_name rename reparent rmdir setattr unlink write };
allow chronyd_t chronyd_var_run_t:file { append create getattr ioctl link lock open read rename setattr unlink write };
allow chronyd_t chronyd_var_run_t:sock_file { create ioctl link lock read rename setattr unlink };
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow domain pidfile:sock_file { append getattr open write };
allow nsswitch_domain pidfile:dir { getattr open search };

…but a much more restricted set of permissions to the generic var_run_t:

$ sesearch --allow --source chronyd_t --target var_run_t
allow chronyd_t var_run_t:dir { add_name remove_name write };
allow domain base_file_type:dir { getattr open search };
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow domain pidfile:sock_file { append getattr open write };
allow domain var_run_t:dir { ioctl lock read };
allow domain var_run_t:lnk_file { getattr read };
allow nsswitch_domain pidfile:dir { getattr open search };

Because chronyd_t lacks the ability to read arbitrary var_run_t files, chronyd cannot load the *.sources files in /run/chrony-dhcp.

The quickest solution would be to change /run/chrony-dhcp to have the chronyd_var_run_t label, the same as /run/chrony.

But this would be wrong, because this would give chronyd_t the ability to write or remove files in /run/chrony-dhcp. And it should not have that ability: chronyd *consumes* files in /run/chrony-dhcp, but it does not produce them, and thus should not have the ability the write or remove files there.

Giving chronyd_t read permission on any arbitrary var_run_t file would prevent the SELinux denial… but again, chronyd_t should not have that ability. It does not need to be able to read any arbitrary var_run_t file.

I assert that the best solution here is to:

1. Create a new file context, e.g. chronyd_sources_var_run_t.
2. Give chronyd_t the ability to read files (and read/search directories) with the chronyd_sources_var_run_t context.
3. Change the file context of /run/chronyd-sources from var_run_t to chronyd_sources_var_run_t.

These actions will give chronyd the ability to read the *.sources files in /run/chronyd-sources, but will not grant chronyd any wider permissions than that.

Counterarguments?

Comment 33 James Ralston 2021-03-26 17:52:23 UTC
OK, I see what's happening now.

There are type transitions to ensure that when chronyd_t creates a dir/file/socket in a var_run_t directory, it transitions to chronyd_var_run_t:

$ sesearch --type_trans --default chronyd_var_run_t
type_transition chronyd_t var_run_t:dir chronyd_var_run_t;
type_transition chronyd_t var_run_t:file chronyd_var_run_t;
type_transition chronyd_t var_run_t:sock_file chronyd_var_run_t;
type_transition initrc_t var_run_t:dir chronyd_var_run_t chrony-dhcp;

On a fresh boot, the labels will be correct:

$ ls -lsaZ /run/chrony*
/run/chrony:
total 4
0 drwxr-x---.  2 chrony chrony system_u:object_r:chronyd_var_run_t:s0   80 Mar 26 13:18 ./
0 drwxr-xr-x. 59 root   root   system_u:object_r:var_run_t:s0         1660 Mar 26 13:20 ../
4 -rw-r--r--.  1 root   root   system_u:object_r:chronyd_var_run_t:s0    5 Mar 26 13:17 chronyd.pid
0 srwxr-xr-x.  1 chrony chrony system_u:object_r:chronyd_var_run_t:s0    0 Mar 26 13:17 chronyd.sock=

/run/chrony-dhcp:
total 4
0 drwxr-xr-x.  2 root root system_u:object_r:chronyd_var_run_t:s0   60 Mar 26 13:18 ./
0 drwxr-xr-x. 59 root root system_u:object_r:var_run_t:s0         1660 Mar 26 13:20 ../
4 -rw-r--r--.  1 root root system_u:object_r:chronyd_var_run_t:s0   26 Mar 26 13:18 enp7s0.sources

The problem is that SELinux file context policy isn't in alignment with the type transitions. So relabeling /run resets the file contexts to agree with the file policy, not the transition policy:

$ restorecon -FR -v /run/chrony*
Relabeled /run/chrony-dhcp from system_u:object_r:chronyd_var_run_t:s0 to system_u:object_r:var_run_t:s0
Relabeled /run/chrony-dhcp/enp7s0.sources from system_u:object_r:chronyd_var_run_t:s0 to system_u:object_r:var_run_t:s0

This breaks chronyd, because chronyd doesn't have permission to read var_run_t files.

The solution is to bring the file context policy into alignment with the transition policies:

$ semanage fcontext -a -f a -t chronyd_var_run_t -r 's0' '/var/run/chrony-dhcp(/.*)?'

$ restorecon -FR -v /run/chrony*
Relabeled /run/chrony-dhcp from system_u:object_r:var_run_t:s0 to system_u:object_r:chronyd_var_run_t:s0
Relabeled /run/chrony-dhcp/enp7s0.sources from system_u:object_r:var_run_t:s0 to system_u:object_r:chronyd_var_run_t:s0

It looks like this was already fixed upstream (at <https://github.com/fedora-selinux/selinux-policy>):

commit 7ccbfc9ed1d2da09cb0c51b555fb2c9ffc68c515
Author: Zdenek Pytela <zpytela@redhat.com>
Date:   Thu Dec 10 17:48:03 2020 +0100

    Add default file context for "/var/run/chrony-dhcp(/.*)?"
    
    With the 25d2a5c01c commit, a file transition for /var/run/chrony-dhcp
    was added, but it was not backed by the default file context
    specification.
    
    Resolves: rhbz#1895825

diff --git a/policy/modules/contrib/chronyd.fc b/policy/modules/contrib/chronyd.fc
index 9c06350c2..668f40954 100644
--- a/policy/modules/contrib/chronyd.fc
+++ b/policy/modules/contrib/chronyd.fc
@@ -14,6 +14,7 @@
 /var/log/chrony(/.*)?  gen_context(system_u:object_r:chronyd_var_log_t,s0)
 
 /var/run/chrony(/.*)?  gen_context(system_u:object_r:chronyd_var_run_t,s0)
+/var/run/chrony-dhcp(/.*)?     gen_context(system_u:object_r:chronyd_var_run_t,s0)
 /var/run/chronyd(/.*)? gen_context(system_u:object_r:chronyd_var_run_t,s0)
 /var/run/chrony-helper(/.*)?   gen_context(system_u:object_r:chronyd_var_run_t,s0)
 /var/run/chronyd\.pid  --      gen_context(system_u:object_r:chronyd_var_run_t,s0)

…but this commit hasn't been backported to Fedora 33's selinux-policy yet.

Comment 34 Doncho Gunchev 2021-03-27 22:09:28 UTC
Similar problem has been detected:

Connected to a wifi network.

hashmarkername: setroubleshoot
kernel:         5.11.10-200.fc33.x86_64
package:        selinux-policy-targeted-3.14.6-35.fc33.noarch
reason:         SELinux is preventing chronyd from 'read' accesses on the file wlp2s0.sources.
type:           libreport

Comment 35 Zdenek Pytela 2021-04-09 19:45:03 UTC
I've submitted a Fedora PR to cherry-pick the commit:
https://github.com/fedora-selinux/selinux-policy-contrib/pull/395

James, thank you for the analysis.

Comment 36 Fedora Update System 2021-04-28 11:33:49 UTC
FEDORA-2021-050d4e8def has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-050d4e8def

Comment 37 Fedora Update System 2021-04-29 01:45:38 UTC
FEDORA-2021-050d4e8def has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-050d4e8def`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-050d4e8def

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 38 Fedora Update System 2021-05-09 01:15:00 UTC
FEDORA-2021-050d4e8def has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


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