Fedora is awesome, because it not only breaks gdb and strace in the default install, it even advertises it as a feature. I wonder if this is enough as a proof that Fedora security people have no clue about security?
Why Fedora is awesome
April 7th, 2012 | General
31 comments ↓
And it is also awesome because it’s freaking difficult to update it from release to release, moreover without breaking anything.
The feature page explicitly says, “it will be optional and turned off by default” — did this change in implementation? If it’s on by default, I’d file a bug against the feature.
4/10.
“optional and turned off by default” means: “we don’t care about normal people, as they will never enable this feature; and we don’t care about developers, because they will not be able to fix issues on systems with this feature turned on”.
in practice, it’s such a stupid feature that nobody in their right mind should use it; it’s snake oil: “see, we can stop processes from looking at other processes”. I expect more, *much* more from Fedora – even though it’s the distro that stops Avahi by default on its firewall because of “reasons”, so I guess I shouldn’t be surprised…
@Josh: It’s on here – or I wouldn’t even have noticed. So either it’s one of those “we’ll turn it on in the beta because we’re trying to annoy people to be sure they manually turn it off” cases, or someone’s doing it wrong.
Emmanuele, Also UPnP!
Josh, About filing bugs, here is a fine example of what usually happens to such bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=626188
i-e NOTHING! Even if you provide patches.
I didn’t leave Fedora – it has left me. I’ll likely be switching to Debian or one of the many other ‘flavors’ based upon it.
Between GNOME’s and Mozilla’s hyjinks during the past year, I fear for the future of open source. Everybody makes mistakes, but if I didn’t know better, I’d think this is part of a deliberate agenda to wreck the open source movement.
Has anyone thought about the fact that ptrace/debugging in general is disabled to stop the linux equivalent or create-remote-thread? Watch the video, actually implement create-remote-thread on linux, then tell me it’s a bad idea to disable debuggers out of the box.
http://www.youtube.com/watch?v=vl32F3bMYUQ
Don’t taunt Redhat for no reason.
Shouldn’t this be something that’s automatically enabled when you install gdb/strace from the repos?
I can see leaving it off on some default desktop install, but if you explicitly chose to install gdb and strace from a trusted source, it’s entirely reasonable to expect them to work.
While I have never seen any malware using gdb/strace, that’s indeed a big problem to be able to run ptrace on anything. Doing a good default choice is rather difficult, since whatever you do, there will be people annoyed by the issue ( I have seen this at work, people are annoyed by disk encryption despites having seen laptop theft the same week ).
If the system is off by default, people will not bother to use it. If the system is on by default, some people will turn it off ( as said by Dan on his blog : http://danwalsh.livejournal.com/49564.html )
And yes, I have also seen that the feature is on after upgrade by yum :
# getsebool deny_ptrace
deny_ptrace –> on
“Most users should never be bothered by this feature being turned on. A programmer wishing to debug an application would be prevented from running the debugger until he turns the feature off. ”
I think this makes it pretty clear. This will only disturb those who will be using gdb/strace, and most people just won’t notice it. If you’re using gdb/strace, you’re tech savvy enough to turn off a SELinux boolean (setsebool -P deny_ptrace 0). This post summarized this well : http://danwalsh.livejournal.com/49564.html
Actually the idea is pretty awesome. Many security breaks involve messing with other processes memory. This feature has nothing to do with “problems for average” users, they usually don’t debug programs ;) And the best solution for now seems to be what James Cape says – turn off the feature only when installing debugger or such.
If it is all that bad, why don’t we all just go spend a couple hundred bucks and use WINDOWS?
@Siosm: you (and, by proxy, Dan) missed the point by about a thousand miles. I may be tech savvy enough to disable it for my own development purposes (though I’ll end up disabling SELinux altogether because I honestly don’t care about it one bit; the whole thing ought to be disabled by default, and only enabled on RHEL, to avoid subjecting Fedora users to the pain and misery it brings – but I digress, and this parenthetical has already grown too long), but GNOME, like any other open source project, relies heavily on its users for QA and help in triaging the bugs because we don’t have dedicated resources for a QA team. what you’re saying is that anyone that files a bug won’t be able to help tracking issues down or even get a backtrace, which means that the GNOME developers will now have to do more QA in their copious amount of spare time; alternatively, that anyone willing to devote time to help out debugging or do QA will have to temporarily (or definitely) make their OS less secure. good job! yey security!
the change assumes that development and QA are totally separated from the installed user base; this may be true for everyone involved in the Fedora security team, but it’s definitely not going to help anyone actually making the stuff that runs on top of the base system.
this reminds me of the Microsoft approach to security; you only get two options: 1) everything turned to 11, level “paranoid nutter living in an abandoned missile silo in the wilderness with a ton of guns and canned food”; and 2) everything passes, woot! after a day at level 1, the user decides that she has work to do, so the security level is consciously changed to 2. and, lo’ and behold, it’s not Microsoft’s fault if your laptop gets infested by the virus from hell: it’s your fault for having changed from the default, secure setting.
this is why I think this feature is really snake oil, because it doesn’t solve anything, and instead it creates an accessibility problem.
@Steven: yes, why shouldn’t we all do that?
oh, wait: because I care about this crap that I’ve been contributing to for the past 10 years, and I hate seeing stuff broken in the name of “security”.
Emmanuele is ABSOLUTELY right. This is ridicolous. I wonder how can GNOME attract new developers to its ecosystem, when the main distribution that is shipping GNOME is in such a state.
GNOME is awesome, but, I’m sorry to say this, distibutions aren’t. I’m looking forward to GNOME OS!
They don’t have much clue about most things, to be honest, but where they do have (package manager and organization, for example) it’s awesome. Oh, and Debian is aiming to implement SELinux, which will probably push Ubuntu and most Debian-based distros to do so.
“GNOME relies on its users?” Since when?
@Emmanuele:
I don’t buy the “it is not a server so ignore security” argument … desktop / consumer systems are more in need of good security by default because there is no admin which has the knowledge to set up things to be secure.
That being said the deny_ptrace issue violates the rule of “unconfined apps should not have any restrictions” so I assume it is just on during development to catch issues and will be disabled for GA (but anyway filing a bug makes more sense then ranting in a blog).
@J. Smith: if you don’t have anything constructive to contribute to the discussion then just. go. away.
@drago01: I totally agree that desktop/consumer systems need better security. I just don’t think SELinux provides better security, if it forces people in a state of either full on paranoia, or disabling stuff (either temporarily or, more likely, definitely).
Gdb isn’t broken by default. Its disabled.
Gnome calendar however is broken by default and the gnome extensions are broken by API changes every release and gnome power management is broken by design. It is beyond hilarious to see gnome complaining about gdb and strace being off by default when it considers its users.are.too stupid to be allowed a shutdown.and.restart button.in the menu. Just be thankful there isn’t a gnome designer.on.the security team. They would have removed the ability to.enable it altogether
Ubuntu – once again (sigh) – gets it right: They also disable ptrace by default, but when their gdb notices you just failed to attach because of this mechanism it prints helpful information on how to reenable ptrace.
Way too easy, not?
No Mathias. Because that’s exactly what Fedora does. I don’t need a cryptic unbreak-my-computer command. (And fwiw, every email with attached files works the same way.)
Should I dig out Havoc’s article about unbreak-me options again?
@Emmanuele
“if it forces people in a state of either full on paranoia, or disabling stuff” unless I hit a bug (which didn’t happen here for a long time) selinux does not get in my way. This is just a stereotype that is present all over the internet (from the early days of selinux) but today you should not have to disable it. As shown by the ptrace thing you can toggle one boolean to enable / disable it so no it does not give you the choice between “full paranoia” and “disable it”.
@drago01: “disable it” – and by “it” I meant “the ptrace protection”, not the whole SELinux; I do have SELinux enabled on my Fedora installation because SELinux has undoubtably become better over the years at not sucking hairy balls to the point of requiring to be turned off, like it was in f12 up to f14.
but the issue still remains: it assumes that developers have root on their machine (which is not always the case, nor should it be); it assumes that people know about SELinux policies enough so that they will purposefully escalate privileges and disable (temporarily or definitely) a security feature; and it assumes that this will apply to everyone doing QA. those are three fairly big assumptions, and are three assumptions that should not have been purposefully made without consulting with the people using the damned thing — and I’m not talking about FESCo.
this is not a “we know better than our users” thing that gets pinned on GNOME far too often and makes me want to gouge people’s eyes out; this is what I call professional courtesy, and a modicum of foresight.
Benjamin: Absolute don’t get the issue then. There is absolutely no reason to permit ptrace by default.
@dragon01: Cannot imaging a scenario where developers relying on gdb don’t have root access. Please give an example.
Mathias: I don’t care about ptrace. I care about gdb. And gdb is broken by default.
Have encountered this on Ubuntu some releases ago -> was annoyed -> read the docs -> disabled the protection on my desktop system and left it intact on the notebook -> happy. I treat the error as a “the action you’re trying to perform requires admin privileges” dialog displayed on the console. Works for me.
@Emmanuele : what professionnal courtesy? Fedora is a desktop distribution for non tech users. As Gnome is.
If Fedora is not suitable for your professionnal practice, just go away and find another one that suits your needs.
It’s illarious to see that when gnome dev talk to their user’s they think they know better than them, but when security distribution tell them they know better, gnome devs turn like their user’s and start complaining all the same…
Linux! Bwahahahahahaha!
Emmanuele: we have an automated system for catching crashes, grabbing a traceback, and reporting a bug. It’s called abrt. It works very well. If a GNOME app crashes on a Fedora user they can click about three buttons to submit a full backtrace. No manual use of gdb required.