netdev - Re: [PATCH v3 bpf-next 00/21] bpf: Sysctl hook

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 9 Apr 2019 23:17:31 +0000
From:   Andrey Ignatov <rdna@...com>
To:     Kees Cook <keescook@...omium.org>
CC:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "Daniel Borkmann" <daniel@...earbox.net>,
        Roman Gushchin <guro@...com>, Kernel Team <Kernel-team@...com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Alexey Dobriyan <adobriyan@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        Jann Horn <jannh@...gle.com>
Subject: Re: [PATCH v3 bpf-next 00/21] bpf: Sysctl hook

Kees Cook <keescook@...omium.org> [Tue, 2019-04-09 09:51 -0700]:
> On Sat, Apr 6, 2019 at 10:03 AM Alexei Starovoitov
> <alexei.starovoitov@...il.com> wrote:
> >
> > On Sat, Apr 06, 2019 at 09:43:50AM -0700, Kees Cook wrote:
> > > On Fri, Apr 5, 2019 at 12:36 PM Andrey Ignatov <rdna@...com> wrote:
> > > Can the BPF be removed (or rather,
> > > what's the lifetime of such BPF?)
> >
> > same as all other cgroup-bpf hooks.
> > Do you have a specific concern or just asking how life time of programs
> > is managed?
> > High level description of lifetime is here:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__facebookmicrosites.github.io_bpf_blog_2018_08_31_object-2Dlifetime.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=3jAokpHyGuCuJ834j-tttQ&m=ZJJ4QMXnksL1b4VPoBM0NJ0i6OWysGc2Om26pcoJpxA&s=6dIZ788hOzoDWVif5XQ-9Mqf9ijko9O7TOWArLzblxU&e=
> 
> I'm mostly curious about the access control stacking. i.e. can
> in-container root add new eBPF to its own cgroup, and if so, can it
> undo the restrictions already present? (I assume it can't, but figured
> I'd ask...)

Since I answered similar question from Jann below, I'll answer it here
as well (even though it was addressed to Alexei).

Stacking can be controlled by attach flags (NONE, BPF_F_ALLOW_OVERRIDE,
BPF_F_ALLOW_MULTI) described in include/uapi/linux/bpf.h.

Basically if one attaches a program to a cgroup with
`bpf_attr.attach_flags = 0` (0 is "NONE"), then nobody can override it
by their own programs of same type in any sub-cgroup. It can be hardened
further by cgroup namespace so that in-container root doesn't even see
part of cgroup hierarchy where cgroup-bpf program is attached to with
attach flags NONE.


-- 
Andrey Ignatov