From: Andy Lutomirski <firstname.lastname@example.org> To: Alexei Starovoitov <email@example.com> Cc: Thomas Gleixner <firstname.lastname@example.org>, Jordan Glover <Golden_Miller83@protonmail.ch>, Andy Lutomirski <email@example.com>, Daniel Colascione <firstname.lastname@example.org>, Song Liu <email@example.com>, Kees Cook <firstname.lastname@example.org>, Networking <email@example.com>, bpf <firstname.lastname@example.org>, Alexei Starovoitov <email@example.com>, Daniel Borkmann <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> Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Date: Mon, 19 Aug 2019 10:38:56 -0700 Message-ID: <CA2D2573-D90D-4904-A8B5-08C9C5FC7A56@amacapital.net> (raw) In-Reply-To: <email@example.com> > On Aug 19, 2019, at 10:27 AM, Alexei Starovoitov <firstname.lastname@example.org> wrote: > >> On Mon, Aug 19, 2019 at 11:15:11AM +0200, Thomas Gleixner wrote: >> Alexei, >> >>> On Sat, 17 Aug 2019, Alexei Starovoitov wrote: >>>> On Fri, Aug 16, 2019 at 10:28:29PM +0200, Thomas Gleixner wrote: >>>> On Fri, 16 Aug 2019, Alexei Starovoitov wrote: >>>> While real usecases are helpful to understand a design decision, the design >>>> needs to be usecase independent. >>>> >>>> The kernel provides mechanisms, not policies. My impression of this whole >>>> discussion is that it is policy driven. That's the wrong approach. >>> >>> not sure what you mean by 'policy driven'. >>> Proposed CAP_BPF is a policy? >> >> I was referring to the discussion as a whole. >> >>> Can kernel.unprivileged_bpf_disabled=1 be used now? >>> Yes, but it will weaken overall system security because things that >>> use unpriv to load bpf and CAP_NET_ADMIN to attach bpf would need >>> to move to stronger CAP_SYS_ADMIN. >>> >>> With CAP_BPF both load and attach would happen under CAP_BPF >>> instead of CAP_SYS_ADMIN. >> >> I'm not arguing against that. >> >>>> So let's look at the mechanisms which we have at hand: >>>> >>>> 1) Capabilities >>>> >>>> 2) SUID and dropping priviledges >>>> >>>> 3) Seccomp and LSM >>>> >>>> Now the real interesting questions are: >>>> >>>> A) What kind of restrictions does BPF allow? Is it a binary on/off or is >>>> there a more finegrained control of BPF functionality? >>>> >>>> TBH, I can't tell. >>>> >>>> B) Depending on the answer to #A what is the control possibility for >>>> #1/#2/#3 ? >>> >>> Can any of the mechanisms 1/2/3 address the concern in mds.rst? >> >> Well, that depends. As with any other security policy which is implemented >> via these mechanisms, the policy can be strict enough to prevent it by not >> allowing certain operations. The more fine-grained the control is, it >> allows the administrator who implements the policy to remove the >> 'dangerous' parts from an untrusted user. >> >> So really question #A is important for this. Is BPF just providing a binary >> ON/OFF knob or does it allow to disable/enable certain aspects of BPF >> functionality in a more fine grained way? If the latter, then it might be >> possible to control functionality which might be abused for exploits of >> some sorts (including MDS) in a way which allows other parts of BBF to be >> exposed to less priviledged contexts. > > I see. So the kernel.unprivileged_bpf_disabled knob is binary and I think it's > the right mechanism to expose to users. > Having N knobs for every map/prog type won't decrease attack surface. > In the other email Andy's quoting seccomp man page... > Today seccomp cannot really look into bpf_attr syscall args, but even > if it could it won't secure the system. > Examples: > 1. > spectre v2 is using bpf in-kernel interpreter in speculative way. > The mere presence of interpreter as part of kernel .text makes the exploit > easier to do. That was the reason to do CONFIG_BPF_JIT_ALWAYS_ON. > For this case even kernel.unprivileged_bpf_disabled=1 was hopeless. > > 2. > var4 doing store hazard. It doesn't matter which program type is used. > load/store instructions are the same across program types. > > 3. > prog_array was used as part of var1. I guess it was simply more > convenient for Jann to do it this way :) All other map types > have the same out-of-bounds speculation issue. > > In general side channels are cpu bugs that are exploited via sequences > of cpu instructions. In that sense bpf infra provides these instructions. > So all program types and all maps have the same level of 'side channel risk'. > >>> I believe Andy wants to expand the attack surface when >>> kernel.unprivileged_bpf_disabled=0 >>> Before that happens I'd like the community to work on addressing the text above. >> >> Well, that text above can be removed when the BPF wizards are entirely sure >> that BPF cannot be abused to exploit stuff. > > Myself and Daniel looked at it in detail. I think we understood > MDS mechanism well enough. Right now we're fairly confident that > combination of existing mechanisms we did for var4 and > verifier speculative analysis protect us from MDS. > The thing is that every new cpu bug is looked at through the bpf lenses. > Can it be exploited through bpf? Complexity of side channels > is growing. Can the most recent swapgs be exploited ? > What if we kprobe+bpf somewhere ? > I don't think there is an issue, but we will never be 'entirely sure'. > Even if myself and Daniel are sure the concern will stay. > Unprivileged bpf as a whole is the concern due to side channels. > The number of them are not yet disclosed. Who is going to analyze them? > imo the only answer to that is kernel.unprivileged_bpf_disabled=1 > which together with CONFIG_BPF_JIT_ALWAYS_ON is secure enough. > The other option is to sprinkle every bpf load/store with lfence > which will make execution so slow that it will be unusable. > Which is effectively the same as unprivileged_bpf_disabled=1. > > There are other things we can do. Like kasan-style shadow memory > for bpf execution. Auto re-JITing the code after it's running. > We can do lfences everywhere for some time then re-JIT > when kasan-ed shadow memory shows only clean memory accesses. > The beauty of BPF that it is analyze-able and JIT-able instruction set. > The verifier speculative analysis is an example that the kernel > can analyze the speculative execution path that cpu will > take before the code starts executing. > Unprivileged bpf can made absolutely secure. It can be > made more secure than the rest of the kernel. > But today we should just go with unprivileged_bpf_disabled=1 I’m still okay with this. > and CAP_BPF. > I think this needs more design work. I’m halfway through writing up an actual proposal. I’ll send it soon.
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 ` 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 [this message] 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 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=CA2D2573-D90D-4904-A8B5-08C9C5FC7A56@amacapital.net \ --firstname.lastname@example.org \ --cc=Golden_Miller83@protonmail.ch \ --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 \ --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 firstname.lastname@example.org public-inbox-index linux-security-module 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