Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1470752

Re: [RFC v2 09/10] landlock: Handle cgroups

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: [RFC v2 09/10] landlock: Handle cgroups
Date 2016-08-26 16:30 +0200
Message-ID <saqiS-8az-31@gated-at.bofh.it> (permalink)
References <sa0op-8hT-3@gated-at.bofh.it> <sa0op-8hT-1@gated-at.bofh.it> <sa0Rr-fC-5@gated-at.bofh.it> <sa48G-2d0-7@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, Aug 25, 2016 at 7:44 AM, Mickaël Salaün <mic@digikod.net> wrote:
>
> On 25/08/2016 13:09, Andy Lutomirski wrote:
>> On Thu, Aug 25, 2016 at 3:32 AM, Mickaël Salaün <mic@digikod.net> wrote:
>>> Add an eBPF function bpf_landlock_cmp_cgroup_beneath(opt, map, map_op)
>>> to compare the current process cgroup with a cgroup handle, The handle
>>> can match the current cgroup if it is the same or a child. This allows
>>> to make conditional rules according to the current cgroup.
>>>
>>> A cgroup handle is a map entry created from a file descriptor referring
>>> a cgroup directory (e.g. by opening /sys/fs/cgroup/X). In this case, the
>>> map entry is of type BPF_MAP_HANDLE_TYPE_LANDLOCK_CGROUP_FD and the
>>> inferred array map is of type BPF_MAP_ARRAY_TYPE_LANDLOCK_CGROUP.
>>
>> Can you elaborate on why this is useful?  I.e. why not just supply
>> different policies to different subtrees.
>
> The main use case I see is to load the security policies at the start of
> a user session for all processes but not enforce them right away. The
> user can then keep a shell for Landlock administration tasks and lock
> the other processes with a dedicated cgroup on the fly. This allows the
> user to make unremovable Landlock security policies but only activate
> them when needed for specific processes.

This seems like a bit of a dubious use case to me.  The landlock
mechanism should be flexible enough to do this kind of thing even
without cgroups, and "spawn a process, wait a while, and then confine
it by fiddling with cgroups" seems a lot dicier than just loading the
right policy in the first place, especially since eBPF policies can be
stateful.

>
>>
>> Also, how does this interact with the current cgroup v1 vs v2 mess?
>> As far as I can tell, no one can even really agree on what "what
>> cgroup am I in" means right now.
>
> I tested with cgroup-v2 but indeed, it seems a bit different with
> cgroup-v1 :)
> Does anyone know how to handle both cases?
>
>>
>>>
>>> An unprivileged process can create and manipulate cgroups thanks to
>>> cgroup delegation.
>>
>> What is cgroup delegation?
>
> This is simply the action of changing the owner of cgroup sysfs files to
> allow an unprivileged user to handle them (cf. Documentation/cgroup-v2.txt)

As far as I can tell, Tejun and systemd both actively discourage doing
this.  Maybe I misunderstand.  But in any event, the admin giving you
a cgroup hierarchy you can use for this means that the admin has to
cooperate with your policy, and it further requires (with cgroup v2 or
similar, which is most likely the future) that your lockdown policy be
compatible with your resource control policy.

I would suggest dropping this lockdown feature until a use case
emerges that really can't be addressed adequately without it.

--Andy

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC v2 09/10] landlock: Handle cgroups Mickaël Salaün <mic@digikod.net> - 2016-08-25 12:50 +0200
  Re: [RFC v2 09/10] landlock: Handle cgroups Andy Lutomirski <luto@amacapital.net> - 2016-08-25 13:20 +0200
    Re: [RFC v2 09/10] landlock: Handle cgroups Mickaël Salaün <mic@digikod.net> - 2016-08-25 16:50 +0200
      Re: [RFC v2 09/10] landlock: Handle cgroups Tejun Heo <tj@kernel.org> - 2016-08-26 15:00 +0200
      Re: [RFC v2 09/10] landlock: Handle cgroups Andy Lutomirski <luto@amacapital.net> - 2016-08-26 16:30 +0200
        Re: [RFC v2 09/10] landlock: Handle cgroups Tejun Heo <tj@kernel.org> - 2016-08-26 18:00 +0200
  Re: [RFC v2 09/10] landlock: Handle cgroups Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-26 04:30 +0200
    Re: [RFC v2 09/10] landlock: Handle cgroups Mickaël Salaün <mic@digikod.net> - 2016-08-26 17:20 +0200
      Re: [RFC v2 09/10] landlock: Handle cgroups Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 01:10 +0200
        Re: [RFC v2 09/10] landlock: Handle cgroups Andy Lutomirski <luto@amacapital.net> - 2016-08-27 09:40 +0200
          Re: [RFC v2 09/10] landlock: Handle cgroups Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 20:20 +0200
            Re: [RFC v2 09/10] landlock: Handle cgroups Andy Lutomirski <luto@amacapital.net> - 2016-08-28 10:20 +0200
        Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün <mic@digikod.net> - 2016-08-27 16:20 +0200
          Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 20:10 +0200
            Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün <mic@digikod.net> - 2016-08-27 21:40 +0200
              Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 22:50 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün <mic@digikod.net> - 2016-08-27 23:20 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Andy Lutomirski <luto@amacapital.net> - 2016-08-28 10:20 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün <mic@digikod.net> - 2016-08-28 11:50 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Andy Lutomirski <luto@amacapital.net> - 2016-08-30 21:00 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün <mic@digikod.net> - 2016-08-30 22:30 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Andy Lutomirski <luto@amacapital.net> - 2016-08-30 22:30 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Mickaël Salaün <mic@digikod.net> - 2016-08-30 22:40 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-30 23:00 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Andy Lutomirski <luto@amacapital.net> - 2016-08-30 23:50 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-31 03:40 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (performance) Andy Lutomirski <luto@amacapital.net> - 2016-08-31 05:30 +0200
        Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match) Mickaël Salaün <mic@digikod.net> - 2016-08-27 16:30 +0200
          Re: [RFC v2 09/10] landlock: Handle cgroups (netfilter match) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 20:40 +0200
        Re: [RFC v2 09/10] landlock: Handle cgroups (program types) Mickaël Salaün <mic@digikod.net> - 2016-08-27 16:40 +0200
          Re: [RFC v2 09/10] landlock: Handle cgroups (program types) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 20:30 +0200
            Re: [RFC v2 09/10] landlock: Handle cgroups (program types) Mickaël Salaün <mic@digikod.net> - 2016-08-27 22:00 +0200
              Re: [RFC v2 09/10] landlock: Handle cgroups (program types) Alexei Starovoitov <alexei.starovoitov@gmail.com> - 2016-08-27 23:00 +0200
                Re: [RFC v2 09/10] landlock: Handle cgroups (program types) Mickaël Salaün <mic@digikod.net> - 2016-08-27 23:20 +0200

csiph-web