change coming with maverick's 2.6.34-5 kernels

[Kees Cook]

On Mon, May 31, 2010 at 04:23:01PM +0100, Matt Zimmerman wrote:
> 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.

Agreed.  And this is balanced against a small additional layer of security
for everyone else.

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

I think that if it is package-triggered, it should get a debconf setting.
For example, I would would this protection my colo server, but that system
has libc6-dev installed.

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

The debconf question could be shared across strace, gdb, and ltrace maybe,
but that doesn't help the situation of finding a good heuristic to restore
the original behavior.

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

Right.

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

CAP_SYS_PTRACE is more powerful, unfortunately.  It allows PTRACE of _any_
process.

-Kees

-- 
Kees Cook
Ubuntu Security Team