Daniel J Walsh wrote: ...
the problem. So we maybe want to have the report this upstream button, only show up when setroubleshoot is baffled. A lot of bugzilla's I get cut and paste the setroubleshoot window and then I respond by saying "Do what the troubleshouter told you to do!" Closed Not a Bug.
I would say that generally, the user has no idea what might have suddenly caused the visible denial. eg no recent system changes {ie config files}, updates {the tool could mention which rpm installs / updates have been performed since useful period ago} etc. So having the tool suggest they need to run a sort of "let this happen anyway" command should be considered risky, ie maybe something has got to the point where an untrained {selinux} user will be allowing bad things to happen.
That's pretty much like the exempt/fix me IMHO. If se-t-s says that I could make it not object by doing X, should I just do it, or is it potentially telling me to do something that would allow the sort of security breakthrough that selinux is trying to stop in the first place ?
It could be an improvement if the se-tools notice an selinux denial to: download new policy if available, applies updated policy, relabel, verifies disk files, before suggesting that the user start performing security altering commands.
Also, if the selinux note could capture the offending command eg was a gui click, a file copy, a script, a cron task {with params}, might it then be possible to cause a reissue of the triggering command after a policy update, so that a fix can be confirmed as actually correcting the issue.
There could be additional help put into common selinux denials caused by out-of-repo packages like vmware - where the tell tale signs could trigger a message like "the installation of a third party application like X may have modified the file context of /etc/blah in a way that disrupted the correct labelling of the file. If you know that you have recently installed X, you will need to fix the file context by ..." That would give enough information for a user to confidently apply the se-t-s command.
se-t-s could also attempt to rate the risk of performing the suggested command ?
DaveT. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
