Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux

David Timms dtimms at iinet.net.au
Fri Jul 18 14:03:48 UTC 2008


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.




More information about the fedora-devel-list mailing list