linux-kernel - Re: [RFC PATCH 0/3] move the secure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e73397a67afcb95c39a4560fe104912a.squirrel@webmail.greenhost.nl>
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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/