Description of problem:

I used `semanage fcontext` + `restorecon`, and then (still) suffered an AVC denial executing the file.

This is not my complaint, I clearly don't understand selinux enough to implement any workaround more subtle than disabling selinux,

The problem detected is that setroubleshootd suggests the most likely fix is to run `restorecon -v` on the file.  That was part of how I _caused_ the problem, and of course re-running it does nothing to help.

The plugin actually knows what label "should" be re-applied.  So it could easily see that something more is wrong.  (Just run the equivalent of `restorecon -nv`).


Version-Release number of selected component (if applicable):
setroubleshoot-3.3.11-1.fc25.x86_64


How reproducible:

Install Fedora 25, this might rely on BZ#1416540 still being not fixed, I don't know SELINUX.

sudo semanage fcontext -a -t unconfined_exec_t /usr/lib/systemd/systemd-machined
sudo restorecon /usr/lib/systemd/systemd-machined
sudo systemctl restart systemd-machined


Actual results:


SELinux is preventing (machined) from execute access on the file /usr/lib/systemd/systemd-machined.

*****  Plugin restorecon (99.5 confidence) suggests   ************************

If you want to fix the label. 
/usr/lib/systemd/systemd-machined default label should be systemd_machined_exec_t.
Then you can run restorecon.
Do
# /sbin/restorecon -v /usr/lib/systemd/systemd-machined

*****  Plugin catchall (1.49 confidence) suggests   **************************

If you believe that (machined) should be allowed execute access on the systemd-machined 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 '(machined)' --raw | audit2allow -M my-machined
# semodule -X 300 -i my-machined.pp


Expected results:

setroubleshootd should be able to avoid making this incorrect command suggestion at 99.5 confidence, because it is very easy for it to disprove.

Options:

1. suggest the correct commands

# semanage fcontext -a -t systemd_machined_exec_t /usr/lib/systemd/systemd-machined
# restorecon -v /usr/lib/systemd/systemd-machined


2. recognize that user has started shooting themselves in the foot.  Report the same information - because knowing the inconsistency / that this is a local customization could be very useful!

But instead of saying "If you want to fix the label", say "the label is broken", and something to indicate that you have put yourself beyond the help of restorecon.

I guess we don't know how many files the user has re-labelled (and again, a simple `restorecon -R /` cannot fix the files).


3. trust all local customizations, if restorecon would not do anything, then have the restorecon plugin not report anything at all in setroubleshootd.


I'm not really recommending option 2 or 3, just noting the possibilities.