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

Arthur Pemberton pemboa at
Fri Jul 18 15:28:30 UTC 2008

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?

Fedora 7 : sipping some of that moonshine
( )

More information about the fedora-devel-list mailing list