On Mon, Jul 14, 2014 at 6:53 PM, James Morris [off-list ref] wrote:

On 07/15/2014 04:59 AM, Kees Cook wrote:

quoted

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 [off-list ref] wrote:

quoted

On Fri, Jul 11, 2014 at 9:49 AM, Oleg Nesterov [off-list ref] wrote:

quoted

On 07/10, Kees Cook wrote:

quoted

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

quoted

Reviewed-by: Oleg Nesterov <redacted>

--
Kees Cook
Chrome OS Security

Yep, certainly.

Any ETA?  I'm currently blocking on having stable commit hashes for these.

If you're planning on pulling from Kees' tree instead of importing the
patches, I can work with that, too.

Thanks,
Andy