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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