Description of problem: Loading third party kernel modules built for various reasons fails after selinux update. I have two machines, one running nvidia's graphics card drivers and the other using the "wl" driver for (broadcom?) wireless chipsets. After upgrading both machines due to that nice kernel privesc, I found myself with machine A unable to start X11/Wayland. Having tried various things I eventually tried manually with the nvidia installer rather than dkms from rpmfusion and read its log output. modprobe was reporting error denied. Curious, I tried machine B with the "wl" driver and sure enough, I couldn't insmod that either. The problem goes away if you boot with selinux=0 or enforcing=0. Version-Release number of selected component (if applicable): 3.13.1-225.10.fc25 How reproducible: Very Steps to Reproduce: 1. Buy some hardware that needs third party kernel modules. 2. Compile said third party kernel modules. 3. Type "modprobe -v <name of module> and watch in glorious frustration as it says "permission denied". Actual results: Will vary depending on where the user experiences. Direct attempts to build and load kernel modules with modprobe -v module_name fail with "permission denied". This may look like: 1) The nvidia installer complains it cannot load nvidia-drm.ko with no further explanation. The logs report the modprobe issue. 2) Users who update and are using dkms for their kernel modules will find they build but suddenly fail to load, meaning they may find their wireless missing or that they can't start X/Wayland. 3) The vmware workstation installer likewise reports an error. vmware-modconfig --install-all reports unable to load module etc. 4) ... Expected results: Typing "modprobe whatever" loads whatever. Additional info: I didn't search too hard to submit this bug report because "modprobe permission denied" doesn't give me anything remotely close. I'm hoping by being thorough people will be able to find the solution that will hopefully arise. Long story short if you are already tracking this issue I'm happy for this bug to be closed as a dupe. I am also aware Fedora does not, as a rule, "support" proprietary products. I would argue that this is not a proprietary product issue in that with the correct labelling, these products would continue to work, as they have previously. I have not bothered investigating what labelling might work, although I will later. For anyone who wants to fix it you ought to be able to: ls -lZ /path/to/a/kernel/module/that/works semanage fcontext -a -t type_from_a_module_that_works_t /full/path/to/your/module.ko restorecon -Rv /path/to/your/module.ko This will permanently add these paths to your policy with the correct labelling, so they will survive a relabel of your filesystem and of course a reboot. You can temporarily make the changes with chcon -t type /path/to/module.ko. I have NOT tried this (and the issue might not be selinux, but I'm fairly confident). However the default policy should not require you to do this.
I have the same problem but with other driver and I get a notification on SELinux Alert Browser: SELinux is preventing modprobe from 'module_load' accesses on the system /usr/lib/modules/4.9.11-200.fc25.x86_64/extra/facetimehd.ko. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that modprobe should be allowed module_load access on the facetimehd.ko system 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 'modprobe' --raw | audit2allow -M my-modprobe # semodule -X 300 -i my-modprobe.pp Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context unconfined_u:object_r:modules_object_t:s0 Target Objects /usr/lib/modules/4.9.11-200.fc25.x86_64/extra/face timehd.ko [ system ] Source modprobe Source Path modprobe Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.13.1-225.10.fc25.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 4.9.11-200.fc25.x86_64 #1 SMP Mon Feb 20 18:11:59 UTC 2017 x86_64 x86_64 Alert Count 1 First Seen 2017-02-27 10:46:15 GMT Last Seen 2017-02-27 10:46:15 GMT Local ID 0b17aed0-3216-49ac-a9a1-3fd28953fdb2 Raw Audit Messages type=AVC msg=audit(1488192375.249:1089): avc: denied { module_load } for pid=9531 comm="modprobe" path="/usr/lib/modules/4.9.11-200.fc25.x86_64/extra/facetimehd.ko" dev="dm-0" ino=655676 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:modules_object_t:s0 tclass=system permissive=0 Hash: modprobe,unconfined_t,modules_object_t,system,module_load
This occurs to me as well. bbswitch and wl refused to load until selinux was set to permissive. Re-enabling to enforcing mode causes no problem after modules were loaded. From what I see, the selinux type is the same for any module, be it loadable or not. E.g. -rw-r--r--. 1 root root system_u:object_r:modules_object_t:s0 7490352 Feb 27 22:48 wl.ko (permission denied) -rw-r--r--. 1 root root system_u:object_r:modules_object_t:s0 16528 Feb 20 20:47 btusb.ko.xz (loadable) -rw-r--r--. 1 root root unconfined_u:object_r:modules_object_t:s0 20144 Feb 27 22:48 bbswitch.ko (permission denied)
I also experience this issue, with virtualbox and nvidia modules. Here's the bug for nvidia: https://bugzilla.redhat.com/show_bug.cgi?id=1427311
Seems corrected on Fedora 25 with selinux-policy-3.13.1-225.11.fc25. Thanks!
This issue has been corrected by the latest selinux-policy updates. I'm clearing the needinfo flags because nobody has actually requested any information from me. However since I can also see it was resolved and why, I'm switching to "fixed in nextrelease" and closing the bug. Still, it would have been nice to hear from someone, especially as this was a breaking change to F25 stable. (In reply to akiross from comment #2) I also noticed this as I had time to check later, but comment #1 already explains the problem: "avc: denied { module_load }" I was very busy at the time and was mostly just extremely irritated I couldn't load my desktop. This issue was raised originally in https://bugzilla.redhat.com/show_bug.cgi?id=1426741 and this is fixed in the package changelog: - Allow can_load_kernmodule to load kernel modules. BZ(1426741) If you care this was fixed by: https://github.com/fedora-selinux/selinux-policy/commit/9dc578dc71518bb42e7b75bd8037a01ccd4d7923 I'm guessing it was introduced by: https://github.com/fedora-selinux/selinux-policy/commit/9a6aec2688fa4e4a64906e8dad69b4ca8f03102d removing the privilege module_load from modules_object_t.