Bug 1689186 - SELinux is preventing tlp from 'write' accesses on the Datei lock_tlp.
Summary: SELinux is preventing tlp from 'write' accesses on the Datei lock_tlp.
Keywords:
Status: CLOSED DUPLICATE of bug 1705246
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 30
Hardware: x86_64
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Lukas Vrabec
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:0fe6c4e97436995837796a159e9...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-15 11:18 UTC by Jonathan Haas
Modified: 2019-05-07 13:20 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-07 13:20:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jonathan Haas 2019-03-15 11:18:37 UTC
Description of problem:
Waking up from standby
SELinux is preventing tlp from 'write' accesses on the Datei lock_tlp.

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

Wenn Sie denken, dass es tlp standardmäßig erlaubt sein sollte, write Zugriff auf lock_tlp file zu erhalten.
Then sie sollten dies als Fehler melden.
Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen.
Do
zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen:
# 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
Target Context                system_u:object_r:var_run_t:s0
Target Objects                lock_tlp [ file ]
Source                        tlp
Source Path                   tlp
Port                          <Unbekannt>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.14.3-23.fc30.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.0.0-300.fc30.x86_64 #1 SMP Mon
                              Mar 4 22:46:48 UTC 2019 x86_64 x86_64
Alert Count                   4
First Seen                    2019-03-15 11:59:12 CET
Last Seen                     2019-03-15 12:16:31 CET
Local ID                      fca7c2e8-942f-4176-9953-4a50f6ff2970

Raw Audit Messages
type=AVC msg=audit(1552648591.621:311): avc:  denied  { write } for  pid=5218 comm="tlp" name="lock_tlp" dev="tmpfs" ino=26266 scontext=system_u:system_r:tlp_t:s0 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.3-23.fc30.noarch

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

Potential duplicate: bug 1562382

Comment 1 Lukas Vrabec 2019-03-20 20:48:07 UTC
Hi, 

How did you start tlp? Using systemctl? 

Thanks,
Lukas.

Comment 2 Jonathan Haas 2019-03-20 20:50:39 UTC
I guess? As far as I can see, it runs automatically every boot:

[jh@xps ~]$ sudo systemctl status tlp
● tlp.service - TLP system startup/shutdown
   Loaded: loaded (/usr/lib/systemd/system/tlp.service; enabled; vendor preset: enabled)
   Active: active (exited) since Wed 2019-03-20 21:12:03 CET; 37min ago
     Docs: http://linrunner.de/tlp
  Process: 2043 ExecStart=/usr/sbin/tlp init start (code=exited, status=0/SUCCESS)
 Main PID: 2043 (code=exited, status=0/SUCCESS)

Mär 20 21:12:02 xps systemd[1]: Starting TLP system startup/shutdown...
Mär 20 21:12:03 xps tlp[2043]: Applying power save settings...done.
Mär 20 21:12:03 xps tlp[2043]: Setting battery charge thresholds...done.
Mär 20 21:12:03 xps systemd[1]: Started TLP system startup/shutdown.

Comment 3 Lukas Vrabec 2019-03-20 21:04:21 UTC
Could you remove file "lock_tlp" and try to reproduce the scenario? 

Thanks,
Lukas.

Comment 4 Jonathan Haas 2019-03-20 21:16:18 UTC
I assume you mean /run/tlp/lock_tlp, it's in the run directory, so it should be recreated every boot? In that case deleting it probably doesn't fix the problem as it's regularly deleted anyway.

[jh@xps ~]$ LANG=C stat /run/tlp/lock_tlp 
  File: /run/tlp/lock_tlp
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 17h/23d	Inode: 46615       Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: system_u:object_r:tlp_var_run_t:s0
Access: 2019-03-20 21:12:02.638706927 +0100
Modify: 2019-03-20 22:12:12.212003982 +0100
Change: 2019-03-20 22:12:12.212003982 +0100
 Birth: -

The SE-Linux denial isn't really reproducible, it only happens sometimes after opening the laptop lid. If you have any idea how to reproduce, please comment.

Comment 5 Michael 2019-05-01 19:42:58 UTC
Description of problem:
Happened after reboot


