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

[Ingo Molnar]

* Dave Hansen <dave@xxxxxxxx> 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@xxxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxx>
> Cc: linux-security-module@xxxxxxxxxxxxxxx
> Cc: linux-arch@xxxxxxxxxxxxxxx
> Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>
> Cc: Mimi Zohar <zohar@xxxxxxxxxxxxxxxxxx>
> Cc: Russell King <linux@xxxxxxxxxxxxxxxx>
> Cc: Michal Simek <monstr@xxxxxxxxx>
> Cc: Ralf Baechle <ralf@xxxxxxxxxxxxxx> 
> Cc: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
> Cc: Paul Mackerras <paulus@xxxxxxxxx>
> Cc: Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
> Cc: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
> Cc: Paul Mundt <lethal@xxxxxxxxxxxx> 
> Cc: x86@xxxxxxxxxx
> Cc: James Morris <james.l.morris@xxxxxxxxxx>
> 
> ---
> 
>  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@xxxxxxxxxx>

Thanks,

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