linux-kernel - Re: [PATCH] kconfig: consolidate arch-specific seccomp options

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, 30 Jan 2014 09:55:51 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Dave Hansen <dave@...1.net>
Cc:	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	linux-security-module@...r.kernel.org, linux-arch@...r.kernel.org,
	sfr@...b.auug.org.au, zohar@...ux.vnet.ibm.com,
	linux@....linux.org.uk, monstr@...str.eu, ralf@...ux-mips.org,
	benh@...nel.crashing.org, paulus@...ba.org, schwidefsky@...ibm.com,
	heiko.carstens@...ibm.com, lethal@...ux-sh.org, x86@...nel.org,
	james.l.morris@...cle.com
Subject: Re: [PATCH] kconfig: consolidate arch-specific seccomp options


* Dave Hansen <dave@...1.net> wrote:

> 
> There are some minor updates here from last time:
>  * added a def_bool instead of separate lines in config
>  * clarified that the /proc interface is *GONE*
> 
> cc'ing a bunch of folks directly now instead of depending
> on linux-arch@ to awaken them.  I think it's most appropriate
> for this to go in via the security tree, but I guess it
> could also go directly to Linus.
> 
> --
> 
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> There are 7 architecures with "config SECCOMP".  They all have
> virtually the same help text except for those referencing the
> /proc interface.  The /proc interface was removed in 2007.
> 
> There is *NOTHING* architecture-specific about SECCOMP except
> that the syscalls have per-architecture definitions, like every
> other syscall.  It is absurd to have the option in the
> arch-specific menus.
> 
> Move it to the security menu, consolidate the 7 down to one, and
> remove the embarassingly-ancient help text references and
> dependencies on /proc.
> 
> Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
> Cc: linux-security-module@...r.kernel.org
> Cc: linux-arch@...r.kernel.org
> Cc: Stephen Rothwell <sfr@...b.auug.org.au>
> Cc: Mimi Zohar <zohar@...ux.vnet.ibm.com>
> Cc: Russell King <linux@....linux.org.uk>
> Cc: Michal Simek <monstr@...str.eu>
> Cc: Ralf Baechle <ralf@...ux-mips.org> 
> Cc: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Cc: Paul Mackerras <paulus@...ba.org>
> Cc: Martin Schwidefsky <schwidefsky@...ibm.com>
> Cc: Heiko Carstens <heiko.carstens@...ibm.com>
> Cc: Paul Mundt <lethal@...ux-sh.org> 
> Cc: x86@...nel.org
> Cc: James Morris <james.l.morris@...cle.com>
> 
> ---
> 
>  b/arch/arm/Kconfig        |   15 +--------------
>  b/arch/microblaze/Kconfig |   18 +-----------------
>  b/arch/mips/Kconfig       |   18 +-----------------
>  b/arch/powerpc/Kconfig    |   18 +-----------------
>  b/arch/s390/Kconfig       |   18 +-----------------
>  b/arch/sh/Kconfig         |   17 +----------------
>  b/arch/sparc/Kconfig      |   18 +-----------------
>  b/arch/x86/Kconfig        |   17 +----------------

> --- a/security/Kconfig~consolidate-seccomp-options	2014-01-29 11:02:31.607008738 -0800
> +++ b/security/Kconfig	2014-01-29 11:02:31.616009147 -0800
> @@ -167,5 +167,24 @@ config DEFAULT_SECURITY
>  	default "yama" if DEFAULT_SECURITY_YAMA
>  	default "" if DEFAULT_SECURITY_DAC
>  
> -endmenu
> +config HAVE_ARCH_SECCOMP
> +	bool
> +


> +config SECCOMP
> +	def_bool y
> +	depends on HAVE_ARCH_SECCOMP
> +	prompt "Enable seccomp to safely compute untrusted bytecode"
> +	---help---
> +	  This kernel feature is useful for number crunching applications
> +	  that may need to compute untrusted bytecode during their
> +	  execution. By using pipes or other transports made available to

I'd change and simplify the first sentence to:

> +	  This kernel feature is useful to sandbox runtimes that need
> +	  to execute untrusted machine code.

Seccomp isn't primarily about number crunching anymore, and it's 
definitely not about 'bytecode' in the classical sense either.

> +	  the process as file descriptors supporting the read/write
> +	  syscalls, it's possible to isolate those applications in
> +	  their own address space using seccomp. Once seccomp is
> +	  enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> +	  and the task is only allowed to execute a few safe syscalls
> +	  defined by each seccomp mode.
>  
> +	  If unsure, say Y. Only embedded should say N here.
> +
> +endmenu

Other than that:

Acked-by: Ingo Molnar <mingo@...nel.org>

Thanks,

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