[PATCH] UBUNTU: SAUCE: ptrace: restrict ptrace scope to children
tim.gardner at canonical.com
Wed May 26 19:31:07 UTC 2010
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. 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.
>> 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.
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.
Tim Gardner tim.gardner at canonical.com
More information about the kernel-team