netdev - [Q] Unable to load SCHED_CLS/SCHED_ACT bpf programs from outside init_user

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-next>] [day] [month] [year] [list]

Date:   Sat, 10 Feb 2018 09:46:17 +0200
From:   Shmulik Ladkani <shmulik@...anetworks.com>
To:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>
Cc:     Chenbo Feng <fengc@...gle.com>, eyal@...anetworks.com,
        netdev@...r.kernel.org, Jamal Hadi Salim <jhs@...atatu.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Jiri Pirko <jiri@...nulli.us>
Subject: [Q] Unable to load SCHED_CLS/SCHED_ACT bpf programs from outside
 init_user_ns

Hi,

Apparently one cannot use TC cls_bpf/act_bpf if running from a user ns
other than the init_user_ns, as bpf_prog_load does not permit loading
these type of progs, snip:

        if (type != BPF_PROG_TYPE_SOCKET_FILTER &&
            type != BPF_PROG_TYPE_CGROUP_SKB &&
            !capable(CAP_SYS_ADMIN))
                return -EPERM;

although the user performing BPF_PROG_LOAD has both CAP_SYS_ADMIN (and
CAP_NET_ADMIN, as required by RTM_NEWTFILTER) in his current_user_ns.

This prevents using tc cls_bpf/act_bpf in containerized software
stacks (where in contrast other tc cls/act are permitted).

The original restiction comes from
    1be7f75d1668 "bpf: enable non-root eBPF programs"
quote:
    tracing and tc cls/act program types still require root permissions,
    since tracing actually needs to be able to see all kernel pointers
    and tc is for root only.

Can the restriction be relaxed, as done for TYPE_SOCKET_FILTER and later
for TYPE_CGROUP_SKB?

Are the SCHED_CLS/SCHED_ACT progs still suspectable of leaking kernel
pointers?
If so, can we restrict only certain operations which are guaranteed not
to leak, so that tc cls_bpf/act_bpf can still be used outside
init_user_ns?

Thanks,
Shmulik