From: Alexei Starovoitov <email@example.com> To: Andy Lutomirski <firstname.lastname@example.org> Cc: Alexei Starovoitov <email@example.com>, Kees Cook <firstname.lastname@example.org>, LSM List <email@example.com>, James Morris <firstname.lastname@example.org>, Jann Horn <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Masami Hiramatsu <email@example.com>, Steven Rostedt <firstname.lastname@example.org>, "David S. Miller" <email@example.com>, Daniel Borkmann <firstname.lastname@example.org>, Network Development <email@example.com>, bpf <firstname.lastname@example.org>, kernel-team <email@example.com>, Linux API <firstname.lastname@example.org> Subject: Re: [PATCH bpf-next] bpf, capabilities: introduce CAP_BPF Date: Wed, 28 Aug 2019 15:55:15 -0700 Message-ID: <email@example.com> (raw) In-Reply-To: <CALCETrW1o+Lazi2Ng6b9JN6jeJffgdW9f3HvqYhNo4TpHRXWfirstname.lastname@example.org> On Tue, Aug 27, 2019 at 11:12:29PM -0700, Andy Lutomirski wrote: > > > > > > > > From the previous discussion, you want to make progress toward solving > > > a lot of problems with CAP_BPF. One of them was making BPF > > > firewalling more generally useful. By making CAP_BPF grant the ability > > > to read kernel memory, you will make administrators much more nervous > > > to grant CAP_BPF. > > > > Andy, were your email hacked? > > I explained several times that in this proposal > > CAP_BPF _and_ CAP_TRACING _both_ are necessary to read kernel memory. > > CAP_BPF alone is _not enough_. > > You have indeed said this many times. You've stated it as a matter of > fact as though it cannot possibly discussed. I'm asking you to > justify it. That's not how I see it. I kept stating that both CAP_BPF and CAP_TRACING are necessary to read kernel memory whereas you kept distorting my statement by dropping second part and then making claims that "CAP_BPF grant the ability to read kernel memory, you will make administrators much more nervous". Just s/CAP_BPF/CAP_BPF and CAP_TRACING/ in this above sentence. See that meaning suddenly changes? Now administrators would be worried about tasks that have both at once. They also would be worried about tasks that have CAP_TRACING alone, because that's what allows probe_kernel_read(). > It seems like you are specifically trying to add a new switch to turn > as much of BPF as possible on and off. Why? Didn't I explain it several times already with multiple examples from systemd, daemons, bpftrace ? Let's try again. Take your laptop with linux distro. You're the only user there. I'm assuming you're not sharing it with partner and kids. This is my definition of 'single user system'. You can sudo on it at any time, but obviously prefer to run as many apps as possible without cap_sys_admin. Now you found some awesome open source app on the web that monitors the health of the kernel and will pop a nice message on a screen if something is wrong. Currently this app needs root. You hesitate, but the apps is so useful and it has strong upstream code review process that you keep running it 24/7. This is open source app. New versions come. You upgrade. You have enough trust in that app that you keep running it as root. But there is always a chance that new version doing accidentaly something stupid as 'kill -9 -1'. It's an open source app at the end. Now I come with this CAP* proposal to make this app safer. I'm not making your system more secure and not making this app more secure. I can only make your laptop safer for day to day work by limiting the operations this app can do. This particular app monitros the kernel via bpf and tracing. Hence you can give it CAP_TRACING and CAP_BPF and drop the rest. > > speaking of MDS... I already asked you to help investigate its > > applicability with existing bpf exposure. Are you going to do that? > > I am blissfully uninvolved in MDS, and I don't know all that much more > about the overall mechanism than a random reader of tech news :) ISTM > there are two meaningful ways that BPF could be involved: a BPF > program could leak info into the state exposed by MDS, or a BPF > program could try to read that state. From what little I understand, > it's essentially inevitable that BPF leaks information into MDS state, > and this is probably even controllable by an attacker that understands > MDS in enough detail. So the interesting questions are: can BPF be > used to read MDS state and can BPF be used to leak information in a > more useful way than the rest of the kernel to an attacker. agree. that's exactly the question to ask. > Keeping in mind that the kernel will flush MDS state on every exit to > usermode, I think the most likely attack is to try to read MDS state > with BPF. This could happen, I suppose -- BPF programs can easily > contain the usual speculation gadgets of "do something and read an > address that depends on the outcome". Fortunately, outside of > bpf_probe_read(), AFAIK BPF programs can't directly touch user memory, > and an attacker that is allowed to use bpf_probe_read() doesn't need > MDS to read things. true as well. So what do we do with that sentence in Documentation/x86/mds.rst? Nothing? New hw bugs will keep coming. All of them should get similar wording? Your understanding of MDS and BPF is way above the average. What other users suppose to do when they read such sentence? I think they have no choice but to do kernel.unprivileged_bpf_disabled=1. We, as a kernel community, are forcing the users into it. Hence I really do not see a value in any proposal today that expands unprivileged bpf usage. Since kernel.unprivileged_bpf_disabled=1 all bpf is under cap_sys_admin. It's not great from security and safety pov. Hence this CAP* proposal. > > Please take a look at Jann's var1 exploit. Was it hard to run bpf prog > > in controlled environment without test_run command ? > > > > Can you send me a link? https://bugs.chromium.org/p/project-zero/issues/detail?id=1272 writeup_files.tar:kernel_leak_exploit_amd_pro_a8_9600_r7/bpf_stuff.c Execution is as trivial as write(sockfd, "X", 1) line 405.
next prev parent reply index Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-27 20:52 Alexei Starovoitov 2019-08-27 23:01 ` Andy Lutomirski 2019-08-27 23:21 ` Steven Rostedt 2019-08-27 23:34 ` Andy Lutomirski 2019-08-28 0:44 ` Steven Rostedt 2019-08-28 1:12 ` Andy Lutomirski 2019-08-28 2:22 ` Steven Rostedt 2019-08-28 0:38 ` Alexei Starovoitov 2019-08-28 3:30 ` Masami Hiramatsu 2019-08-28 4:47 ` Alexei Starovoitov 2019-08-28 0:34 ` Alexei Starovoitov 2019-08-28 0:55 ` Andy Lutomirski 2019-08-28 2:00 ` Andy Lutomirski 2019-08-28 4:49 ` Alexei Starovoitov 2019-08-28 6:20 ` Andy Lutomirski 2019-08-28 23:38 ` Alexei Starovoitov 2019-08-29 0:58 ` Andy Lutomirski 2019-08-28 4:43 ` Alexei Starovoitov 2019-08-28 6:12 ` Andy Lutomirski 2019-08-28 22:55 ` Alexei Starovoitov [this message] 2019-08-29 0:45 ` Andy Lutomirski 2019-08-29 0:53 ` Andy Lutomirski 2019-08-29 4:07 ` Alexei Starovoitov 2019-09-28 23:37 ` Steven Rostedt 2019-09-30 18:31 ` Kees Cook 2019-10-01 1:22 ` Alexei Starovoitov 2019-10-01 22:10 ` Steven Rostedt 2019-10-01 22:18 ` Alexei Starovoitov 2019-10-01 22:47 ` Steven Rostedt 2019-10-02 17:18 ` Alexei Starovoitov 2019-10-02 23:00 ` Steven Rostedt 2019-10-03 16:18 ` trace_printk issue. Was: " Alexei Starovoitov 2019-10-03 16:41 ` Steven Rostedt 2019-10-04 19:56 ` Alexei Starovoitov 2019-10-03 6:12 ` Masami Hiramatsu 2019-10-03 16:20 ` Alexei Starovoitov 2019-08-28 7:14 ` Peter Zijlstra 2019-08-28 22:08 ` Alexei Starovoitov 2019-08-29 13:34 ` Steven Rostedt 2019-08-29 15:43 ` Andy Lutomirski 2019-08-29 17:23 ` Alexei Starovoitov 2019-08-29 17:36 ` Andy Lutomirski 2019-08-29 17:49 ` Steven Rostedt 2019-08-29 17:19 ` Alexei Starovoitov 2019-08-29 17:47 ` Steven Rostedt 2019-08-28 10:38 ` kbuild test robot
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 \ --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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
BPF Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/bpf/0 bpf/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 bpf bpf/ https://lore.kernel.org/bpf \ firstname.lastname@example.org public-inbox-index bpf Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.bpf AGPL code for this site: git clone https://public-inbox.org/public-inbox.git