From: Thomas Gleixner <tglx@linutronix.de> To: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: Jordan Glover <Golden_Miller83@protonmail.ch>, Andy Lutomirski <luto@kernel.org>, Daniel Colascione <dancol@google.com>, Song Liu <songliubraving@fb.com>, Kees Cook <keescook@chromium.org>, Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>, Alexei Starovoitov <ast@kernel.org>, Daniel Borkmann <daniel@iogearbox.net>, Kernel Team <Kernel-team@fb.com>, Lorenz Bauer <lmb@cloudflare.com>, Jann Horn <jannh@google.com>, Greg KH <gregkh@linuxfoundation.org>, Linux API <linux-api@vger.kernel.org>, LSM List <linux-security-module@vger.kernel.org> Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Date: Fri, 16 Aug 2019 22:28:29 +0200 (CEST) Message-ID: <alpine.DEB.2.21.1908162211270.1923@nanos.tec.linutronix.de> (raw) In-Reply-To: <20190816195233.vzqqbqrivnooohq6@ast-mbp.dhcp.thefacebook.com> Alexei, On Fri, 16 Aug 2019, Alexei Starovoitov wrote: > It's both of the above when 'systemd' is not taken literally. > To earlier Thomas's point: the use case is not only about systemd. > There are other containers management systems. <SNIP> > These daemons need to drop privileges to make the system safer == less > prone to corruption due to bugs in themselves. Not necessary security > bugs. Let's take a step back. 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. 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 ? Answering those questions gives us a real scope of what can be achieved independent of use cases and wishful thought out policies. Thanks, tglx
next prev parent reply index Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20190627201923.2589391-1-songliubraving@fb.com> [not found] ` <20190627201923.2589391-2-songliubraving@fb.com> [not found] ` <21894f45-70d8-dfca-8c02-044f776c5e05@kernel.org> [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 [this message] 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 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 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 \ --in-reply-to=alpine.DEB.2.21.1908162211270.1923@nanos.tec.linutronix.de \ --to=tglx@linutronix.de \ --cc=Golden_Miller83@protonmail.ch \ --cc=Kernel-team@fb.com \ --cc=alexei.starovoitov@gmail.com \ --cc=ast@kernel.org \ --cc=bpf@vger.kernel.org \ --cc=dancol@google.com \ --cc=daniel@iogearbox.net \ --cc=gregkh@linuxfoundation.org \ --cc=jannh@google.com \ --cc=keescook@chromium.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=lmb@cloudflare.com \ --cc=luto@kernel.org \ --cc=netdev@vger.kernel.org \ --cc=songliubraving@fb.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
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 \ linux-security-module@vger.kernel.org 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