Bug 1698575 - SELinux is preventing rngd from 'write' accesses on the file write_wakeup_threshold.
Summary: SELinux is preventing rngd from 'write' accesses on the file write_wakeup_thr...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 30
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:fe6e851ea7db6b1d1d0f56937bf...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-10 16:15 UTC by Matt Fagnani
Modified: 2019-04-21 07:55 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.14.3-29.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-13 00:05:26 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Matt Fagnani 2019-04-10 16:15:22 UTC
Description of problem:
To address the rngd execmem denials during the loading of shared libraries which prevented rngd from starting which I reported in bug 1697886, I ran
sudo ausearch -c 'rngd' --raw | audit2allow -M my-rngd
sudo semodule -X 300 -i my-rngd.pp

After that the rngd service started during booting without any more denials. I updated to the selinux-policy-3.14.3-28
packages from Koji. On the next boot after that update, I saw this denial of rngd writing to write_wakeup_threshold.
The journal showed the following regarding rngd.

journalctl -b --no-hostname | grep rng
Apr 10 11:02:27 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=rngd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr 10 11:02:27 rngd[718]: Initalizing available sources
Apr 10 11:02:27 rngd[718]: Failed to init entropy source hwrng
Apr 10 11:02:27 rngd[718]: Failed to init entropy source rdrand
Apr 10 11:02:52 rngd[718]: Initalizing AES buffer
Apr 10 11:02:52 rngd[718]: Enabling JITTER rng support
Apr 10 11:02:53 rngd[718]: Initalizing entropy source jitter
Apr 10 11:02:53 rngd[718]: PKCS11 Engine /usr/lib64/opensc-pkcs11.so Error: No such file or directory
Apr 10 11:02:53 rngd[718]: Failed to init entropy source pkcs11
Apr 10 11:02:53 audit[718]: AVC avc:  denied  { write } for  pid=718 comm="rngd" name="write_wakeup_threshold" dev="proc" ino=25192 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file permissive=0
Apr 10 11:02:53 rngd[718]: unable to adjust write_wakeup_threshold: Permission denied

The same denial occurred when I ran sudo systemctl restart rngd.
SELinux is preventing rngd from 'write' accesses on the file write_wakeup_threshold.

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

If you believe that rngd should be allowed write access on the write_wakeup_threshold 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 'rngd' --raw | audit2allow -M my-rngd
# semodule -X 300 -i my-rngd.pp

Additional Information:
Source Context                system_u:system_r:rngd_t:s0
Target Context                system_u:object_r:sysctl_kernel_t:s0
Target Objects                write_wakeup_threshold [ file ]
Source                        rngd
Source Path                   rngd
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.3-28.fc30.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.0.7-300.fc30.i686 #1 SMP Mon Apr
                              8 18:28:35 UTC 2019 i686 i686
Alert Count                   2
First Seen                    2019-04-10 11:52:25 EDT
Last Seen                     2019-04-10 11:55:19 EDT
Local ID                      4ff17be8-1637-45f0-b110-dd0e98940bdc

Raw Audit Messages
type=AVC msg=audit(1554911719.263:297): avc:  denied  { write } for  pid=2762 comm="rngd" name="write_wakeup_threshold" dev="proc" ino=46300 scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:object_r:sysctl_kernel_t:s0 tclass=file permissive=0


Hash: rngd,rngd_t,sysctl_kernel_t,file,write

Version-Release number of selected component:
selinux-policy-3.14.3-28.fc30.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.10.0
hashmarkername: setroubleshoot
kernel:         5.0.7-300.fc30.i686
type:           libreport

Potential duplicate: bug 880337

Comment 2 Adam Williamson 2019-04-11 15:08:11 UTC
Someone on the Bodhi update reported another issue with write_wakeup_threshold:

https://bodhi.fedoraproject.org/updates/FEDORA-2019-b514a5c8a3#comment-926118

It seems like it's possible something really did go wrong with that policy in the selinux-policy-3.14.3-28.fc30 build for some reason?

Comment 3 Adam Williamson 2019-04-11 15:09:52 UTC
I note this line in the -28 changelog:

- Remove duplicate definition of kernel_rw_kernel_sysctl()

Perhaps it wasn't exactly a duplicate after all?

Comment 4 Adam Williamson 2019-04-11 15:14:01 UTC
Yes. I think that's the problem.

The definition that was removed is this:

====

interface(`kernel_rw_kernel_sysctl',`
       gen_require(`
               type proc_t, sysctl_t, sysctl_kernel_t;
       ')

       rw_files_pattern($1, { proc_t sysctl_t sysctl_kernel_t }, sysctl_kernel_t)

       list_dirs_pattern($1, { proc_t sysctl_t }, sysctl_kernel_t)
')

====

The definition that remains is this:

====

interface(`kernel_rw_kernel_sysctl',`
	gen_require(`
		type proc_t, sysctl_t, sysctl_kernel_ns_last_pid_t;
	')

	rw_files_pattern($1, { proc_t sysctl_t sysctl_kernel_ns_last_pid_t }, sysctl_kernel_ns_last_pid_t)

	list_dirs_pattern($1, { proc_t sysctl_t }, sysctl_kernel_ns_last_pid_t)
')

====

Those don't seem to be duplicates at all, they are different rules for different purposes; it looks more like the one that is still there should have a different name. Perhaps it was copy/pasted from the original 'kernel_rw_kernel_sysctl' as a base, and then whoever did that forgot to change the name?

Comment 5 Adam Williamson 2019-04-11 15:28:02 UTC
Yeah. So you fixed this as a typo on 'rawhide' branch:

https://github.com/fedora-selinux/selinux-policy/commit/cfd49d70cfbb8daf5ceb6617c3f05450fdf5d2dd

But for some reason did not apply that change to the F30 branch, instead doing this erroneous "Remove duplicate definition" commit.

Comment 7 Lukas Vrabec 2019-04-12 08:23:18 UTC
Merged.

Thanks.

Comment 8 Fedora Update System 2019-04-12 09:50:21 UTC
selinux-policy-3.14.3-29.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7cb094d99a

Comment 9 Matt Fagnani 2019-04-12 18:39:13 UTC
Thanks for your explanation and fix. I updated to 3.14.3-29 from koji. I ran sudo semodule -X 300 -r my-rngd to remove the custom module I installed with the rules
allow rngd_t self:process execmem;
allow rngd_t sysctl_kernel_t:file write;

When I ran sudo systemctl restart rngd, rngd didn't start due to the execmem denial I reported in #1697886
type=AVC msg=audit(1555086820.827:339): avc:  denied  { execmem } for  pid=2651 comm="rngd" scontext=system_u:system_r:rngd_t:s0 tcontext=system_u:system_r:rngd_t:s0 tclass=process permissive=0

So I ran sudo ausearch -c 'rngd' --raw -ts today | audit2allow -M my-rngd-2
sudo semodule -i my-rngd-2.pp
which just had the rule 
allow rngd_t self:process execmem;

rngd started correctly when I ran sudo systemctl restart rngd again, and the write denial on /proc/sys/kernel/random/write_wakeup_threshold didn't happen. I didn't see the write denial on write_wakeup_threshold when rngd started during the next boot. This denial appears to be fixed in 3.14.3-29.

Comment 10 Fedora Update System 2019-04-13 00:05:26 UTC
selinux-policy-3.14.3-29.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, 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.