* Dave Hansen <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > Cc: [email protected] > Cc: [email protected] > Cc: Stephen Rothwell <[email protected]> > Cc: Mimi Zohar <[email protected]> > Cc: Russell King <[email protected]> > Cc: Michal Simek <[email protected]> > Cc: Ralf Baechle <[email protected]> > Cc: Benjamin Herrenschmidt <[email protected]> > Cc: Paul Mackerras <[email protected]> > Cc: Martin Schwidefsky <[email protected]> > Cc: Heiko Carstens <[email protected]> > Cc: Paul Mundt <[email protected]> > Cc: [email protected] > Cc: James Morris <[email protected]> > > --- > > 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 <[email protected]> Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
