change coming with maverick's 2.6.34-5 kernels
kees at ubuntu.com
Tue Jun 1 18:10:25 BST 2010
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
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
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.
> 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
CAP_SYS_PTRACE is more powerful, unfortunately. It allows PTRACE of _any_
Ubuntu Security Team
More information about the ubuntu-devel