From: Alexei Starovoitov <email@example.com> To: Andy Lutomirski <firstname.lastname@example.org> Cc: Daniel Borkmann <email@example.com>, Song Liu <firstname.lastname@example.org>, Kees Cook <email@example.com>, Networking <firstname.lastname@example.org>, bpf <email@example.com>, Alexei Starovoitov <firstname.lastname@example.org>, Kernel Team <Kernelemail@example.com>, Lorenz Bauer <firstname.lastname@example.org>, Jann Horn <email@example.com>, Greg KH <firstname.lastname@example.org>, Linux API <email@example.com>, LSM List <firstname.lastname@example.org>, Chenbo Feng <email@example.com> Subject: Re: RFC: very rough draft of a bpf permission model Date: Mon, 26 Aug 2019 15:36:00 -0700 Message-ID: <20190826223558.6torq6keplniif6w@ast-mbp> (raw) In-Reply-To: <CALCETrUhXrZaJy8omX_DsH0rAY98YEqR64VuisQSz2Rru8Dqpg@mail.gmail.com> On Fri, Aug 23, 2019 at 04:09:11PM -0700, Andy Lutomirski wrote: > On Thu, Aug 22, 2019 at 4:26 PM Alexei Starovoitov > <firstname.lastname@example.org> wrote: > > You're proposing all of the above in addition to CAP_BPF, right? > > Otherwise I don't see how it addresses the use cases I kept > > explaining for the last few weeks. > > None of my proposal is intended to exclude changes like CAP_BPF to > make privileged bpf() operations need less privilege. But I think > it's very hard to evaluate CAP_BPF without both a full description of > exactly what CAP_BPF would do and what at least one full example of a > user would look like. the example is previous email and systemd example was not "full" ? > I also think that users who want CAP_BPF should look at manipulating > their effective capability set instead. A daemon that wants to use > bpf() but otherwise minimize the chance of accidentally causing a > problem can use capset() to clear its effective and inheritable masks. > Then, each time it wants to call bpf(), it could re-add CAP_SYS_ADMIN > or CAP_NET_ADMIN to its effective set, call bpf(), and then clear its > effective set again. This works in current kernels and is generally > good practice. Such logic means that CAP_NET_ADMIN is not necessary either. The process could re-add CAP_SYS_ADMIN when it needs to reconfigure network and then drop it. > Aside from this, and depending on exactly what CAP_BPF would be, I > have some further concerns. Looking at your example in this email: > > > Here is another example of use case that CAP_BPF is solving: > > The daemon X is started by pid=1 and currently runs as root. > > It loads a bunch of tracing progs and attaches them to kprobes > > and tracepoints. It also loads cgroup-bpf progs and attaches them > > to cgroups. All progs are collecting data about the system and > > logging it for further analysis. > > This needs more than just bpf(). Creating a perf kprobe event > requires CAP_SYS_ADMIN, and without a perf kprobe event, you can't > attach a bpf program. that is already solved sysctl_perf_event_paranoid. CAP_BPF is about BPF part only. > And the privilege to attach bpf programs to > cgroups without any DAC or MAC checks (which is what the current API > does) is an extremely broad privilege that is not that much weaker > than CAP_SYS_ADMIN or CAP_NET_ADMIN. Also: I don't think there is a hierarchy of CAP_SYS_ADMIN vs CAP_NET_ADMIN vs CAP_BPF. CAP_BPF and CAP_NET_ADMIN carve different areas of CAP_SYS_ADMIN. Just like all other caps. > > This tracing bpf is looking into kernel memory > > and using bpf_probe_read. Clearly it's not _secure_. But it's _safe_. > > The system is not going to crash because of BPF, > > but it can easily crash because of simple coding bugs in the user > > space bits of that daemon. > > The BPF verifier and interpreter, taken in isolation, may be extremely > safe, but attaching BPF programs to various hooks can easily take down > the system, deliberately or by accident. A handler, especially if it > can access user memory or otherwise fault, will explode if attached to > an inappropriate kprobe, hw_breakpoint, or function entry trace event. absolutely not true. > (I and the other maintainers consider this to be a bug if it happens, > and we'll fix it, but these bugs definitely exist.) A cgroup-bpf hook > that blocks all network traffic will effectively kill a machine, > especially if it's a server. this permission is granted by CAP_NET_ADMIN. Nothing changes here. > A bpf program that runs excessively > slowly attached to a high-frequency hook will kill the system, too. not true either. > (I bet a buggy bpf program that calls bpf_probe_read() on an unmapped > address repeatedly could be make extremely slow. Page faults take > thousands to tens of thousands of cycles.) kprobe probing and faulting on non-existent address will do the same 'damage'. So it's not bpf related. Also it won't make the system "extremely slow". Nothing to do with CAP_BPF. > A bpf firewall rule that's > wrong can cut a machine off from the network -- I've killed machines > using iptables more than once, and bpf isn't magically safer. this is CAP_NET_ADMIN permission. It's a different capability. > > I'm wondering if something like CAP_TRACING would make sense. > CAP_TRACING would allow operations that can reveal kernel memory and > other secret kernel state but that do not, by design, allow modifying > system behavior. So, for example, CAP_TRACING would allow privileged > perf_event_open() operations and privileged bpf verifier usage. But > it would not allow cgroup-bpf unless further restrictions were added, > and it would not allow the *_BY_ID operations, as those can modify > other users' bpf programs' behavior. Makes little sense to me. I can imagine CAP_TRACING controlling kprobe/uprobe creation and probe_read() both from bpf side and from vanilla kprobe. That would be much nicer interface to use than existing sysctl_perf_event_paranoid, but that is orthogonal to CAP_BPF which is strictly about BPF. > Something finer-grained can mitigate some of this. CAP_BPF as I think > you're imagining it will not. I'm afraid this discussion goes nowhere. We'll post CAP_BPF patches soon so we can discuss code.
next prev parent reply index Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <email@example.com> [not found] ` <firstname.lastname@example.org> [not found] ` <email@example.com> [not found] ` <3C595328-3ABE-4421-9772-8D41094A4F57@fb.com> [not found] ` <CALCETrWBnH4Q43POU8cQ7YMjb9LioK28FDEQf7aHZbdf1eBZWg@mail.gmail.com> [not found] ` <0DE7F23E-9CD2-4F03-82B5-835506B59056@fb.com> [not found] ` <CALCETrWBWbNFJvsTCeUchu3BZJ3SH3dvtXLUB2EhnPrzFfsLNA@mail.gmail.com> [not found] ` <201907021115.DCD56BBABB@keescook> [not found] ` <CALCETrXTta26CTtEDnzvtd03-WOGdXcnsAogP8JjLkcj4-mHvg@mail.gmail.com> [not found] ` <4A7A225A-6C23-4C0F-9A95-7C6C56B281ED@fb.com> [not found] ` <CALCETrX2bMnwC6_t4b_G-hzJSfMPrkK4YKs5ebcecv2LJ0rt3w@mail.gmail.com> [not found] ` <514D5453-0AEE-420F-AEB6-3F4F58C62E7E@fb.com> [not found] ` <1DE886F3-3982-45DE-B545-67AD6A4871AB@amacapital.net> [not found] ` <7F51F8B8-CF4C-4D82-AAE1-F0F28951DB7F@fb.com> [not found] ` <77354A95-4107-41A7-8936-D144F01C3CA4@fb.com> [not found] ` <369476A8-4CE1-43DA-9239-06437C0384C7@fb.com> 2019-07-30 20:24 ` [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Andy Lutomirski 2019-07-31 8:10 ` Song Liu 2019-07-31 19:09 ` Andy Lutomirski 2019-08-02 7:21 ` Song Liu 2019-08-04 22:16 ` Andy Lutomirski 2019-08-05 0:08 ` Andy Lutomirski 2019-08-05 5:47 ` Andy Lutomirski 2019-08-05 7:36 ` Song Liu 2019-08-05 17:23 ` Andy Lutomirski 2019-08-05 19:21 ` Alexei Starovoitov 2019-08-05 21:25 ` Andy Lutomirski 2019-08-05 22:21 ` Andy Lutomirski 2019-08-06 1:11 ` Alexei Starovoitov 2019-08-07 5:24 ` Andy Lutomirski 2019-08-07 9:03 ` Lorenz Bauer 2019-08-07 13:52 ` Andy Lutomirski 2019-08-13 21:58 ` Alexei Starovoitov 2019-08-13 22:26 ` Daniel Colascione 2019-08-13 23:24 ` Andy Lutomirski 2019-08-13 23:06 ` Andy Lutomirski 2019-08-14 0:57 ` Alexei Starovoitov 2019-08-14 17:51 ` Andy Lutomirski 2019-08-14 22:05 ` Alexei Starovoitov 2019-08-14 22:30 ` Andy Lutomirski 2019-08-14 23:33 ` Alexei Starovoitov 2019-08-14 23:59 ` Andy Lutomirski 2019-08-15 0:36 ` Alexei Starovoitov 2019-08-15 11:24 ` Jordan Glover 2019-08-15 17:28 ` Alexei Starovoitov 2019-08-15 18:36 ` Andy Lutomirski 2019-08-15 23:08 ` Alexei Starovoitov 2019-08-16 9:34 ` Jordan Glover 2019-08-16 9:59 ` Thomas Gleixner 2019-08-16 11:33 ` Jordan Glover 2019-08-16 19:52 ` Alexei Starovoitov 2019-08-16 20:28 ` Thomas Gleixner 2019-08-17 15:02 ` Alexei Starovoitov 2019-08-17 15:44 ` Andy Lutomirski 2019-08-19 9:15 ` Thomas Gleixner 2019-08-19 17:27 ` Alexei Starovoitov 2019-08-19 17:38 ` Andy Lutomirski 2019-08-15 18:43 ` Jordan Glover 2019-08-15 19:46 ` Kees Cook 2019-08-15 23:46 ` Alexei Starovoitov 2019-08-16 0:54 ` Andy Lutomirski 2019-08-16 5:56 ` Song Liu 2019-08-16 21:45 ` Alexei Starovoitov 2019-08-16 22:22 ` Christian Brauner 2019-08-17 15:08 ` Alexei Starovoitov 2019-08-17 15:16 ` Christian Brauner 2019-08-17 15:36 ` Alexei Starovoitov 2019-08-17 15:42 ` Christian Brauner 2019-08-22 14:17 ` Daniel Borkmann 2019-08-22 15:16 ` Andy Lutomirski 2019-08-22 15:17 ` RFC: very rough draft of a bpf permission model Andy Lutomirski 2019-08-22 23:26 ` Alexei Starovoitov 2019-08-23 23:09 ` Andy Lutomirski 2019-08-26 22:36 ` Alexei Starovoitov [this message] 2019-08-27 0:05 ` Andy Lutomirski 2019-08-27 0:34 ` Alexei Starovoitov 2019-08-22 22:48 ` [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Alexei Starovoitov
Reply instructions: You may reply publically 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=20190826223558.6torq6keplniif6w@ast-mbp \ --firstname.lastname@example.org \ --cc=Kernelemail@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Linux-Security-Module Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \ email@example.com public-inbox-index linux-security-module Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module AGPL code for this site: git clone https://public-inbox.org/public-inbox.git