change coming with maverick's 2.6.34-5 kernels

Evan Martin evan at
Fri Jun 11 19:04:23 BST 2010

I am no expert, but smarter people than me think suspect that this
first change will break Breakpad, the crash-catching system used by
Mozilla and Chromium:

Here's a bug for discussion:

On Sun, May 30, 2010 at 10:03 PM, Kees Cook <kees at> wrote:
> Hello,
> As discussed[1] at UDS, Maverick's kernel will include three changes that
> are common to other security-hardened Linux distributions.  The intent
> is to gain these additional protections for the by-default average
> Ubuntu system:
>  a) PTRACE of direct children only (protects credentials-of-the-past)
>  b) protected symlink following in sticky world-writable directories
>    (stops /tmp symlink races)
>  c) protected hardlink creation (stops hardlink injection)
> What this means for you if you don't change any of the defaults:
>  a) Using "strace -p PID" and gdb's "attach" command will NOT work
>    unless you are the root user (i.e. use "sudo strace -p PID ...")
>    Running stuff with "strace" and "gdb" directly will work normally.
>  b) Following symlinks in sticky world-writable directories (/tmp) that
>    are not owned by you will fail.  This change should not be noticed
>    except under situations where a process is genuinely being attacked.
>  c) Creating hardlinks to files you cannot read or write is no longer
>    allowed.  This _may_ cause problems for some less common applications,
>    and we need to find and fix them.
> Each option has a sysctl associated with it that you can toggle locally if
> you want to restore the original behavior:
>  a) /proc/sys/kernel/ptrace_scope: "0" allows original ptrace behavior
>  b) /proc/sys/fs/weak-sticky-symlinks: "1" allows original symlink behavior
>  c) /proc/sys/fs/weak-nonaccess-hardlinks: "1" allows original link behavior
> I expect that the PTRACE changes will cause the greatest surprise.  Since
> PTRACE is rarely needed by normal users, this change makes sense for the
> default install, but is going to cause irritation for developers and system
> administrators.  To that end, I'd like to get feedback on how best to
> address this situation.
> Some initial ideas that have been suggested to me already:
>  - add a file to /etc/sysctl.d/ that restores the PTRACE scope to "0"
>   if a specific package is installed (e.g. ubuntu-dev-tools; something
>   that the normal user will not install).
>  - update all documentation to include "sudo" in front of "strace"
>  - add a kernel message that points to the sysctl directly, making
>   the change as discoverable as possible, when a PTRACE is rejected.
> I'm curious what other people would recommend.  Once there's some
> consensus, I will go implement it.  :)
> Thanks for reading!  There are some further details in the wiki[2].
> -Kees
> [1]
> [2]
> --
> Kees Cook
> Ubuntu Security Team
> --
> ubuntu-devel mailing list
> ubuntu-devel at
> Modify settings or unsubscribe at:

More information about the ubuntu-devel mailing list