So today, I allowed my laptop to upgrade to the latest F9 packages. Shortly afterward, VPNC could no longer run its connection script to connect to my corporate VPN connection.
I looked for an AVC denial message in my GNOME notification area (it was only later that I’d be paranoid and check that the sealert and friends were actually being allowed to run, which they were), but there was none. And none of the system logs readily showed any SELinux problem, so I decided it wasn’t time to Just Blame SELinux. A half hour of hacking at the VPNC script later, and getting confused why the commands within that script would run via sudo but didn’t seem to be running when called by VPNC, and I had myself an answer. Obviously it must be SELinux at fault, somehow, somewhere, sometime.
Calling setenforce 0 before running VPNC results in no errors and the VPN comes up just fine, whereas turning SELinux back on immediately results in a failure to run the connection script. The RPM itself reports context information that is consistent with that on the actual files, and again, there are no denial messages being reported – running sealert manually would seem to confirm this, and there are no messages in obvious log files. So it comes down to this: something is broken in F9, I can’t yet determine where it is, but a simple update has resulted in SELinux causing yet more pain that it’s ever possibly worth.
I’ve almost learned my lesson. I listened to certain people when they suggested that using SELinux was a great idea, and that doing this on F9 is super cool because it wouldn’t get in the way, and that it’s all great because we can protect ourselves from ourselves and our own evil actions. But all these people have forgotten one minor point – SELinux policy is so complex and/that we get these random failures. This is a highly undesirable user experience for a desktop. I’m about ready, once again, to hurtle SELinux out of the window as far as humanly possible. Way too overly intrusive to be actually useful.
Yes, I’m sure there’s a BZ somewhere, and I could just wait for another set of package updates that I’m sure will resynchronize policy with package, but let’s please notice that in the meantime, Joe User has long since given up and gone out to play with Little Billy and his friends. I’m trying to write these entries here to convey the undesirable user experience, and not whether I personally know enough to work around it. The average Fedora/Linux user doesn’t have 14 years of experience at dealing with this kind of thing.
Time for some (decaf) coffee.
Jon.
The average user does not know how to operate netfilter/iptables either. Does that mean you have that also disabled?
You do not have to wait for a policy upgrade but you can allow any permissions yourself as root in a suitable domain. Heck you can even load your own less intrusive security policy.
I also once had the issue that a process was denied some action but audit.log did not show any avc denials. The first thing i did was increase the debug level of that app. This showed me exactly where access was denied and hinted my that the denial may have been exempted from being audited.
I am a average fedora user ( that knows a bit about iptables and traditional linux security) and i would be glad to help you solve your issues and help you operate a selinux system. Security always comes with a trade off but selinux is not harder to understand than traditional security or netfilter/iptables.
SELinux can help. I once had an experience where people that did not have selinux enabled/enforced were not able to load their rawhide; SELinux not only prevented an intrusion that would cause the system to not be able to boot but it also reported what would have happent by what process. Due to selinux i was able to report a bug and i was able to boot my system.
Stop by #fedora-selinux if you want any help. I know this is not about you but i bet that if you had a better understanding of how to administer a selinux system that you would also be able to judge better.
Also let’s not blame the selinux framework for any policy.
One thing I have noticed is that most experiences with something are set by how one approaches them. Everytime I have approached something with a negative viewpoint, I have found every possible problem with it.. and yet my co-workers computer works perfectly well with the same setup.
Basically, selinux is not for you, and you are not for Selinux. You can put it in permissive mode or disable it, but I think that no matter how much better it would get, your past and present experience is going to find fault with it. I am not allowed to touch the mac computers at home for the same reason.
Jon makes a good point about the complexity of what a computer user is going to do. I think this is why setroubleshoot and other tools were written. There seems to be agreement from e.g. Dan Walsh that there can be a mechanism for a user to say, “Yes, I did mean to do that, allow it now and everafter.”
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
> Basically, selinux is not for you, and you are not for Selinux.
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.
selinux will “helpfully” filter things from you so you can’t see the error when one is generated. most likely that is what’s happening. you may have to look into the policy files for vpnc strip out those filters. sorry, i don’t know how to even begin to do that.
I run selinux disabled.
SELinux for me is in the same category as Evolution. When it works, it’s heartbreakingly beautiful.
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.
That is why we have people like you and others that see these errors and write great BZ reports so that bugs get fixed ASAP. I also have and still have some issues with SEL and just keep posting the bugs and they get fixed so more average users have “calm sea” while cruising through Fedora waters