change coming with maverick's 2.6.34-5 kernels

[Matt Zimmerman]

On Sun, May 30, 2010 at 10:03:45PM -0700, Kees Cook 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:

Thanks for providing this summary.

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

b) and c) sound like solid improvements with few tradeoffs. a), on the other
hand, seems like it would really trip up developers, who are a group we want
to make things easier for, not harder.

If we could find a way to ensure this is automatically turned on for
developers, I think that would be a reasonable tradeoff.  Ideas for
heuristics to detect developers:

- Installation of a developer metapackage [misses developers who install
  only what they want by hand]

- Installation of libc6-dev [could miss developers who don't compile C
  programs]

- Installation of strace and gdb [doesn't work since we install them by
  default]

I like the suggestion of fixing common ptrace callers like strace and gdb to
tell the user how to get the "standard" behavior back, but it would be even
better if we could take care of it for them.

How does this interact with CAP_SYS_PTRACE?  Could there be a way to grant
this privilege to specific programs like strace, but deny it to programs in
general?

-- 
 - mdz