As I discussed last year, Ubuntu has been restricting the use of ptrace for a few releases now. I’m excited to see Fedora starting to introduce similar restrictions, but I’m disappointed at the specific implementation:
- A method for doing this already exists (Yama). Yama is not plumbed into SELinux, but I would argue that’s not needed.
- The SELinux method depends, unsurprisingly, on an active SELinux policy on the system, which isn’t everyone.
- It’s not possible for regular developers (not system developers) to debug their own processes.
- It will break all ptrace-based crash handlers (e.g. KDE, Firefox, Chrome) or tools that depend on ptrace to do their regular job (e.g. Wine, gdb, strace, ltrace).
Blocking ptrace blocks exactly one type of attack: credential extraction from a running process. In the face of a persistent attack, ultimately, anything running as the user can be trojaned, regardless of ptrace. Blocking ptrace, however, stalls the initial attack. At the moment an attacker arrives on a system, they cannot immediately extend their reach by examining the other processes (e.g. jumping down existing SSH connections, pulling passwords out of Firefox, etc). Some sensitive processes are already protected from this kind of thing because they are not “dumpable” (due to either specifically requesting this from prctl(PR_SET_DUMPABLE, ...) or due to a uid/gid transition), but many are open for abuse.
The primary “valid” use cases for ptrace are crash handlers, debuggers, and memory analysis tools. In each case, they have a single common element: the process being ptraced knows which process should have permission to attach to it. What Linux lacked was a way to declare these relationships, which is what Yama added. The use of SELinux policy, for example, isn’t sufficient because the permissions are too wide (e.g. giving gdb the ability to ptrace anything just means the attacker has to use gdb to do the job). Right now, due to the use of Yama in Ubuntu, all the mentioned tools have the awareness of how to programmatically declare the ptrace relationships at runtime with prctl(PR_SET_PTRACER, ...). I find it disappointing that Fedora won’t be using this to their advantage when it is available and well tested.
Even ChromeOS uses Yama now. ;)
© 2012, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License.
When it is expected to have other aspects of Yama available in kernel tree?
Like hardlink ad symlink protections in place?
I have an issue also when setting ptrace. When passing:
sudo sysctl -w kernel.yama.ptrace_scope=2
I get:
sysctl: setting key “kernel.yama.ptrace_scope”: Invalid argument
Maybe I’m doing it wrong, I’m not well versed with linux. I’d like to have increased security by default and Yama seems to fit the bill.
Currently running:
3.4.0-7.dmz.1-liquorix-amd64
Comment by naugty bit — August 4, 2012 @ 7:02 am
The hardlink and symlink restrictions are scheduled for the 3.6 Linux kernel, but as part of the VFS, not Yama.
The additional scopes (2 and 3) for Yama were introduced in the 3.5 Linux kernel, so it is not available in 3.4, as you’ve discovered. :)
Comment by kees — August 7, 2012 @ 9:03 am
Cool, thanks for answering;) I have to wait for a while then.
Had to Google VFS to get the picture painted. I assume that reasoning behind it is twofold, to have kernel hardened by default in simplest possible way by supporting all of the existing filesystems through VFS and not using LSM interface in order to have it available for other sec modules if wanted?
Good to know this stuff is getting accepted in the main tree. As a regular user I can’t be bothered to learn complex stuff like SELinux or recompile kernel just for grsec. Keep up the good work, you seem to be very good at it!
Comment by naughty bit — August 7, 2012 @ 9:58 am