[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 24 May 2012 16:43:29 -0700
From: Andrew Lutomirski <luto@....edu>
To: James Morris <jmorris@...ei.org>
Cc: Will Drewry <wad@...omium.org>, linux-kernel@...r.kernel.org, mcgrathr@...gle.com,
hpa@...or.com, indan@....nu, netdev@...isplace.org,
linux-security-module@...r.kernel.org, kernel-hardening@...ts.openwall.com,
mingo@...hat.com, oleg@...hat.com, peterz@...radead.org, rdunlap@...otime.net,
tglx@...utronix.de, serge.hallyn@...onical.com, pmoore@...hat.com,
akpm@...ux-foundation.org, corbet@....net, markus@...omium.org,
coreyb@...ux.vnet.ibm.com, keescook@...omium.org, viro@...iv.linux.org.uk
Subject: Re: [RFC PATCH 0/3] move the secure_computing call
On Thu, May 24, 2012 at 4:40 PM, James Morris <jmorris@...ei.org> wrote:
> On Thu, 24 May 2012, Will Drewry wrote:
>
>> As is, the biggest benefit of this change is just setting consistent
>> expectations in what the ptrace/seccomp interactions should be. The
>> current ability for ptrace to "bypass" secure computing (by remapping
>> allowed system calls) is not necessarily a problem, but it is not
>> necessarily intuitive behavior.
>
> Indeed -- while the purpose of seccomp is to reduce the attack surface of
> the syscall interface, if a user allows ptrace, attackers will definitely
> see that as an attack vector, if it allows them to increase that attack
> surface.
>
> It at least needs to be well-documented.
IMO the behavior should change. Alternatively, a post-ptrace syscall
should have to pass the *tracer's* seccomp filter, but that seems
overcomplicated and confusing.
OTOH, allowing ptrace in a seccomp filter is asking for trouble anyway
-- if you can ptrace something outside the sandbox, you've escaped.
--Andy
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
