Proposal: Improving SELinux <--> user interaction on Fedora - Kerneloops for SELinux
email.ahmedkamal at googlemail.com
Thu Jul 17 20:24:45 UTC 2008
another idea, is when a denial occurs, and we get this nice balloon,
it would contain 2 buttons
- AutoFix: automatically attempts changing the offending file's
context, as per the recommended action
- Exempt: changes the policy such that the offended application runs
in an unrestricted selinux domain.
IMHO, the policies will never be perfect. Mortals can't really "fix"
the policy coz it's too complex. The Exempt is what the end users
need, or they turn off the whole thing
On Thu, Jul 17, 2008 at 10:55 PM, Robin Norwood <rnorwood at redhat.com> wrote:
> On Thu, 17 Jul 2008 14:19:07 -0500
> "Arthur Pemberton" <pemboa at gmail.com> wrote:
>> On Thu, Jul 17, 2008 at 2:17 PM, Daniel J Walsh <dwalsh at redhat.com>
>> > John Dennis designed setroubleshoot to be able to send its messages
>> > to an upstream collector, it seems to me that adding a button to
>> > report the message upstream would be easy. The problem is where is
>> > the upstream infrastructure to handle all the messages.
>> > dwalsh at redhat.com. Is probably not a good place.
>> I would think not. Does the infrastructure team have any web service
>> or sorts that can accept these log messages?
> Probably not, but it sounds like a fairly easy turbogears project. The
> data is in XML? Is the format defined anywhere? The app would need to
> process the XML to check for duplicates, and display the results. If
> the format is well-defined and we can say "If fields x, y, and z are
> the same, then this is a duplicate report", then it should be nearly
> Robin Norwood
> Red Hat, Inc.
> "The Sage does nothing, yet nothing remains undone."
> -Lao Tzu, Te Tao Ching
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
More information about the devel