[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1cc0df8-bd06-51e7-d5a0-888c1955683b@gmail.com>
Date: Thu, 15 Oct 2020 13:24:03 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: Kees Cook <keescook@...omium.org>
Cc: mtk.manpages@...il.com, Tycho Andersen <tycho@...ho.pizza>,
Sargun Dhillon <sargun@...gun.me>,
Christian Brauner <christian@...uner.io>,
linux-man <linux-man@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Aleksa Sarai <cyphar@...har.com>, Jann Horn <jannh@...gle.com>,
Alexei Starovoitov <ast@...nel.org>, wad@...omium.org,
bpf@...r.kernel.org, Song Liu <songliubraving@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Andy Lutomirski <luto@...capital.net>,
Linux Containers <containers@...ts.linux-foundation.org>,
Giuseppe Scrivano <gscrivan@...hat.com>,
Robert Sesek <rsesek@...gle.com>
Subject: Re: For review: seccomp_user_notif(2) manual page
Hello Kees,
On 10/1/20 1:39 AM, Kees Cook wrote:
> On Wed, Sep 30, 2020 at 01:07:38PM +0200, Michael Kerrisk (man-pages) wrote:
>> [...] I did :-)
>
> Yay! Thank you!
You're welcome :-)
>> [...]
>> Overview
>> In conventional usage of a seccomp filter, the decision about how
>> to treat a particular system call is made by the filter itself.
>> The user-space notification mechanism allows the handling of the
>> system call to instead be handed off to a user-space process.
>> The advantages of doing this are that, by contrast with the sec‐
>> comp filter, which is running on a virtual machine inside the
>> kernel, the user-space process has access to information that is
>> unavailable to the seccomp filter and it can perform actions that
>> can't be performed from the seccomp filter.
>
> I might clarify a bit with something like (though maybe the
> target/supervisor paragraph needs to be moved to the start):
>
> This is used for performing syscalls on behalf of the target,
> rather than having the supervisor make security policy decisions
> about the syscall, which would be inherently race-prone. The
> target's syscall should either be handled by the supervisor or
> allowed to continue normally in the kernel (where standard security
> policies will be applied).
You, Christian, and Jann all pulled me up on this point. And thanks;
I'm going to use some of your words above. See my reply to Jann, sent
at about the same time as this reply. Please take a look at the text
in my reply to Jann, and let me know what you think.
> I'll comment more later, but I've run out of time today and I didn't see
> anyone mention this detail yet in the existing threads... :)
Later never came :-). But, I hope you may have comments for the
next draft, which I will send out soon.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
Powered by blists - more mailing lists