Because the promise each makes is so wonderful, the failure to live up to that promise in any way becomes a terrible disappointment. It’s easy to lose sight of what actually does work well today.

Steven may be exactly right in his analysis. I *don’t* want to futz with certain things, like my email client, even if I’m happy to play with certain other things, like video.

And like Jon, I *don’t* want to futz with SELinux–at least not for services that are “supposed” to work out-of-the-box.

However, “never” is such a very long time. I hope Steven’s prediction that SELinux will never perform adequately out-of-the-box for certain users just because it doesn’t satisfy them now is inaccurate.

Finally, pursuant to domg472, the distinction between a service that doesn’t work, and an out-of-the-box configuration that doesn’t work (system-config-httpd anybody?) is very appropriate for developers, but not at all appropriate to foist on end-users.

I run selinux disabled.

No. *This* is a negative viewpoint. You are blaming the user for a bug in SELinux. It’s not the user’s fault. And SELinux will never get better until the developers acknowledge that.

Why can’t SELinux deliver it’s bad news via the usual orifice? An error occurs, errno is set and the app calls perror() or whatever. The message is “SELInux says you can only run virt images from /var/virt …” and it pops out on stderr or in a dialog box ir in the apps own log file — the normal places you would look to find all errors.

How are folks supposed to cope when SELinux fails silently, as in this case? It’s bad enough you have to grovel about in some completely different set of log files, just in case, you know, whatever error you happen to be having might be another SELinux oddity.

The promise of SELinux is great. No one is criticizing that. But I could make my computer secure by pulling the plug. Do you see that there are other forces at work here other than ‘be secure’? Be secure and not working half the time is not an acceptable compromise.

We have mechanisms like this in many interactions. Until you disable the notice, a new Firefox install tells you each time you join or leave an HTTPS page. That notice has been around since HTTPS was first used, and it has always “confused users.” How many people do you think check the box as part of the, “I don’t understand this, go away” school of ignoring?

The users are the main group who are going to do the complex things that need to be constrained or allowed by SELinux policy. It has always been a problem, one which Jon is encountering, that SELinux quickly moves a user into the arena of security policy maintainer. Even a simple firewall policy such as that exposed by system-config-securitylevel is daunting for many people. No matter how we expose SELinux (if we choose to!), it is going to be daunting.

So, what options are there besides continuing this way or turning it off forever? One thing is for some user interface experts to come apply their trade to the problem of users managing security policy. SELinux is one, so are firewall rules, various Firefox settings, settings in mail client, settings in IM client, ad nauseum.

I think Dan has been moving in the right direction, basically all by himself AFAICT:

* Create more types of groups that a user can be self-slotted in to; then a “full features” user can have a better SELinux interaction through a less constrained environment, while an “online desktop” user can be in a near-kiosk environment. (xguest)

* Better end-to-end tooling to allow a user to permit policy changes and report back on the reason why to SELinux developers. Perhaps come up with a way for per-user policies to be implemented, so different users on the same machine don’t have to run the same policy in all places.

Jon’s example of virt-manager not having the permissions to boot an ISO is just the kind of complexity that is beyond a team of SELinux developers dreaming up all variations. Having him file a bug report and wait even a day for a policy update is a bit ridiculous. It could be a user settable boolean, but then … it would have to be imagined first.

How about a process like this:

1. Tool hits an SELinux denial

2. setroubleshoot pops up a nice, tight GUI that clearly hides all the extra information in favor of a short descriptive sentence and a call to action.

3. Actions include allowing the action once, allowing the action always for the user, and denying the action.

4. If the action is allowed even one time, the setroubleshoot details are made ready to deliver to SELinux developers for review. The user is given a chance to put in an email address to receive back questions and feedback. NOTE: no email address to interact may mean the problem does not get addressed, sorry.

At the very least, this would give someone like Jon a way to get his stuff done with SELinux running, and not be tempted to blog to the entire world about it! ;-D