[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 24 May 2012 20:27:43 +0200
From: "Indan Zupancic" <indan@....nu>
To: "Roland McGrath" <mcgrathr@...gle.com>
Cc: "H. Peter Anvin" <hpa@...or.com>,
"Will Drewry" <wad@...omium.org>,
linux-kernel@...r.kernel.org,
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 Thu, May 24, 2012 20:07, Roland McGrath wrote:
> On Thu, May 24, 2012 at 9:13 AM, H. Peter Anvin <hpa@...or.com> wrote:
>> 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.
>
> Are you sure? This is ptrace syscall tracing going first.
> If seccomp generates a SIGSYS, then ptrace will still get its opportunity
> to intercept the signal and change the register state however it likes.
If so, then the seccomp check needs to be redone after any ptrace
changes, or we should give up and just do the seccomp check first,
instead of possibly looping forever. PTRACE_EVENT_SECCOMP has the
same problem.
If a seccomp filtered task can do ptrace(), it can easily bypass
the seccomp filter by ptracing any task not under the same filter
but from the same user. And then it can puppeteer the victim into
doing anything it wishes. So pretending seccomp can make a ptracer
secure is futile, I think. Perhaps it's better to keep it simple and
always do the seccomp test first and ignore ptrace changes, however
sad that may seem. Seccomp had the power to stop ptrace(). It didn't,
so it shouldn't try to do it afterwards either.
It's a bit fuzzy though, only reason why doing seccomp first is more
convenient is because seccomp can generate ptrace events. I don't
think it will make a difference in practice because ptrace(2) won't
be allowed by seccomp filters anyway, so it's a bit of a theoretical
problem.
Greetings,
Indan
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.
