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

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Timms wrote:
> 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.
> 

Well I would argue that setroubleshoot does a lot of this, although it
has very limited information.  Giving the tool the ability to check if a
newer version of selinux-policy would fix the issue would be a huge step
forward.  I think understanding that vmware hosed up the /etc/services
file labeling, is a tougher problem.  Maintaining a database of
offending third party apps would be tough to maintain, and when vmware
fixes the problem we would need to make sure setroubleshooter no longer
blamed them. :^)

One of the goals of the new doc writer will be to improve the text in
the setroubleshooter, to be more humanly readable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiAptkACgkQrlYvE4MpobN7rgCg6EOPEQurXLpOv2xUmTXfi6/t
HIQAoJY/CV5dlKzNsH5mg+uXqiDWsFqw
=7epY
-----END PGP SIGNATURE-----