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]

Date:	Thu, 24 May 2012 11:45:21 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Indan Zupancic <indan@....nu>
CC:	Roland McGrath <mcgrathr@...gle.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 05/24/2012 11:27 AM, Indan Zupancic wrote:
> 
> 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.
> 

No, that's not the reason to do seccomp first.  The reason to do seccomp
first is that a seccomp filter can be part of the process execution and
can completely transform the system call picture.

Consider UML, for example.  It uses ptrace to capture system calls and
execute them on the behalf of the process.  It needs to know what system
calls *actually* are done by the virtual process.

(Note: that being said, UML might very well be better done using seccomp
filters *instead* of ptrace, but that's another matter.)

I agree with you, if the process is traceable it is rather questionable
to claim any kind of security; more likely consider that a debugging
mode and tell people to lock out ptrace for real sandboxing.

	-hpa

--
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/