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/
