* Dave Hansen <d...@sr71.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.han...@linux.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.han...@linux.intel.com>
> Cc: linux-security-mod...@vger.kernel.org
> Cc: linux-a...@vger.kernel.org
> Cc: Stephen Rothwell <s...@canb.auug.org.au>
> Cc: Mimi Zohar <zo...@linux.vnet.ibm.com>
> Cc: Russell King <li...@arm.linux.org.uk>
> Cc: Michal Simek <mon...@monstr.eu>
> Cc: Ralf Baechle <r...@linux-mips.org>
> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> Cc: Paul Mackerras <pau...@samba.org>
> Cc: Martin Schwidefsky <schwidef...@de.ibm.com>
> Cc: Heiko Carstens <heiko.carst...@de.ibm.com>
> Cc: Paul Mundt <let...@linux-sh.org>
> Cc: x...@kernel.org
> Cc: James Morris <james.l.mor...@oracle.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 <mi...@kernel.org>
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
