Hide Forgot
Created attachment 1230761 [details] Denials for the tlp and tlp-rdw packages Description of problem: After installation Version-Release number of selected component (if applicable): tlp-0.9-1.fc25.noarch tlp-rdw-0.9-1.fc25.noarch selinux-policy-3.13.1-225.1.fc25.noarch How reproducible: Every time Steps to Reproduce: 1. Install packages 'tlp' and 'tlp-rdw' 2. Reboot System 3. Observe audit log Actual results: Several denials for binaries `tlp`, `iw`, `x86_energy_perf` and `tpacpi-bat`, `rm` and `mkdir` from source context tlp_t, see attachment. Expected results: Binaries in the package function without denials. Additional info: The package contains functionality specific to Lenovo/IBM Thinkpad laptops. I'm not sure if the denials can be reproduced without the hardware. The denials for `tpacpi-bat` are only reproducible when the kernel module "acpi_call" from here: https://github.com/teleshoes/acpi_call is compiled and loaded.
Judging by the silence of the maintainers, do I understand correctly that the right course of action for me is to spam individual bug reports for every single binary? Somehow I thought that a comprehensive summary of related denials coming from two very specific packages would be more useful, because maintainers could analyze how it is supposed to work, and then fix the SELinux policy in a sensible manner instead of just running audit2allow 6 times in a row. But I seem to be mistaken. I'll reassign the component to the tlp package, maybe their maintainers have a little bit more interest in a functioning package. If that doesn't work, I will just spam the individual Plugin catchall messages as separate issues.
Hi, First, I would suggest using TLP's akmod binaries rather than building your own: http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html#installation This is because Fedora does not support this kernel module, but upstream does support them. So if you can reproduce the issues against their binaries, they maybe able to provide better feedback on the denials specific to that module. I cc-ed the upstream developer, but feel free to make a ticket upstream and provide the URL in this bug report. https://github.com/linrunner/TLP/issues I'll see what I can do from my side, but unfortunately I do not have a Thinkpad available to me if this is a HW specific issue. Upstream maybe able to help here as well.
Hi, this interesting. For my plain vanilla F25 installation i can confirm this one: > type=AVC msg=audit(1481382358.188:206): avc: denied { add_name } for pid=1485 comm="tpacpi-bat" name="call" scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir permissive=1 Stems from tpacpi-bat writing to /proc/acpi/call. I'll add a policy for it upstream for version 1.0 as soon as i learn how to write them. I don't observe AVCs here when writing to /var/lib/tlp or /run/tlp, but i think it's reasonable to add policies for TLP's "binaries" (scripts). Also no AVCs here for binaries outside tlp, tlp-rdw like x86_energy_perf, iw, ethtool doing their normal duties on preset paths like: > type=AVC msg=audit(1481382332.490:377): avc: denied { open } for pid=21665 comm="x86_energy_perf" path="/dev/cpu/0/msr" dev="devtmpfs" ino=1107 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:cpu_device_t:s0 tclass=chr_file permissive=1 > type=AVC msg=audit(1481382332.519:383): avc: denied { open } for pid=21683 comm="iw" path="/proc/21683/net/psched" dev="proc" ino=4026531994 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:proc_net_t:s0 tclass=file permissive=1 I see no point in adding policies to tlp, tlp-rdw packages for this.
So I removed my custom SELinux policy modules, and the denial situation has changed slightly. (In reply to Jeremy Newton from comment #2) > Hi, > > First, I would suggest using TLP's akmod binaries rather than building your > own: > http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management. > html#installation Thanks, I did that now. That simplyifies things. I now have a new denial, apparently the akmods module has the wrong context: > type=AVC msg=audit(1488985100.967:143): avc: denied { module_load } for pid=1499 comm="modprobe" path="/usr/lib/modules/4.9.13-200.fc25.x86_64/extra/acpi_call/acpi_call.ko" dev="dm-0" ino=1985736 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:modules_object_t:s0 tclass=system permissive=1 (In reply to Thomas Koch from comment #3) > Hi, > > this interesting. For my plain vanilla F25 installation i can confirm this > one: > > > type=AVC msg=audit(1481382358.188:206): avc: denied { add_name } for pid=1485 comm="tpacpi-bat" name="call" scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir permissive=1 I have that too, and in addition to that: > type=AVC msg=audit(1488985100.998:144): avc: denied { dac_override } for pid=1505 comm="tpacpi-bat" capability=1 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:tlp_t:s0 tclass=capability permissive=1 > type=AVC msg=audit(1488985100.998:147): avc: denied { create } for pid=1505 comm="tpacpi-bat" name="call" scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=file permissive=1 > type=AVC msg=audit(1488985100.998:145): avc: denied { write } for pid=1505 comm="tpacpi-bat" name="acpi" dev="proc" ino=4026531977 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=dir permissive=1 > I don't observe AVCs here when writing to /var/lib/tlp or /run/tlp, but i > think it's reasonable to add policies for TLP's "binaries" (scripts). > Also no AVCs here for binaries outside tlp, tlp-rdw like x86_energy_perf, > iw, ethtool doing their normal duties on preset paths like: I still get these, though: > type=AVC msg=audit(1488985573.902:176): avc: denied { write } for pid=3295 comm="iw" path="/run/tlp/lock_tlp" dev="tmpfs" ino=28798 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tlp_var_run_t:s0 tclass=file permissive=0 > type=AVC msg=audit(1488985573.906:177): avc: denied { write } for pid=3296 comm="iwconfig" path="/run/tlp/lock_tlp" dev="tmpfs" ino=28798 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tlp_var_run_t:s0 tclass=file permissive=0 > type=AVC msg=audit(1488985573.913:178): avc: denied { write } for pid=3299 comm="ethtool" path="/run/tlp/lock_tlp" dev="tmpfs" ino=28798 scontext=system_u:system_r:ifconfig_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tlp_var_run_t:s0 tclass=file permissive=0 Which is subject of Fedora bug #1399848 that was "fixed", presumably by running audit2allow. Not all of the denials come up at boot, so be sure to unplug and re-plug from the power source to trigger denials for testing. Also, I'm not completely sure that this is the extent of all denials - or if more will surface if I leave my device running and more power saving actions will have taken place. > I see no point in adding policies to tlp, tlp-rdw packages for this. You don't? To me it seems that either the tlp/tlp-rdw scripts are running in the wrong context, or the /run/tlp/lock_tlp directory has the wrong labels. If you look at the above denials, it seems that somehow ifconfig is trying to modify tlp files, so you should at least allow this in a policy. ps.: Would you rather continue this discussion here, or do you prefer to discuss this on GitHub in a new Issue?
Moving this back to selinux-policy, as I believe this needs to be solved there, but I'm not sure. Lukas, are you able to help clarify on the process of dealing with selinux policy issues? I see that a few have already been dealt with in the past with the "targeted" sub package (such as rhbz#1409977). Please let me know if there is anything that the upstream developer or I can help with getting this resolved.
I did some research and found the following. AVCs are thrown when TLP is called in systemd context: 1. System boot runs: systemctl start tlp (tlp.service) scontext = system_u:system_r:tlp_t:s0 results: systemctl_start_tlp.avc (see attachment) 2. System shutdown runs: systemctl stop tlp (tlp.service) scontext = system_u:system_r:tlp_t:s0 results: systemctl_stop_tlp.avc (see attachment) 3. System suspend runs: tlp-sleep.service scontext = system_u:system_r:tlp_t:s0 results: system_resume.avc (see attachment) 4. System resume run: tlp-sleep.service scontext = system_u:system_r:tlp_t:s0 results: system_resume.avc (see attachment) The remaining invocation modes for TLP's scripts work fine: 5. Change of power source AC <-> battery runs: /usr/sbin/tlp auto (via udevd) scontext = system_u:system_r:udev_t:s0-s0:c0.c1023 results: no AVCs 6. USB device hotplug runs: /usr/lib/udev/tlp-usb-udev (via udevd) scontext = system_u:system_r:udev_t:s0-s0:c0.c1023 results: no AVCs 7. Dock/undock laptop runs: /usr/lib/udev/tlp-rdw-udev (via udevd) scontext = system_u:system_r:udev_t:s0-s0:c0.c1023 results: no AVCs 8. Connect/disconnect LAN cable runs: /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm (via NetworkManager) scontext = system_u:system_r:initrc_t:s0 4782 ? S 0:00 /bin/sh results: no AVCs My conclusion: the targeted policy module in Fedora's selinux-policy-targeted package [1,2] is incomplete and doesn't cover scontext = system_u:system_r:tlp_t:s0 A related bug report is #1408434 [3]. [1] https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/commit/?id=42206f3502a16444082bf61d41c7c008af29bee9 [2] https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/policy-rawhide-contrib.patch#n109520 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1408434
Created attachment 1270568 [details] System start AVCs
Created attachment 1270569 [details] System shutdown AVCs
Created attachment 1270570 [details] System suspend AVCs
Created attachment 1270571 [details] System resume AVCs
Some more remarks: AVCs occur when a TLP in script with scontext = system_u:system_r:tlp_t:s0 calls 1. /usr/bin/logger to write trace output [1] to the journal 2. /usr/sbin/rfkill which reads/writes /dev/rfkill 3. /usr/share/tlp/tpacpi-bat which reads/writes /proc/acpi/call 4. /usr/sbin/modprobe to load a kernel module 5. /usr/bin/nmcli to communicate with NetworkManager dbus daemon
I forgot to mention the trivial case: 9. Manual invocation runs: /usr/sbin/tlp (from the shell) scontext = unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 results: no AVCs
selinux 3.13.1-225.16.fc25 doesn't solve this bug. What can I do to push the solution forward?
Hi Thomas, I added fixes for tlp info F25+. It will be part of new selinux-policy package build. THanks, Lukas.
Thanks for the fixes. I've re-tested with 3.13.1-280. Above AVCs are gone now but new ones have appeared for: * tcontext=system_u:object_r:sssd_public_t * tcontext=system_u:object_r:sssd_var_lib_t:s0 See attachments.
Created attachment 1324967 [details] 3.13.1-280: System start AVCs
Created attachment 1324969 [details] 3.13.1-280: System stop AVCs
Created attachment 1324970 [details] 3.13.1-280: System suspend AVCs
Created attachment 1324972 [details] 3.13.1-280: System resume AVCs
Hi Lukas, re-tested with 3.13.1-280, not solved yet. Something must have gone wrong with your latest changes --> see attached AVCs. Regards, Thomas
Correction: retest was with 3.13.1-290 of course.
Created attachment 1334986 [details] 3.13.1-290: System start AVCs
Created attachment 1334987 [details] 3.13.1-290: System stop AVCs
Created attachment 1334988 [details] 3.13.1-290: System suepnd/resume AVCs
Hi Lukas, we're not yet there, but very close now. Remaining AVCs see attachment. Tested with 3.13.1-295. Regards, Thomas
Created attachment 1338929 [details] 3.13.1-295
selinux-policy-3.13.1-260.14.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-d312739a4e
Tested once again with 3.13.1-300. Above AVCs from 3.13.1-295 persist.
Thomas, I added fixes based on the latest attachment.
Tested with with 3.13.1-302. No AVCs. Great :-)
selinux-policy-3.13.1-260.14.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.