Why Fedora is awesome

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?


#1 Aloriel on 04.07.12 at 20:24

And it is also awesome because it’s freaking difficult to update it from release to release, moreover without breaking anything.

#2 Josh Stone on 04.07.12 at 20:38

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.

#3 sillav on 04.07.12 at 20:45


#4 Emmanuele on 04.07.12 at 20:49

“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…

#5 Benjamin Otte on 04.07.12 at 21:26

@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.

#6 Zeeshan Ali on 04.08.12 at 01:13

Emmanuele, Also UPnP!

Josh, About filing bugs, here is a fine example of what usually happens to such bugs:


i-e NOTHING! Even if you provide patches.

#7 karl on 04.08.12 at 01:49

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.

#8 Andrew King on 04.08.12 at 02:32

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.


Don’t taunt Redhat for no reason.

#9 James Cape on 04.08.12 at 03:33

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.

#10 Michael on 04.08.12 at 08:18

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

#11 Siosm on 04.08.12 at 09:11

“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

#12 DeadLock on 04.08.12 at 09:36

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.

#13 Steven Lemon on 04.08.12 at 10:07

If it is all that bad, why don’t we all just go spend a couple hundred bucks and use WINDOWS?

#14 Emmanuele on 04.08.12 at 10:27

@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.

#15 Emmanuele on 04.08.12 at 10:31

@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”.

#16 M. on 04.08.12 at 14:07

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!

#17 J. Smith on 04.08.12 at 14:48

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?

#18 drago01 on 04.08.12 at 15:55


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).

#19 Emmanuele on 04.08.12 at 17:18

@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).

#20 sillav on 04.08.12 at 20:49

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

#21 Mathias Hasselmann on 04.09.12 at 00:36

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?

#22 Benjamin Otte on 04.09.12 at 00:49

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?

#23 drago01 on 04.09.12 at 12:05


“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”.

#24 Emmanuele on 04.09.12 at 21:15

@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.

#25 Mathias Hasselmann on 04.10.12 at 16:35

Benjamin: Absolute don’t get the issue then. There is absolutely no reason to permit ptrace by default.

#26 Mathias Hasselmann on 04.10.12 at 16:37

@dragon01: Cannot imaging a scenario where developers relying on gdb don’t have root access. Please give an example.

#27 Benjamin Otte on 04.10.12 at 17:55

Mathias: I don’t care about ptrace. I care about gdb. And gdb is broken by default.

#28 oliver on 04.11.12 at 15:45

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.

#29 sillav on 04.12.12 at 11:57

@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…

#30 Geoffrey E. James on 04.13.12 at 01:12

Linux! Bwahahahahahaha!

#31 Adam Williamson on 04.13.12 at 07:02

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.