[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140130085551.GB2024@gmail.com>
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/
Powered by blists - more mailing lists