change coming with maverick's 2.6.34-5 kernels

[Evan Martin]

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:
  http://code.google.com/p/google-breakpad/

Here's a bug for discussion:
  http://code.google.com/p/chromium/issues/detail?id=46368

On Sun, May 30, 2010 at 10:03 PM, Kees Cook <kees at ubuntu.com> 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] https://blueprints.launchpad.net/ubuntu/+spec/security-m-kernel-hardening
> [2] https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening
>
> --
> Kees Cook
> Ubuntu Security Team
>
> --
> ubuntu-devel mailing list
> ubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
>