From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 895A2DA7 for ; Thu, 25 Jul 2019 14:18:52 +0000 (UTC) Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C61597F8 for ; Thu, 25 Jul 2019 14:18:51 +0000 (UTC) Date: Thu, 25 Jul 2019 09:18:49 -0500 From: "Serge E. Hallyn" To: Christian Brauner Message-ID: <20190725141849.GB24945@mail.hallyn.com> References: <20190719093538.dhyopljyr5ns33qx@brauner.io> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: mic@digikod.net, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] seccomp List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sat, Jul 20, 2019 at 09:41:11AM +0200, Christian Brauner wrote: > On July 20, 2019 9:23:33 AM GMT+02:00, James Morris wrote: > >On Fri, 19 Jul 2019, Christian Brauner wrote: > > > >> There is a close connection between 1. and 2. When a watcher > >intercepts > >> a syscall from a watchee and starts to inspect its arguments it can - > >> depending on the syscall rather often actually - determine whether or > >> not the syscall would succeed or fail. If it knows that the syscall > >will > >> succeed it currently still has to perform it in lieu of the watchee > >> since there is no way to tell the kernel to "resume" or actually > >perform > >> the syscall. It would be nice if we could discuss approaches to > >enabling > >> this feature as well. > > > >Landlock is exploring userspace access control via the seccomp > >syscall with ebpf, but from within the same process: > > > >https://landlock.io/ > > > >It may be worth investigating whether Landlock could be extended to a > >split watcher/watchee model. > > Certainly a valid point but... > I don't want to rely on landlock for this. > First, no one knows if and when it will ever land. > Second, seccomp is the go-to sandboxing solution for a lot of userspace already. > Often used without a full LSM. > Third, syscall interception to me is seccomp territory. :) > That's to say I'd like seccomp to have this feature *natively* and ideally not tied to > a complete LSM that needs to be merged for this. :) Sounds all the more like discussion is warranted :)