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

[Tim Gardner]

On 05/13/2010 02:59 AM, Kees Cook wrote:
> 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
>

Is it safe to assume that developers that might encounter this minor 
restriction would also have ubuntu-dev-tools installed? We could add 
something to that package that swizzles /proc/sys/kernel/ptrace_scope, 
thereby avoiding inconvenience to developers while still providing a 
good test for the normal install.

rtg
-- 
Tim Gardner tim.gardner at canonical.com