Additional info:
reporter:       libreport-2.10.0
hashmarkername: setroubleshoot
kernel:         5.0.9-301.fc30.x86_64
type:           libreport

Comment 6 user93835 2019-05-03 07:13:55 UTC
Description of problem:
Just today installed Fedora 30 Workstation Edition, selecting multiple installation additions like Python Classroom, Security Tools, Cloud Infra tools and a good few more (I probably have the names wrong, but close to what I typed). 
Automatic partitioning with full disk encryption. Ran dnf check-update and dnf update to bring everything up to date after install.

Using Huawei Matebook X Pro 2018:
Intel Core i7-8550U
16GB LPDDR3
512GB LiteON NVMe SSD
NVIDIA GeForce MX150 (using default nouveau driver)

Steps to reproduce:
1. Install tlp:
sudo dnf install tlp
2. Start tlp:
sudo tlp start
3. Suspend computer by long-clicking on power button in GNOME power menu then clicking the II suspend button
4. Wake computer by providing keyboard input
5. Log in and resume session

Got SELinux Alert

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

Additional info:
reporter:       libreport-2.10.0
hashmarkername: setroubleshoot
kernel:         5.0.10-300.fc30.x86_64
type:           libreport

Comment 7 Zdenek Pytela 2019-05-03 09:02:29 UTC
Hi,

Could you please run the following command, provided the system has not been rebooted in the meantime and any attempt to fix the problem has not been made?

ls -lZa /run/tlp

Comment 8 user93835 2019-05-03 19:36:48 UTC
Unfortunately I have rebooted and made a change in attempt to fix the issue. SELinux Alert Browser has recommended possible solutions and I've tried one of them, without success. I did:

[user@host ~]$ sudo ausearch -c 'tlp' --raw | audit2allow -M my-tlp
[sudo] password for user:
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i my-tlp.pp

[user@host ~]$ sudo semodule -i my-tlp.pp

The last command provided no output, but suspending and un-suspending still reproduces the issue.

Would it still be helpful to run the command you provided?

Comment 9 user93835 2019-05-03 19:39:43 UTC
I figure it can't hurt. Here's output:

[user@host ~]$ ls -lZa /run/tlp
total 8
drwxr-xr-x.  2 root root system_u:object_r:var_run_t:s0      100 May  3 12:36 .
drwxr-xr-x. 61 root root system_u:object_r:var_run_t:s0     1600 May  3 12:30 ..
-rw-r--r--.  1 root root system_u:object_r:var_run_t:s0        2 May  3 12:36 last_pwr
-rw-r--r--.  1 root root system_u:object_r:tlp_var_run_t:s0   21 May  3 12:30 rfkill_saved
-rw-r--r--.  1 root root unconfined_u:object_r:var_run_t:s0    0 May  2 23:56 usb_done

Comment 10 user93835 2019-05-04 00:05:33 UTC
I've since rebooted again (after making the selinux change suggested by the SELinux Alert Browser) and ran tlp by running sudo tlp start. I've not gotten an error from SELinux regarding tlp since. I don't actually know what the command I ran did though, and I've gotten other SELinux errors as well but I'm not sure if those are related.

Comment 11 Michael 2019-05-04 21:48:20 UTC
I just rebooted my system and got that:

ls -lZa /run/tlp
total 16
drwxr-xr-x.  2 root root system_u:object_r:var_run_t:s0         120 May  4 23:47 .
drwxr-xr-x. 53 root root system_u:object_r:var_run_t:s0        1540 May  4 23:42 ..
-rw-r--r--.  1 root root system_u:object_r:var_run_t:s0           2 May  4 23:47 last_pwr
-rw-r--r--.  1 root root system_u:object_r:initrc_var_run_t:s0    8 May  4 23:42 tun0.itype
-rw-r--r--.  1 root root system_u:object_r:initrc_var_run_t:s0    8 May  4 23:42 virbr0.itype
-rw-r--r--.  1 root root system_u:object_r:initrc_var_run_t:s0    5 May  4 23:42 wlo1.itype

Comment 12 Zdenek Pytela 2019-05-07 13:20:35 UTC

*** This bug has been marked as a duplicate of bug 1705246 ***


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