[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4FBE5E3C.9070600@zytor.com>
Date: Thu, 24 May 2012 09:13:48 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Will Drewry <wad@...omium.org>
CC: linux-kernel@...r.kernel.org, mcgrathr@...gle.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,
luto@....edu, 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, jmorris@...ei.org
Subject: Re: [RFC PATCH 0/3] move the secure_computing call
On 05/24/2012 09:07 AM, Will Drewry wrote:
> This is an RFC based on the comments from Al Viro and Eric Paris
> regarding ptrace()rs being able to change the system call the kernel
> sees after the seccomp enforcement has occurred (for mode 1 or 2).
>
> With this series applied, a (p)tracer of a process with seccomp enabled
> will be unable to change the tracee's system call number after the
> secure computing check has been performed.
>
> The x86 change is tested, as is the seccomp.c change. For other arches,
> it is not (RFC :). Given that there are other inconsistencies in this
> code across architectures, I'm not sure if it makes sense to attempt to
> fix them all at once or to roll through as I attempt to add seccomp
> filter support.
>
> 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.
>
> Thoughts, comments, flames will be appreciated!
I think this really screws with using seccomp for self-interception. I
wouldn't inherently be opposed to the following flow:
seccomp -> ptrace -> seccomp
... i.e. if ptrace is enabled and we enable something, run it through
seccomp again, but there are bunch of use cases (mostly involving
SIGSYS) where doing ptrace before seccomp is just bizarre.
-hpa
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.
