Description of problem: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that tlp should be allowed write access on the lock_tlp 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 'tlp' --raw | audit2allow -M my-tlp # semodule -X 300 -i my-tlp.pp Additional Information: Source Context system_u:system_r:tlp_t:s0-s0:c0.c1023 Target Context system_u:object_r:var_run_t:s0 Target Objects lock_tlp [ file ] Source tlp Source Path tlp Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.5-27.fc32.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.6.0-0.rc2.git0.1.fc32.x86_64 #1 SMP Mon Feb 17 21:09:39 UTC 2020 x86_64 x86_64 Alert Count 4 First Seen 2020-02-22 11:19:20 CET Last Seen 2020-02-22 11:19:21 CET Local ID c9abe1c9-d356-432e-bcc5-3b12dfb3f551 Raw Audit Messages type=AVC msg=audit(1582366761.910:543): avc: denied { write } for pid=38859 comm="tlp" name="lock_tlp" dev="tmpfs" ino=268094 scontext=system_u:system_r:tlp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_run_t:s0 tclass=file permissive=0 Hash: tlp,tlp_t,var_run_t,file,write Version-Release number of selected component: selinux-policy-3.14.5-27.fc32.noarch Additional info: component: selinux-policy reporter: libreport-2.12.0 hashmarkername: setroubleshoot kernel: 5.6.0-0.rc2.git0.1.fc32.x86_64 type: libreport Potential duplicate: bug 1510249
Hello tlp folks, the lock_tlp file created in the runtime filesystem gets incorrect label. I was not able to figure out which process creates it - can you help us with answering this question? Feel free to switch the component back to selinux-policy once it is made clear.
/run/tlp/lock_tlp is created by /usr/sbin/tlp in several different contexts: (not sure about all the scontexts) 1. System boot run by systemd: tlp.service --> /usr/sbin/tlp init start scontext = system_u:system_r:tlp_t:s0 2. System shutdown run by systemd: tlp.service --> /usr/sbin/tlp init stop scontext = system_u:system_r:tlp_t:s0 3. System suspend run by systemd: /usr/sbin/tlp suspend scontext = ? 4. System resume run by systemd: /usr/sbin/tlp suspend scontext = ? 5. Change of power source AC <-> battery run by udevd: /usr/sbin/tlp auto scontext = system_u:system_r:udev_t:s0-s0:c0.c1023 6. User Shell: /usr/sbin/tlp start But there is also /run/tlp/lock_tlp_discharge created by /usr/sbin/tlp in only one context: 7. User Shell: /usr/sbin/tlp discharge
Similar problem has been detected: Wake up from sleep hashmarkername: setroubleshoot kernel: 5.6.7-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. type: libreport
\o Hey Zdenek, I think Thomas provided the info. I can confirm #4 is what is causing the issues for me. Does this make it a tlp bug or a selinux-policy bug?
Created attachment 1683657 [details] Policy supplement for tlp's actions in /tmp/tlp and /run/tlp
Hi, i added a policy supplement a user sent me for 1.3 beta version. Can you add it to selinux's tlp.te please? Thanks.
Similar problem has been detected: This alert is received upon waking a laptop from suspend. It started after upgrading to Fedora 32 and tlp 1.3. hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. type: libreport
Similar problem has been detected: The computer was waking up from ACPI S3 "suspend" and presented me with this troubleshooting information. Computer was recently updated from F30 via F31 to F32, through the desktop software prompts. hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-32.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the Datei lock_tlp. type: libreport
Alex, Thomas, It can be addressed in selinux-policy. The /run/tlp directory is confined so we need to allow each process which can create /run/tlp the type transition, i. e. for systemd and user session (including confined users as well) the same way as it is for tlp: type_transition tlp_t var_run_t:dir tlp_var_run_t; type_transition tlp_t var_run_t:file tlp_var_run_t; I was looking how dbus can possibly deal with it, but the answer in c#2 clearly describes how it is. My understanding it that for 3) and 4), this script is used: /usr/lib/systemd/system-sleep/tlp Until now, I was not aware of the need of using /tmp/tlp - is it a new problem found, Thomas?
Hi Zdenek, you're perfectly right about /usr/lib/systemd/system-sleep/tlp, i forgot to mention that in #2. Thanks for the question about /tmp/tlp: This stems from the new config scheme of TLP 1.3 requiring to read and aggregate multiple config files now. The result is written to tmpfiles below /tmp/tlp/ (created by means of mktemp). The following scripts make use of it: * /usr/sbin/tlp – in all of the contexts of #2 * /usr/lib/udev/tlp-usb-udev – called by udevd for newly plugged USB devices * /usr/bin/tlp-stat – from a user shell * /usr/bin/bluetooth,wifi,wwan – from a user shell * /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm – called by NetworkManager for network connect/diconnect events * /usr/bin/tlp-rdw – from a user shell All of them do it by invoking the helper script /usr/share/tlp/tlp-readconfs (Perl). /usr/bin/tlp will also move the tmpfile to /run/tlp/run.conf afterwards. Btw: TLP is not involved with dbus.
Similar problem has been detected: Still having this issue after the last SELinux policy update when resuming laptop from sleep. hashmarkername: setroubleshoot kernel: 5.6.8-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-38.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. type: libreport
*** Bug 1833727 has been marked as a duplicate of this bug. ***
Similar problem has been detected: this bug persists after each and every wake-from-suspend since the upgrade to Fedora 32, and really needs to be fixed quicker hashmarkername: setroubleshoot kernel: 5.6.10-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-38.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the Datei lock_tlp. type: libreport
Similar problem has been detected: Wake up from sleep hashmarkername: setroubleshoot kernel: 5.6.11-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-38.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. type: libreport
Similar problem has been detected: This error just appeared without prior warning. hashmarkername: setroubleshoot kernel: 5.6.10-300.fc32.x86_64 package: selinux-policy-targeted-3.14.5-38.fc32.noarch reason: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. type: libreport
*** Bug 1840129 has been marked as a duplicate of this bug. ***
Thomas, I went again through the policy rules and can't figure out what's wrong, with one possible exception. We have domain transitions for both systemd and udev: init_daemon_domain(tlp_t, tlp_exec_t) tlp_domtrans(udev_t) On a clean installation, the runtime directory and files have correct types, once the unit has been started. # systemctl start tlp # ls -Za /run/tlp system_u:object_r:tlp_var_run_t:s0 . system_u:object_r:tlp_var_run_t:s0 last_pwr system_u:object_r:var_run_t:s0 .. system_u:object_r:tlp_var_run_t:s0 run.conf A new file created in /run from a user shell gets the proper context. I can't see a reason why would /run/tlp got removed and created again, by some other process than systemd or udev. According to the detailed description in c#2 and c#10 there should not be any. The only way which remains is if starting the service from a terminal is considered correct and/or common: in that case the directory surely has incorrect labels. For most of the system services it is not and we do not support it, we require starting service as systemd units. We can add a named transition (for unconfined_t and sysadm_t) if it is required though. # systemctl stop tlp # rm -rf /run/tlp # tlp init start # ls -Za /run/tlp unconfined_u:object_r:var_run_t:s0 . unconfined_u:object_r:var_run_t:s0 last_pwr system_u:object_r:var_run_t:s0 .. unconfined_u:object_r:var_run_t:s0 run.conf This issue seems a bit hard to troubleshoot.
Zdenek, > I can't see a reason why would /run/tlp got removed and created again Right, the directory is only created once: https://github.com/linrunner/TLP/blob/1.3.1/tlp-func-base.in#L377 You have to consider TLP's daemon-less design: https://linrunner.de/tlp/developers/architecture.html Nearly every TLP script needs to read the config files and therefore calls create_rundir(). The service is probably not the first invocation of a TLP component during boot, because it's started at the very end. The first invocation is most likely via udevd, invoked for every USB device or a power supply event. What about the NetworkManager context with tlp-rdw installed? > /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm – called by NetworkManager for network connect/disconnect events
(In reply to Thomas Koch from comment #18) > Zdenek, > > > I can't see a reason why would /run/tlp got removed and created again > > Right, the directory is only created once: > https://github.com/linrunner/TLP/blob/1.3.1/tlp-func-base.in#L377 > > You have to consider TLP's daemon-less design: > https://linrunner.de/tlp/developers/architecture.html > > Nearly every TLP script needs to read the config files and therefore calls > create_rundir(). > > The service is probably not the first invocation of a TLP component during > boot, because it's started at the very end. Thomas, this is an important piece of information. > The first invocation is most likely via udevd, invoked for every USB device > or a power supply event. udevd invocation is covered. > > What about the NetworkManager context with tlp-rdw installed? > > > /etc/NetworkManager/dispatcher.d/99tlp-rdw-nm – called by NetworkManager for network connect/disconnect events Need to take into account this one; Seems to have moved to /usr/lib/NetworkManager/dispatcher.d/99tlp-rdw-nm in newer fedoras.
So I fired up a F32 test system (latest updates) on my trusty X200 (not a fast hardware) with the simple tlp-rdw configuration > DEVICES_TO_DISABLE_ON_LAN_CONNECT="wifin" > DEVICES_TO_ENABLE_ON_LAN_DISCONNECT="wifi" and after boot i get: > ls -Za /run/tlp > system_u:object_r:var_run_t:s0 . system_u:object_r:tlp_var_run_t:s0 last_pwr system_u:object_r:initrc_var_run_t:s0 virbr0.itype > system_u:object_r:var_run_t:s0 .. system_u:object_r:tlp_var_run_t:s0 run.conf system_u:object_r:initrc_var_run_t:s0 wls1.itype With LAN cable connected it is: > ls -Za /run/tlp system_u:object_r:var_run_t:s0 . system_u:object_r:initrc_var_run_t:s0 enp0s25.itype system_u:object_r:tlp_var_run_t:s0 run.conf system_u:object_r:var_run_t:s0 .. system_u:object_r:tlp_var_run_t:s0 last_pwr system_u:object_r:initrc_var_run_t:s0 virbr0.itype enp0s25, wls1 and virbr0 are network interfaces, so the NM context is a possible explanation. BUT: I don't get the AVC from #1. My AVCs are > type=AVC msg=audit(1590778346.715:435): avc: denied { setgid } for pid=2206 comm="logger" capability=6 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:tlp_t:s0 tclass=capability permissive=0 (many instances) > type=USER_AVC msg=audit(1590777729.887:736): pid=894 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus permissive=0 exe=2F7573722F62696E2F646275732D62726F6B6572202864656C6574656429 sauid=81 hostname=? addr=? terminal=?' (6 instances)
Finally with tlp-rdw removed is see: > ls -Za /run/tlp > system_u:object_r:var_run_t:s0 . system_u:object_r:var_run_t:s0 .. system_u:object_r:tlp_var_run_t:s0 last_pwr system_u:object_r:tlp_var_run_t:s0 run.conf and only the "logger" AVCs shown above. I hope you can do something with it, Zdenek.
> BUT: I don't get the AVC from #1. Did you try suspending the laptop and waking from sleep? This is when I see "SELinux is preventing tlp from 'write' accesses on the file lock_tlp." every time.
Similar problem has been detected: I do not know how this happened. When I came back to the computer and moved the mouse to wake the screen, the selinux message appeared. hashmarkername: setroubleshoot kernel: 5.6.14-300.fc32.x86_64 reason: SELinux is preventing tlp from 'write' accesses on the file lock_tlp. type: libreport
I maybe can provide on more hint. For me the problem starts after a successful "suspend to RAM" and prevents my machine to successful "suspend to RAM" again. Trying this leads into a crash. If I set SELinux to permissive "setenforce Permissive" to problem does not occur and I'm able to suspend more than one time. This is a problem since "Late F31" and appeared with some update (couple of weeks before F32 release - sorry no better time idea) and is still there after I upgraded to F32. Hardware is Desktop and AMD based (Ryzen 3700X). My work laptop Intel based is not affected but has nearly same Software config. Hope this helps a little I you need logs etc. please ask Regards André
Folks, Thank you for your effort to isolate the issue. The problem is /run/tlp directory is created with the var_run_t context which is incorrect. We have rules for systemd and udev to transition the directory context to tlp_var_run_t, which should be in place whenever invoked directly or as a units dependency. So far, I was not able to track any other way this directory is created. As this tlp-func-base snippet: readonly RUNDIR=/run/tlp ... create_rundir () { # make sure $RUNDIR exists [ -d $RUNDIR ] || mkdir -p $RUNDIR 2> /dev/null 1>&2 } is executed many times, we may need to add rules for any software which reads tlp-func-base, which is the case of /usr/lib/NetworkManager/dispatcher.d/99tlp-rdw-nm. The tlp-rdw file has the common bin_t context: Thomas, when is this command executed and by whom? Need to assess if it should be assigned the tlp_exec_t context as tlp. It also seems to run create_rundir. At the moment, I am not sure if the two AVCs reported in c#20 are related: > type=AVC msg=audit(1590778346.715:435): avc: denied { setgid } for pid=2206 comm="logger" capability=6 scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:tlp_t:s0 tclass=capability permissive=0 (many instances) > type=USER_AVC msg=audit(1590777729.887:736): pid=894 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc: denied { send_msg } for scontext=system_u:system_r:tlp_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=dbus permissive=0 exe=2F7573722F62696E2F646275732D62726F6B6572202864656C6574656429 sauid=81 hostname=? addr=? terminal=?' (6 instances) Did they just start to appear at some point of troubleshooting? Can we put them aside for now to have the main problem confirmed resolved?
Zdenek, as tlp-func-base is a function library i'll have to identify all entry points i.e. routines there that use create_rundir() and the calling scripts. What makes me optimistic is that my system creates /run/tlp with the wrong context too. The logger AVCs are trigged by TLP's trace mode. I'll resort to permissive mode. Stay tuned.
ps. /usr/bin/tlp-rdw is only invoked in a user shell.
ps2. and for good measure a list of all TLP scripts directly invoked by system daemons. I'll omit everything only relavant in a user shell. systemd: - /usr/sbin/tlp - /usr/lib/systemd/system-sleep/tlp udevd: - /usr/sbin/tlp - /usr/lib/udev/tlp-usb-udev - /usr/lib/udev/tlp-rdw-udev (tlp-rdw) NM: - /usr/lib/NetworkManager/dispatcher.d/99tlp-rdw-nm (tlp-rdw)
Hopefully I managed to cover all remaining entry points for tlp invocation: https://github.com/fedora-selinux/selinux-policy-contrib/pull/256 https://github.com/fedora-selinux/selinux-policy/pull/359
Zdenek, *all* scripts listed in #28 invoke create_rundir(). My system (with tlp-rdw and selinux-policy-3.14.5-39) currently produces the following on boot: ls -Zla --full-time /run/tlp total 16 drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 120 2020-06-02 16:40:09.276969740 +0200 . drwxr-xr-x. 48 root root system_u:object_r:var_run_t:s0 1360 2020-06-02 16:41:28.450570666 +0200 .. -rw-r--r--. 1 root root system_u:object_r:tlp_var_run_t:s0 2 2020-06-02 16:39:35.903326824 +0200 last_pwr -rw-rw-r--. 1 root root system_u:object_r:tlp_var_run_t:s0 2240 2020-06-02 16:39:35.837241582 +0200 run.conf -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 8 2020-06-02 16:39:29.492171155 +0200 virbr0.itype -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 5 2020-06-02 16:39:28.324137374 +0200 wls1.itype From the traces I gather the following sequence: 1. udevd /usr/lib/udev/tlp-usb-udev -- the one that actually creates /var/run 2. NM /usr/lib/NetworkManager/dispatcher.d/99tlp-rdw-nm -- creates *.itype 3. systemd /usr/sbin/tlp -- creates last_pwr and run.conf So is the policy yet complete for /usr/lib/udev/tlp-usb-udev? What about /usr/lib/udev/tlp-rdw-udev? ---------------------------- I also need to be more specific about the user shells: /usr/sbin/tlp /usr/bin/tlp-stat /usr/bin/bluetooth /usr/bin/wifi /usr/bin/wwan /usr/bin/tlp-rdw will invoke create_rundir()ony when run in a shell with root privilege only. And any of them could actually create /run/tlp when run immediately after package install where neither the service was started nor any of the udev / NM events happened yet.
Thomas, Hopefully with both the commits all known problems are resolved, I need to create a build to see, but I can only manually test as before. Just came to my mind creating a single systemd-tmpfiles entry might help as well unless the /run/tlp directory is removed after some reasonable command (like stopping the service?).
Zdenek, would be great if you could share the build for preliminary tests. The directory is never removed. I'll keep systemd-tmpfiles in mind, but there are distributions/users without systemd out there ...
commit e50524da74295eeb81d421c8335b5aed8e713f10 (HEAD -> rawhide, origin/rawhide, origin/HEAD) Author: Zdenek Pytela <zpytela> Date: Mon Jun 1 15:48:49 2020 +0200 Support multiple ways of tlp invocation Label /usr/lib/systemd/system-sleep/tlp as tlp_exec_t. Create the tlp_filetrans_named_content() interface for managing the /run/tlp directory. Allow NetworkManager_t tlp_filetrans_named_content(). Resolves: rhbz#1806123 commit 7c30adb369163c15a7ef6e9d5d2bdda0ba58b04f (HEAD -> rawhide, origin/rawhide) Author: Zdenek Pytela <zpytela> Date: Tue Jun 2 15:17:39 2020 +0200 Allow named transition for /run/tlp from a user shell Resolves: rhbz#1806123
Yet another one: commit f17ec670d35ff510289f74c8564243a68555c5fd (HEAD -> rawhide, upstream/rawhide) Author: Zdenek Pytela <zpytela> Date: Wed Jun 3 17:15:22 2020 +0200 Allow initrc_t tlp_filetrans_named_content() NetworkManager dispatcher scripts have the NetworkManager_initrc_exec_t type which transitions to initrc_t. This update adds tlp_filetrans_named_content() for initrc_t.
FEDORA-2020-ca8855e4de has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ca8855e4de
*** Bug 1844755 has been marked as a duplicate of this bug. ***
Note complete yet - please still see bug https://bugzilla.redhat.com/show_bug.cgi?id=1844755 - there is a new failure mode with the bodhi update package, and it's still complaining after resume-from-suspend-to-RAM (ACPI S3 level suspend)
Thomas and others, Instead of a scratchbuild, I built packages for all Fedoras as there was a reason to create them, so I included also tlp fixes.
Zdenek, booted with selinux-policy-3.14.5-40.fc32, /run/tlp is still created with the incorrect var_run_t context: $ ls -Zla --full-time /run/tlp total 16 drwxr-xr-x. 2 root root system_u:object_r:var_run_t:s0 120 2020-06-07 11:37:21.737356386 +0200 . drwxr-xr-x. 48 root root system_u:object_r:var_run_t:s0 1360 2020-06-07 11:39:11.788845030 +0200 .. -rw-r--r--. 1 root root system_u:object_r:tlp_var_run_t:s0 2 2020-06-07 11:37:19.089296689 +0200 last_pwr -rw-rw-r--. 1 root root system_u:object_r:tlp_var_run_t:s0 2240 2020-06-07 11:37:19.030295523 +0200 run.conf -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 8 2020-06-07 11:37:14.936009259 +0200 virbr0.itype -rw-r--r--. 1 root root system_u:object_r:initrc_var_run_t:s0 5 2020-06-07 11:37:13.789976810 +0200 wls1.itype
FEDORA-2020-ca8855e4de has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ca8855e4de` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ca8855e4de See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Thomas, With the new policy in place, I see all the transition rules for all the already described ways of creating /run/tlp as expected. What we can do next is to set audit rules to monitor mkdir syscalls. I would like to ask anybody who can help with finding the process to do the following steps: 1) Open /etc/audit/rules.d/audit.rules file in an editor; consider backing it up first to undo changes later. 2) Remove the following line if it exists: -a task,never 3) Add the following lines at the end of the file: -a always,exit -F arch=b64 -S mkdir,mkdirat -F key=mkdirsyscall -w /etc/shadow -p w -k shadowwrite 4) Restart the audit daemon: # service auditd restart 5) Do the steps that lead to creating /run/tlp (possibly reboot?) 6) Collect AVC denials and relevant audit events, with some modifiers to limit the output, or attach raw audit logs: # ausearch -i -ts boot # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today # ausearch -i -k mkdirsyscall Note this sequence will audit all mkdir() syscalls and can flood audit.log.
Zdenek, I guess something may be wrong your audit.rules because there's literally nothing about tlp in the mksysdircall audit log and only "logger" ACS in the full log (both since boot). See attachments.
Created attachment 1696361 [details] audit.rules
Created attachment 1696362 [details] ausearch -i -k mkdirsyscall -ts boot
Created attachment 1696363 [details] ausearch -i -ts boot
Thomas, On my system it worked and running tlp-stat had as a result 2 calls mkdir -p /run/tlp audited. Probably 32bit syscall is necessary to audit as well: -a always,exit -F arch=b64 -S mkdir,mkdirat -F key=mkdirsyscall
selinux-policy-3.14.5-40.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report.