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

Daniel J Walsh dwalsh at
Fri Jul 18 17:19:01 UTC 2008

Hash: SHA1

Arthur Pemberton wrote:
> On Fri, Jul 18, 2008 at 9:03 AM, David Timms <dtimms at> 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.
> Would this really something that could be done without getting
> permission from a user?
No but it would be cool if it could say, this bug is already fixes in
the lates selinux-policy available in updates.  Please
yum -y update selinux-policy-targeted

Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the fedora-devel-list mailing list