linux-kernel - Re: seccomp: add "seccomp" syscall

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] [day] [month] [year] [list]

Date:	Tue, 12 Aug 2014 09:25:43 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux API <linux-api@...r.kernel.org>
Subject: Re: seccomp: add "seccomp" syscall

On Mon, Aug 11, 2014 at 1:07 PM, Geert Uytterhoeven
<geert@...ux-m68k.org> wrote:
> Hi Kees,
>
> v3.17 is gonna get a lot of new syscalls...

4 so far! :P

>
> On Wed, Aug 6, 2014 at 6:27 PM, Linux Kernel Mailing List
> <linux-kernel@...r.kernel.org> wrote:
>> Gitweb:     http://git.kernel.org/linus/;a=commit;h=48dc92b9fc3926844257316e75ba11eb5c742b2c
>> Commit:     48dc92b9fc3926844257316e75ba11eb5c742b2c
>> Parent:     3b23dd12846215eff4afb073366b80c0c4d7543e
>> Refname:    refs/heads/master
>> Author:     Kees Cook <keescook@...omium.org>
>> AuthorDate: Wed Jun 25 16:08:24 2014 -0700
>> Committer:  Kees Cook <keescook@...omium.org>
>> CommitDate: Fri Jul 18 12:13:37 2014 -0700
>>
>>     seccomp: add "seccomp" syscall
>>
>>     This adds the new "seccomp" syscall with both an "operation" and "flags"
>>     parameter for future expansion. The third argument is a pointer value,
>>     used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must
>>     be 0. This is functionally equivalent to prctl(PR_SET_SECCOMP, ...).
>>
>>     In addition to the TSYNC flag later in this patch series, there is a
>>     non-zero chance that this syscall could be used for configuring a fixed
>>     argument area for seccomp-tracer-aware processes to pass syscall arguments
>>     in the future. Hence, the use of "seccomp" not simply "seccomp_add_filter"
>>     for this syscall. Additionally, this syscall uses operation, flags,
>>     and user pointer for arguments because strictly passing arguments via
>>     a user pointer would mean seccomp itself would be unable to trivially
>>     filter the seccomp syscall itself.
>>
>>     Signed-off-by: Kees Cook <keescook@...omium.org>
>>     Reviewed-by: Oleg Nesterov <oleg@...hat.com>
>>     Reviewed-by: Andy Lutomirski <luto@...capital.net>
>
> Is this something that I should enable?
>
> As it depends on CONFIG_SECCOMP, it only makes sense on architectures that
> already support CONFIG_SECCOMP, right?
> Does it make sense to reserve a syscall slot for it on architectures that
> don't support it yet?

I don't see a good reason to reserve the syscall slot if seccomp
filter is not already implemented. I've CCed linux-api in case there
is something I'm not considering, though.

FWIW, if someone wants to add it for m68k, the steps to support
seccomp are listed in the arch/Kconfig for HAVE_ARCH_SECCOMP_FILTER.

-Kees

-- 
Kees Cook
Chrome OS Security
--
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/