[PATCH] UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

[Kees Cook]

On Thu, May 13, 2010 at 10:39:48AM +0200, Scott James Remnant wrote:
> On Thu, 2010-05-13 at 01:33 -0700, Kees Cook wrote:
> > This patch is specifically for blocking access to processes that hold
> > credentials in memory but don't set prctl[1].  This change pro-actively
> > helps protect such scenarios.
> > 
> Why don't you just fix the apps concerned to use prctl() or to lock
> their memory?

Well, I intend to, which is why the bug exists, but there will always be
new software.  That's why this is considered "pro-active" defense.

> > Having developers/admins use sudo or add a file to /etc/sysctl.d to
> > restore the original PTRACE behavior isn't much of an inconvenience.
> > 
> I disagree in the strongest terms.

Understood.

> If security gets in the way of people using their computers, they will
> simply disable it.
> 
>   Fedora's SELinux policy
>   Windows' UAC

I couldn't agree more, and am very aware of these situations.  I just
disagree with you about the level of inconvenience and the size of the
affected audience.

> Being able to debug processes running as your user is an important tool
> for developers.  This will annoy the hell out of them, and they will
> disable your patch.

They will disable the sysctl setting or gain CAP_SYS_PTRACE temporarily.

> That means we'll get less testing of your patch, and potential problems
> will be hidden from us until release.

I believe the set of people testing maverick that does not disable this
feature system-wide will be sufficiently large to gain meaningful testing.

> I really dislike these meme that it's acceptable for developers to have
> to add toggles or files to restore a system to a state they can work
> with; not because we should be developer focussed, but because our
> developers are still our primary testers.

It sounds like you object to the default setting, not the feature itself.

> I would far prefer to individual apps jailed from each other entirely,
> empathy shouldn't be *able* to exec firefox, etc.

I totally agree.  This isn't possible now, so I am proposing improvements
to the existing methodologies.

-Kees

-- 
Kees Cook
Ubuntu Security Team