From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: "LSM List" <linux-security-module@vger.kernel.org>,
"Network Development" <netdev@vger.kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Linux API" <linux-api@vger.kernel.org>,
"Sargun Dhillon" <sargun@sargun.me>, "Tejun Heo" <tj@kernel.org>,
"Kees Cook" <keescook@chromium.org>,
"David S . Miller" <davem@davemloft.net>,
"open list:CONTROL GROUP (CGROUP)" <cgroups@vger.kernel.org>,
"Mickaël Salaün" <mic@digikod.net>,
"Daniel Mack" <daniel@zonque.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
"Daniel Borkmann" <daniel@iogearbox.net>
Subject: Re: [RFC v2 09/10] landlock: Handle cgroups (performance)
Date: Tue, 30 Aug 2016 18:36:06 -0700 [thread overview]
Message-ID: <20160831013605.GB75654@ast-mbp.thefacebook.com> (raw)
In-Reply-To: <CALCETrX6hPFZwdnypkPA0p9VjdcK=ZFYpR8zXpzOYS6f=fx3_g@mail.gmail.com>
On Tue, Aug 30, 2016 at 02:45:14PM -0700, Andy Lutomirski wrote:
>
> One might argue that landlock shouldn't be tied to seccomp (in theory,
> attached progs could be given access to syscall_get_xyz()), but I
proposed lsm is way more powerful than syscall_get_xyz.
no need to dumb it down.
> think that the seccomp attachment mechanism is the right way to
> install unprivileged filters. It handles the no_new_privs stuff, it
> allows TSYNC, it's totally independent of systemwide policy, etc.
>
> Trying to use cgroups or similar for this is going to be much nastier.
> Some tighter sandboxes (Sandstorm, etc) aren't even going to dream of
> putting cgroupfs in their containers, so requiring cgroups or similar
> would be a mess for that type of application.
I don't see why it is a 'mess'. cgroups are already used by majority
of the systems, so I don't see why requiring a cgroup is such a big deal.
But let's say we don't do them. How implementation is going to look like
for task based hierarchy? Note that we need an array of bpf_prog pointers.
One for each lsm hook. Where this array is going to be stored?
We cannot put in task_struct, since it's too large. Cannot put it
into 'struct seccomp' directly either, unless it will become a pointer.
Is that the proposal?
So now we will be wasting extra 1kbyte of memory per task. Not great.
We'd want to optimize it by sharing this such struct seccomp with prog array
across threads of the same task? Or dynimically allocating it when
landlock is in use? May sound nice, but how to account for that kernel
memory? I guess also solvable by charging memlock.
With cgroup based approach we don't need to worry about all that.
next prev parent reply other threads:[~2016-08-31 1:36 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-25 10:32 [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 01/10] landlock: Add Kconfig Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 02/10] bpf: Move u64_to_ptr() to BPF headers and inline it Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 03/10] bpf,landlock: Add a new arraymap type to deal with (Landlock) handles Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 04/10] seccomp: Split put_seccomp_filter() with put_seccomp() Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 05/10] seccomp: Handle Landlock Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 06/10] landlock: Add LSM hooks Mickaël Salaün
2016-08-30 18:56 ` Andy Lutomirski
2016-08-30 20:10 ` Mickaël Salaün
2016-08-30 20:18 ` Andy Lutomirski
2016-08-30 20:27 ` Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 07/10] landlock: Add errno check Mickaël Salaün
2016-08-25 11:13 ` Andy Lutomirski
2016-08-25 10:32 ` [RFC v2 08/10] landlock: Handle file system comparisons Mickaël Salaün
2016-08-25 11:12 ` Andy Lutomirski
2016-08-25 14:10 ` Mickaël Salaün
2016-08-26 14:57 ` Andy Lutomirski
2016-08-27 13:45 ` Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 09/10] landlock: Handle cgroups Mickaël Salaün
2016-08-25 11:09 ` Andy Lutomirski
2016-08-25 14:44 ` Mickaël Salaün
2016-08-26 12:55 ` Tejun Heo
2016-08-26 14:20 ` Andy Lutomirski
2016-08-26 15:50 ` Tejun Heo
2016-08-26 2:14 ` Alexei Starovoitov
2016-08-26 15:10 ` Mickaël Salaün
2016-08-26 23:05 ` Alexei Starovoitov
2016-08-27 7:30 ` Andy Lutomirski
2016-08-27 18:11 ` Alexei Starovoitov
2016-08-28 8:14 ` Andy Lutomirski
2016-08-27 14:06 ` [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün
2016-08-27 18:06 ` Alexei Starovoitov
2016-08-27 19:35 ` Mickaël Salaün
2016-08-27 20:43 ` Alexei Starovoitov
2016-08-27 21:14 ` Mickaël Salaün
2016-08-28 8:13 ` Andy Lutomirski
2016-08-28 9:42 ` Mickaël Salaün
2016-08-30 18:55 ` Andy Lutomirski
2016-08-30 20:20 ` Mickaël Salaün
2016-08-30 20:23 ` Andy Lutomirski
2016-08-30 20:33 ` Mickaël Salaün
2016-08-30 20:55 ` Alexei Starovoitov
2016-08-30 21:45 ` Andy Lutomirski
2016-08-31 1:36 ` Alexei Starovoitov [this message]
2016-08-31 3:29 ` Andy Lutomirski
2016-08-27 14:19 ` [RFC v2 09/10] landlock: Handle cgroups (netfilter match) Mickaël Salaün
2016-08-27 18:32 ` Alexei Starovoitov
2016-08-27 14:34 ` [RFC v2 09/10] landlock: Handle cgroups (program types) Mickaël Salaün
2016-08-27 18:19 ` Alexei Starovoitov
2016-08-27 19:55 ` Mickaël Salaün
2016-08-27 20:56 ` Alexei Starovoitov
2016-08-27 21:18 ` Mickaël Salaün
2016-08-25 10:32 ` [RFC v2 10/10] samples/landlock: Add sandbox example Mickaël Salaün
2016-08-25 11:05 ` [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing Andy Lutomirski
2016-08-25 13:57 ` Mickaël Salaün
2016-08-27 7:40 ` Andy Lutomirski
2016-08-27 15:10 ` Mickaël Salaün
2016-08-27 15:21 ` [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing (cgroup delegation) Mickaël Salaün
2016-08-30 16:06 ` [RFC v2 00/10] Landlock LSM: Unprivileged sandboxing Andy Lutomirski
2016-08-30 19:51 ` Mickaël Salaün
2016-08-30 19:55 ` Andy Lutomirski
2016-09-15 9:19 ` Pavel Machek
2016-09-20 17:08 ` Mickaël Salaün
2016-09-24 7:45 ` Pavel Machek
2016-10-03 22:56 ` Kees Cook
2016-10-05 20:30 ` Mickaël Salaün
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160831013605.GB75654@ast-mbp.thefacebook.com \
--to=alexei.starovoitov@gmail.com \
--cc=ast@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=daniel@zonque.org \
--cc=davem@davemloft.net \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mic@digikod.net \
--cc=netdev@vger.kernel.org \
--cc=sargun@sargun.me \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).