Add a menu choice to the SElinux avc denial popup that tells SElinux: "Let it do that".
Chuck Forsberg WA7KGX N2469R wrote:
Add a menu choice to the SElinux avc denial popup that tells SElinux: "Let it do that".
It's called audit2allow man audit2allow (in a terminal)
Also join Fedora selinux-list http://www.redhat.com/mailman/listinfo/fedora-selinux-list
where before you allow something with audi2allow. Run it by the list in case you create the Titanic.
But if you want a gui for it: http://fedoraproject.org/wiki/FAQ#Where_can_I_request_a_newer_version_of_a_p...
Maybe work for a feature as well?
Frank
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
Kevin Kofler wrote:
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.
For many people, the reason to choose RHEL/Fedora is usable SELinux. It's one of the things which is nice to mention in any discussion for relative releases.
On Sun, 2009-05-31 at 16:32 +0200, Kevin Kofler wrote:
A possible way to fix this would be to:
...when SELinux blocks a legitimate operation on your system, file a bug on it, with the appropriate information included.
https://fedoraproject.org/wiki/BugsAndFeatureRequests#SELinux
Adam Williamson awilliam@redhat.com writes:
...when SELinux blocks a legitimate operation on your system, file a bug on it, with the appropriate information included.
This brings me to a question. What do other folks do when running rdist(1) (or similar) on a system that has selinux enabled? I just succeeded in locking myself out of a remote system when it updated */.ssh/authorized_keys and the context was updated in a way that was distasteful to selinux.
Looking at the rdist man page I see no indication that rdist understands contexts and tries to preserve them. Is this true? Bug? RFE?
-wolfgang
On Tue, 2009-06-02 at 08:05 -0700, Wolfgang S. Rupprecht wrote:
Adam Williamson awilliam@redhat.com writes:
...when SELinux blocks a legitimate operation on your system, file a bug on it, with the appropriate information included.
This brings me to a question. What do other folks do when running rdist(1) (or similar) on a system that has selinux enabled? I just succeeded in locking myself out of a remote system when it updated */.ssh/authorized_keys and the context was updated in a way that was distasteful to selinux.
Looking at the rdist man page I see no indication that rdist understands contexts and tries to preserve them. Is this true? Bug? RFE?
rsync supports preserving xattrs if you run it with the -X option. I'm not aware of similar support for rdist. Any particular reason for using rdist rather than rsync?
Stephen Smalley sds@tycho.nsa.gov writes:
rsync supports preserving xattrs if you run it with the -X option. I'm not aware of similar support for rdist. Any particular reason for using rdist rather than rsync?
Thanks. I didn't realize rsync did the appropriate magic. I'll have a go at using it. Mostly the choice of rdist was inertia.
-wolfgang
On Sun, May 31, 2009 at 12:21:07AM -0700, Chuck Forsberg WA7KGX N2469R wrote:
Add a menu choice to the SElinux avc denial popup that tells SElinux: "Let it do that".
SELinux needs a lot of things but an allow button is not one of them. A better idea would be to use the recently created sandbox feature instead, offering to run the application in a generic sandbox, this way it may run without incident but you can be reasonably sure it isn't grossly violating policy.
Of course the sandbox doesn't support X apps yet so it may or may not work but its better than just allowing according to setroubleshoot. Really RPM (package kit or whatever) should sandbox all applications upon installation that do not have policy in place or at least offer the option but undoubtedly people would complain about that feature.
max wrote:
SELinux needs a lot of things but an allow button is not one of them. A better idea would be to use the recently created sandbox feature instead, offering to run the application in a generic sandbox, this way it may run without incident but you can be reasonably sure it isn't grossly violating policy.
Of course the sandbox doesn't support X apps yet so it may or may not work but its better than just allowing according to setroubleshoot. Really RPM (package kit or whatever) should sandbox all applications upon installation that do not have policy in place or at least offer the option but undoubtedly people would complain about that feature.
SELinux is already too restrictive, making it even more restrictive isn't going to fix that problem.
That said, I don't see the usefulness of a framework exclusively designed to forbid things at all. It's always going to be in your way and it's never going to add an actual feature to your system.
Kevin Kofler
On Mon, Jun 1, 2009 at 4:25 PM, Kevin Kofler kevin.kofler@chello.at wrote:
max wrote:
SELinux needs a lot of things but an allow button is not one of them. A better idea would be to use the recently created sandbox feature instead, offering to run the application in a generic sandbox, this way it may run without incident but you can be reasonably sure it isn't grossly violating policy.
Of course the sandbox doesn't support X apps yet so it may or may not work but its better than just allowing according to setroubleshoot. Really RPM (package kit or whatever) should sandbox all applications upon installation that do not have policy in place or at least offer the option but undoubtedly people would complain about that feature.
SELinux is already too restrictive
No, its not ... it does not get in my way even thought I have stuff like confined nsplugin enabled (which are off by default).
You have to provide specific cases so that they can be fixed.
On 06/01/2009 08:28 PM, Muayyad AlSadi wrote:
SELinux needs a lot of things but an allow button is not one of them.
can't we have "Allow next time" button ?
We have to be very careful with this. Users will blindly practise clicking allow next instead of understanding the details. The next RFE would be filed
[ * ] Just allow automatically
Rahul
On Mon, 01 Jun 2009 20:29:57 +0530 Rahul Sundaram wrote:
On 06/01/2009 08:28 PM, Muayyad AlSadi wrote:
SELinux needs a lot of things but an allow button is not one of them.
can't we have "Allow next time" button ?
We have to be very careful with this. Users will blindly practise clicking allow next instead of understanding the details. The next RFE would be filed
I thought all the setroubleshoot nonsense was primarily designed to simplify saying "just go ahead and allow this"?
[ * ] Just allow automatically
Nah, I don't need that - turning off selinux works even better (and I don't have to waste my time turning it off one little bit at a time :-).
On 06/01/2009 08:48 PM, Tom Horsley wrote:
I thought all the setroubleshoot nonsense was primarily designed to simplify saying "just go ahead and allow this"?
In some cases but definitely not blindly.
[ * ] Just allow automatically
Nah, I don't need that - turning off selinux works even better (and I don't have to waste my time turning it off one little bit at a time :-).
Sure. You can turn off any security measure completely. It is just a trade off. No different than chmod -R 777 *
Rahul
On 06/01/2009 10:59 AM, Rahul Sundaram wrote:
We have to be very careful with this. Users will blindly practise clicking allow next instead of understanding the details.
You're right, but large percentages of users won't understand the details anyway, much less get setroubleshoot. Windows Vista gets mocked along similar lines.
If the best thing to do is to report a bug in bugzilla, maybe that's what the button should do. Anaconda's auto-reporter is a pretty swell idea.
A suitable filter in the way would probably be needed to keep the load down on bugzilla.
-Bill
On 06/02/2009 03:37 AM, Bill McGonigle wrote:
If the best thing to do is to report a bug in bugzilla, maybe that's what the button should do. Anaconda's auto-reporter is a pretty swell idea.
A suitable filter in the way would probably be needed to keep the load down on bugzilla.
Right. This seems a sensible thing to do. I am not fond of too many security alerts. It desensitizes users to ignore it as a mere nuisance. Fortunately I rarely get SELinux alerts on my systems with recent releases. So this problems seems to be more under control now. I suggested earlier a smolt type opt in method to collect the AVC messages and process them server side to proactively figure out and resolve bugs. That was deemed not feasible but simple automatic bug reporting similar to Anaconda seems a nice feature. Would anyone file a RFE on this?
Rahul
On 06/01/2009 06:26 PM, Rahul Sundaram wrote:
Would anyone file a RFE on this?
I submitted bug 503622 with some rough ideas:
https://bugzilla.redhat.com/show_bug.cgi?id=503622
People who know what they're talking about, please add/correct. ;)
-Bill
Bill McGonigle, Mon, 01 Jun 2009 19:23:55 -0400:
Would anyone file a RFE on this?
I submitted bug 503622 with some rough ideas:
https://bugzilla.redhat.com/show_bug.cgi?id=503622
People who know what they're talking about, please add/correct. ;)
Sorry for coming late to this thread, but it seems to me that by hard work, dilligence and argumentation you came up with something which thought about before ;-)
See https://fedoraproject.org/wiki/Design/ SETroubleshootUsabilityImprovements
Any volunteers to transfer these mockups into Python code?
Matěj
On 06/01/2009 06:07 PM, Bill McGonigle wrote:
On 06/01/2009 10:59 AM, Rahul Sundaram wrote:
We have to be very careful with this. Users will blindly practise clicking allow next instead of understanding the details.
You're right, but large percentages of users won't understand the details anyway, much less get setroubleshoot. Windows Vista gets mocked along similar lines.
If the best thing to do is to report a bug in bugzilla, maybe that's what the button should do. Anaconda's auto-reporter is a pretty swell idea.
A suitable filter in the way would probably be needed to keep the load down on bugzilla.
-Bill
We are planning on this enhancement.
-
Adam Williamson -
Bill Davidsen -
Bill McGonigle -
Chuck Forsberg WA7KGX -
Daniel J Walsh -
drago01 -
Frank Murphy -
Kevin Kofler -
Matej Cepl -
max -
Muayyad AlSadi -
Rahul Sundaram -
Stephen Smalley -
Tom Horsley -
Wolfgang S. Rupprecht