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.