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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 17 Jul 2014 08:45:52 -0700 From: Kees Cook <keescook@...omium.org> To: David Drysdale <drysdale@...gle.com> Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Andy Lutomirski <luto@...capital.net>, Oleg Nesterov <oleg@...hat.com>, James Morris <jmorris@...ei.org>, "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>, Alexei Starovoitov <ast@...mgrid.com>, Andrew Morton <akpm@...ux-foundation.org>, Daniel Borkmann <dborkman@...hat.com>, Will Drewry <wad@...omium.org>, Julien Tinnes <jln@...omium.org>, Linux API <linux-api@...r.kernel.org>, "x86@...nel.org" <x86@...nel.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, Linux MIPS Mailing List <linux-mips@...ux-mips.org>, linux-arch <linux-arch@...r.kernel.org>, LSM List <linux-security-module@...r.kernel.org> Subject: Re: [PATCH v11 11/11] seccomp: implement SECCOMP_FILTER_FLAG_TSYNC On Thu, Jul 17, 2014 at 8:04 AM, David Drysdale <drysdale@...gle.com> wrote: > On Wed, Jul 16, 2014 at 10:50 PM, Kees Cook <keescook@...omium.org> wrote: >> diff --git a/kernel/seccomp.c b/kernel/seccomp.c >> index 9065d2c79c56..2125b83ccfd4 100644 >> +/** >> + * seccomp_can_sync_threads: checks if all threads can be synchronized >> + * >> + * Expects sighand and cred_guard_mutex locks to be held. >> + * >> + * Returns 0 on success, -ve on error, or the pid of a thread which was >> + * either not in the correct seccomp mode or it did not have an ancestral >> + * seccomp filter. >> + */ >> +static inline pid_t seccomp_can_sync_threads(void) >> +{ >> + struct task_struct *thread, *caller; >> + >> + BUG_ON(!mutex_is_locked(¤t->signal->cred_guard_mutex)); >> + BUG_ON(!spin_is_locked(¤t->sighand->siglock)); >> + >> + if (current->seccomp.mode != SECCOMP_MODE_FILTER) >> + return -EACCES; > > Quick question -- is it possible to apply the first filter and also synchronize > it across threads in the same operation? If so, does this arm also need to > cope with seccomp.mode being SECCOMP_MODE_DISABLED? > > [seccomp_set_mode_filter() looks to call this via seccomp_attach_filter() > before it does seccomp_assign_mode()] I don't entirely understand what you're asking. The threads gain the filter and the mode before the current thread may gain the mode (if it's the first time this has been called). Due to all the locks, though, this isn't a problem. Is there a situation you see where there might be a problem? -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/
Powered by blists - more mailing lists