On 07/15/2014 04:59 AM, Kees Cook wrote:
Hi James,
Is this series something you would carry in the security-next tree?
That has traditionally been where seccomp features have landed in the
past.
-Kees
On Fri, Jul 11, 2014 at 10:55 AM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
On Fri, Jul 11, 2014 at 9:49 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
On 07/10, Kees Cook wrote:
This adds the ability for threads to request seccomp filter
synchronization across their thread group (at filter attach time).
For example, for Chrome to make sure graphic driver threads are fully
confined after seccomp filters have been attached.
To support this, locking on seccomp changes via thread-group-shared
sighand lock is introduced, along with refactoring of no_new_privs. Races
with thread creation are handled via delayed duplication of the seccomp
task struct field and cred_guard_mutex.
This includes a new syscall (instead of adding a new prctl option),
as suggested by Andy Lutomirski and Michael Kerrisk.
I do not not see any problems in this version,
Awesome! Thank you for all the reviews. :) If Andy and Michael are
happy with this too, I think this is in good shape. \o/
-Kees
Reviewed-by: Oleg Nesterov <oleg@xxxxxxxxxx>
--
Kees Cook
Chrome OS Security
Yep, certainly.
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
