So, because people were arguing in the comments of my last postabout things along the lines of “it’s easy to fix the bug” and that was not the problem I’m even interested in, let me do a new post outlining the problem I’m interested in.
Here’s the case: I have a security system that is supposed to protect me. Now I want to run a program. Not just any program, but something that I consider kind of important. And now the security system says “I’m afraid I can’t do that.” The program says “Please run $CRYPTIC to allow this.” What do I do?
Essentially there’s 3 things I can do:
- Trust the security system
- Trust the violator
- Trust myself
Now let’s dissect the choices. Choice (1) is what I want to do and how I use my computer. But that only works if the system doesn’t break things on purpose.
Choice (2) is a no-brainer. The violating program is the potential attacker that must be stopped. I don’t want to trust it.
Choice (3) is complicated, because it requires that I educate myself and am aware of what all the programs are doing on my computer right this moment. This is the approach that everybody seems to advocate I should do. There is nuanced ways in which people suggest I’d do it, but in the end everybody wants to make me decide.
I’d like to add some more examples where we have to figure out how to do things, so we’re not talking just about SELinux vs applications:
- My browser vs SSL certificates
- My browser vs malware sites
- My email program vs binary attachments
- My distribution vs random binaries on the Internet
- My package manager vs –nogpgcheck
- Fences vs where I want to go
- “Do not every give your SSN to anyone” vs the real world
In all those cases, we all put varying levels of trust in the security system. Of course, those trust relationships can change over time. But generally, nobody takes a security system seriously that requires exceptions to make work normally. And if I can’t take my security system seriously, I might as well disable it, because it’ll save me from babysitting it all the time. And unless SELinux takes an effort to be taken seriously by me, I will continue to do just that.
30 comments ↓
I hate to say it but if you replace some of the technologies in your rants you would have some of the same arguments people make about GNOME’s decisions. I trust the security team to make hard decisions and to adjust over time when they don’t get it 100% right. I trust the same of the Desktop team. If there is an issue it is lack of communication of which yelling at each other and call each other stupid doesn’t forward any goals.
That fact has not escaped me. In fact, I think that GNOME has rightfully lost a lot of trust people put into it with its often nonsensical decisions. Interestingly, both Dan’s blog and us use the same argument of “power users aren’t important, my mom is”. In that sense it’s nice that SELinux bites us in the rear.
But unlike GNOME, where you have nowhere to go but OS X because all the other solutions are even worse, SELinux has a very competitive opponent: Turning it off.
One thing to keep in mind – there is a distinction between SELinux-the-technology and the selinux-policy-targeted package as shipped in Fedora and RHEL.
The distinction is somewhat academic because there isn’t another policy package in Fedora, but still – I’d title your blog “Why the Fedora SELinux policy is not awesome”.
Doesn’t/shouldn’t setroubleshoot allow you choice (1)?
The “My browser vs SSL certificates” is the perfect example for this kind of problem. There will always be a website with an outdated certificate or self signed certificate. At this point, the “security system” as you call it will not be able to make a clear choice and the user must decide what to do. You can’t build something so ubiquitous that it will be able to decide/work for everbody. You just need something that works for most people, and allow/teach others how to disable/work around it.
For the SELinux example, I think there is an “helper text” available if you run the “SELinux troubleshooter”. You can’t you just ask a system to be secure whithout learning a bit about it.
I agree with Walters, although there is another policy configuration called selinux-policy-minimum i believe (and of course there is seinux-policy-mls).
Another issue with policy configuration in Fedora is that it tries to be “one-size-fits-all” which is not how security works i believe.
I also do not agree with some of the security decisions in Fedoras’ SELinux policy. For example i do not like it how unconfined is more and more confined.
I also do not like the current approach for confined user space.
Also I do not like that there seems to be more emphasis on policy configuration than the MAC architecture and user space.
Seems sometimes that policy configuration gives the architecture a less than optimal reputation and i think that is not fair.
I rather see more focus on making it easier to allow one to implement ones own tailored policy configuration. Seems more efficient as each environment has its own properties in my view.
That seems to be very hard to achieve unfortunately.
There is also very much i do love about Fedoras’ implementation of the SELinux MAC architecture, user space and policy configuration (and also Gnome).
Maybe the Fedora distro should look into having SELinux disabled by default. It seems that every power user/developer I know ends up disabling it anyway.
To make this crystal-clear:
The moment I need to touch setroubleshoot – or any other tool – it’s no longer choice (1), it’s choice (3). Because at that moment I know better than the security system.
What I find particularly annoying is that Fedora has SELinux issues with packages from the official fedora repository. IMHO they should work out of the box, without any SELinux message. It is clear that if they install package X is because they want to run it. I think that in general they don’t want to spend any time typing SELinux commands that they don’t understand.
The next step is how to deal with packages from third parties. In my opinion, let users to deal with SELinux commands is not the ideal solution neither.
Maybe SELinux is a good way to implement security, but I think in general is the system which has to deal with SELinux configuration, not the users (unless the user wants to).
I’m surprised by the vehemence in the last couple of posts. strace and gdb are not end user software. If you are relying on my dad to use strace (or file bug reports) you are doomed.
I understand your point that FOSS often requires “power users” capable of using gdb or strace, but these users are also capable of setting an SELinux bool if requested to.
Given that ptrace allows a variety of interesting /potential/ security exposures, disabling it for users who won’t need it and won’t understand the option seems logical.
@Benjamin
You are basically saying that just because it is not ideal in 100% of the cases we should just give up. Or IOW to make it more comfortable for 1% of the users (random number for “small fraction”) we should make the system less secure by default for the other 99%. How does that make sense?
@Oliver
1) There is no such thing as a “power user”
2) I know a lot of developers that have selinux on (including myself)
3) You are implying that Fedora is only used by developers without having any numbers to back that up
4) “The people I know” is not a valid argument as it is statistically irrelevant
@Jon Levell: There’s so many easy ways around this, I don’t even care to list any of them. I’m sure you can come up with at least 5 of them in a minute.
The problem is that SELinux explicitly on purpose with boasting in blogs decided to break gdb for every single person on the planet, and in particular those that actually use it.
Any idea why they did that?
@drago01: I’m saying you should not explicitly on purpose with boasting in blogs decide to break the software I use. How you do that I don’t care. Stop pissing me off and I might look at your security system again.
If software developers feel forced to turn off SELinux, it has failed, because the defaults aren’t right.
If Fedora wants the default to be that SELinux is on, it needs to have a default policy that works for users. This policy should not assume that every software developer will have root on every machine he/she uses; this is not the case in the working world and such an assumption makes Fedora unusable on servers.
Pretty nice and accurate analysis (as usual), I guess the solution, desktop-wise at least, is pretty straight forward, work together with security people to address the issues.
@Benjamin:
1) It is not “my” security system ;)
2) The intend was not “break software foo” but “prevent attack bar from working in a default setup”
@drago01: What part of if you get a “permission denied” or “Operation not supported” error with ptrace, strace or gdb, it is SELinux causing the problem is not “break software foo” but “prevent attack bar”?
@Benjamin
I said “intend” … you sound as if the selinux people went out “oh lets break gdb and strace”.
@drago01: Yes, that’s what I’m saying. From my blog post up to my last 3 comments. They went out and broke gdb and strace on purpose and knowingly.
Thank you very much for clearly spelling out the reasons why I don’t use SELinux. I fully understand the standard users/permissions model, so I can always take option (3) for it when option (1) fails. People claim that you don’t have to understand SELinux to use a system running it; that eliminates option (3), and since option (2) makes no sense, that just leaves option (1): rely on the distribution to get all the SELinux policies right, and when they don’t, report a bug and give up until it gets fixed.
fun fact: Dan patched gdb to print out the warning and the command line to disable ptrace after it was pointed out in the comments of his blog. because, I assume, everyone should read and remember the release notes on the Fedora wiki, and always check them out whenever something invariably breaks between Fedora releases.
so I think this change wasn’t really well thought out with respect of the people actually using common developer tools.
I totally agree with Olivier Crête, that SELinux crap needs to just go away.
The purpose of a distro is to provide sane safe defaults. For 90+% of the users who will never touch gdb or strace allowing a process to ptrace any other process on the system is unsafe. If you want to do this then its a simple one line fix to turn on the ability to ptrace other processes. If this wasn’t an important feature you wouldn’t have other mechanisms such as yama which do the same thing. If you want to allow attaching gdb to arbitrary processes then just turn the boolean on and keep going with your daily debugging. I can tell you though that as a kernel and userspace developer if the least of my worries is flipping a switch so I can use GDB then my day is going well.
Interestingly Microsoft introduced a Debug privilege in Windows that users need to have to start debugging stuff *ages* ago.
It turns out that letting arbitrary processes opening each others’ address spaces debugging each other is a real problem.
The question here is not why is SELinux disabling gdb and strace by default, the real question is why wasn’t this fixed when it was highlighted as a vulnerability in Windows?
Then we can talk about why this is a sebool rather than group membership as it is in MS-land…
Anyway, until a sandbox mechanism even 10% as good as the old Java Applet model comes along, SELinux is all we have.
DDD
If you think that having encrypted home directories are important and desirable security feature, but ptrace_deny is a worthless nuisance then your ability to gauge the relative danger of various security threats is seriously in doubt. In fact; it’s almost completely ass-backwards.
The #1 threat to any desktop is going to be exploitable bugs in any software that retrieves or process data from the internet. Anything that plays streaming media, opens up downloaded files, views html data over http, etc etc. is a potential threat to your information.
Since Linux has traditionally had _zero_ access controls between processes running under the same user AND all the user’s sensitive information is going to be stored user-readable in their account then the security controls for the Linux desktop is roughly on par with Windows 98.
Denying ptrace-by-default is just one of those brain dead obvious moves. It’s a gaping hole in Linux desktop security and is just absolutely a basic thing that needs to be addressed before you can even pretend to care about security within a user account. Without it it makes any attempt to improve/implement security controls a complete mockery.
Now, obviously, the blog poster has a very valid point about SELinux being shit.
For a feature like ‘deny ptrace’ to be fully baked it’s going to have to require a lot more work then just turning off the ability by default. Since now you are making debugging a program a privileged operation you are going to have to take that into account. Probably integrate debugging privileges into policykit as a minimum.
And that is just a start.
Next step is going to be gaining the ability to tag and identify files and data coming over the internet and putting special restrictions on the processes that are using them.
If Microsoft can pull it off with XP SP2 over 7 years ago, then the same thing should be possible on a Linux desktop.
We use SELinux for one of our project’s security.For more than a year now,we are extremely happy with SELinux.I agree, SELinux is pain to configure,If you come across that period,Its really awesome.
I only leave selinux on on machines that are exposed directly to the internet. I recently setup two Centos 6.2 boxes and the selinux configuration was great. The only tweak I had to make was to tell selinux to allow ssh to listed on a different port than the default.
[WORDPRESS HASHCASH] The poster sent us ‘0 which is not a hashcash value.
I have been using Linux since Redhat 5.2 both professionally and personally as developer for over 10 years. When I moved to Fedora 14 SELinux was a complete pain. I turned it off in the end it was not worth the time and trouble to sort through all the commands, options and debug messages to get it working the way I needed it to. I spent at least a couple of days on this and then decided it was not worth my time, this tells me it is not setup for easy user configuration, even by an extremely experienced user.
I turn SELinux off by default because it’s sh1t, almost on the scale of sh1t that they call GNOME 3 but not quite that bad.
SELinux initially was a pain and I often turned it off. But now I always leave it on and it doesn’t bother me. I have installed Fedora for many users and they’ve never had issues because of it.
I have occasionally had to change an SELinux setting, but almost always that’s due to third party software (not included in Fedora) doing things they shouldn’t. For example, I tried Adobe software once and it had executable stack enabled (bad). In that case I just cleared the flag on the libraries. Another example is wine mmaping address 0, which requires an SELinux boolean flipped.
I’m pretty sure the ptrace block will still allow abrt to work, so it really doesn’t affect normal users. As a developer, I’m quite capable of changing a boolean to allow me to use gdb. And I’m happy that normal users have that extra security.