Frank Murphy wrote:
> It's called audit2allow
> man audit2allow (in a terminal)
The problem is that audit2allow only works for next time. You can't get that
one attempt to get through. And the way SELinux is designed, what the
original poster (OP) wants is just not possible. SELinux denies the access
immediately, then setroubleshoot gets asynchronously notified and shows the
warning. At that point, it's too late to allow the action. To work as the
OP wants, it would have to block the application until the answer from the
user comes (which is how those Window$ implementations which do offer that
option (e.g. UAC, most software firewalls and antivirus software etc.)
work). That can work in a pure GUI environment, but it won't work if
SELinux is blocking some system service used by the entire GUI (e.g. X11)
and it's definitely the wrong thing to do on a server.
In short, SELinux is not really designed for desktop usage. It's designed to
work more generally, but the desktop suffers as a result.
A possible way to fix this would be to:
* add a blocking mode to SELinux, which applications can explicitly enable
and which issues prompts through an authentication agent (the PolicyKit
authentication agent can be reused) if an action would be denied and
* have the constructors for GUI apps (gtk_init and the QApplication
constructor) default to setting the blocking mode (but of course the
authentication agent itself needs to have it disabled or we can end up in
infinite loops on misconfigured systems),
but I have no idea how easy that would be to implement (securely) nor
whether the SELinux folks would like the idea.
Personally, I just disable SELinux entirely.
Kevin Kofler
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
