Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1689975 - Policy is blocking systemd reading /lib/modules/$KVER/modules.devname breaking /dev/ node creation
Summary: Policy is blocking systemd reading /lib/modules/$KVER/modules.devname breakin...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2019-03-18 14:43 UTC by Daniel Berrange
Modified: 2019-04-05 17:58 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.14.4-8.fc31
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-04-05 17:58:44 UTC

Attachments (Terms of Use)

Description Daniel Berrange 2019-03-18 14:43:03 UTC
Description of problem:
On a new Fedora 31 install /dev/net/tun does not exist. This is a static device node that systemd creates on startup regardless of whether the kmod is loaded or not.

This is done by the kmod-static-nodes.service unit but it is failing to start:

# systemctl status kmod-static-nodes.service
● kmod-static-nodes.service - Create list of required static device nodes for the current kernel
   Loaded: loaded (/usr/lib/systemd/system/kmod-static-nodes.service; static; vendor preset: disabled)
   Active: inactive (dead) since Mon 2019-03-18 14:26:46 GMT; 1min 11s ago
Condition: start condition failed at Mon 2019-03-18 14:27:56 GMT; 1s ago
           └─ ConditionFileNotEmpty=/lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname was not met
 Main PID: 331 (code=exited, status=0/SUCCESS)

The file /lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname   does exist with non-zero size.

Audit.log reveals that SELinux is blocking this acess

type=AVC msg=audit(1552919426.997:335): avc:  denied  { getattr } for  pid=1 comm="systemd" path="/usr/lib/modules/5.1.0-0.rc0.git9.1.fc31.x86_64/modules.devname" dev="dm-0" ino=753068 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:modules_dep_t:s0 tclass=file permissive=1

The file is labelled with modules_dep_t  type, which is different from what was used in previous Fedora which was modules_object_t

Either the type needs to go back to modules_object_t as in previous Fedora, or the policy needs to grant modules_dep_t read access to systemd via the init_t type.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install fresh Fedora 31 x86_64

Actual results:
/dev/net/tun doesn't exist and  kmod-static-nodes.service  failed to run

Expected results:
/dev/net/tun exists &  kmod-static-nodes.service  runs

Additional info:

Comment 1 dac.override 2019-03-18 17:43:44 UTC
I suppose might be related to either or

The ironic thing is that the labeling is now actually correct. Type module_object_t is for kernel modules only AFAIK.

Comment 2 Jan Pokorný [poki] 2019-03-19 00:29:56 UTC
FTR. there seems to be more fall out, e.g. with jmtpfs:

# jmtpfs /mnt/card
> [...]
> fuse: device not found, try 'modprobe fuse' first

# rpm -q selinux-policy jmtpfs
> selinux-policy-3.14.4-4.fc31.noarch
> jmtpfs-0.4-10.fc30.x86_64

(shout out to both libvirt and jmtpfs/fuse library? for these informed
suggestions the users would be easily lost without)

Comment 3 Lukas Vrabec 2019-03-19 08:31:16 UTC
Thanks for investigation. 

Adding patch: 

commit b28842ef918897da153800b2df47bb991250c421 (HEAD -> rawhide)
Author: Lukas Vrabec <>
Date:   Tue Mar 19 09:26:57 2019 +0100

    Update file context for modutils rhbz#1689975
    - label /lib/modules/<KERNEL_VERSION>/modules.devname as modules_dep_t
    instead of modules_object_t
    - Allow init_t domain to read modules_dep_t files

Comment 4 dac.override 2019-03-19 08:38:47 UTC
Not sure about this but my policy seems to imply that systemd also maps module dependency files.

Comment 5 dac.override 2019-03-19 08:55:02 UTC
Yes looks like you have traces of that as well:

I suspect these two should be removed (provided that module dependency files are labeled properly):


And instead i suppose you would need to add:


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