[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6bb12d3a-5613-2891-83af-43e3176481dc@digikod.net>
Date: Tue, 31 Dec 2019 13:11:51 +0100
From: Mickaël Salaün <mic@...ikod.net>
To: Kees Cook <keescook@...omium.org>
Cc: KP Singh <kpsingh@...omium.org>, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, linux-security-module@...r.kernel.org,
Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
James Morris <jmorris@...ei.org>,
Thomas Garnier <thgarnie@...omium.org>,
Michael Halcrow <mhalcrow@...gle.com>,
Paul Turner <pjt@...gle.com>,
Brendan Gregg <brendan.d.gregg@...il.com>,
Jann Horn <jannh@...gle.com>,
Matthew Garrett <mjg59@...gle.com>,
Christian Brauner <christian@...uner.io>,
Florent Revest <revest@...omium.org>,
Brendan Jackman <jackmanb@...omium.org>,
Martin KaFai Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
"Serge E. Hallyn" <serge@...lyn.com>,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
"David S. Miller" <davem@...emloft.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Stanislav Fomichev <sdf@...gle.com>,
Quentin Monnet <quentin.monnet@...ronome.com>,
Andrey Ignatov <rdna@...com>, Joe Stringer <joe@...d.net.nz>,
Mickaël Salaün <mickael.salaun@....gouv.fr>
Subject: Re: [PATCH bpf-next v1 00/13] MAC and Audit policy using eBPF (KRSI)
On 30/12/2019 20:30, Kees Cook wrote:
> On Fri, Dec 20, 2019 at 11:46:47PM +0100, Mickaël Salaün wrote:
>> I'm working on a version of Landlock without eBPF, but still with the
>> initial sought properties: safe unprivileged composability, modularity, and
>> dynamic update. I'll send this version soon.
>>
>> I hope that the work and experience from Landlock to bring eBPF to LSM will
>> continue to be used through KRSI. Landlock will now focus on the
>> unprivileged sandboxing part, without eBPF. Stay tuned!
>
> Will it end up looking at all like pledge? I'm still struggling to come
> up with a sensible pledge-like design on top of seccomp, especially
> given the need to have it very closely tied to the running libc...
>
Yes, it's similar to Pledge/Unveil but with fine-grained control (and a
more flexible design). And because it is not tied to syscall, there is
no similar issues than with seccomp and libc. In fact, there is no more
relationship with seccomp neither. The version I'm working on is similar
in principle to the patch series v10 [1], without the usage complexity
brought by eBPF, but with a more polished file-based access-control. The
demo from LSS 2018 [2] gives an overview of the possibilities.
[1] https://lore.kernel.org/lkml/20190721213116.23476-1-mic@digikod.net/
[2] https://landlock.io/talks/2018-08-27_landlock-lss_demo-1-web.mkv
Powered by blists - more mailing lists