From: Alexei Starovoitov <firstname.lastname@example.org> To: Kees Cook <email@example.com> Cc: Andy Lutomirski <firstname.lastname@example.org>, Song Liu <email@example.com>, Networking <firstname.lastname@example.org>, bpf <email@example.com>, Alexei Starovoitov <firstname.lastname@example.org>, Daniel Borkmann <email@example.com>, Kernel Team <Kernelfirstname.lastname@example.org>, Lorenz Bauer <email@example.com>, Jann Horn <firstname.lastname@example.org>, Greg KH <email@example.com>, Linux API <firstname.lastname@example.org>, LSM List <email@example.com> Subject: Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf Date: Thu, 15 Aug 2019 16:46:23 -0700 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <201908151203.FE87970@keescook> On Thu, Aug 15, 2019 at 12:46:41PM -0700, Kees Cook wrote: > On Tue, Aug 13, 2019 at 02:58:25PM -0700, Alexei Starovoitov wrote: > > agree that containers (namespaces) reduce amount of trust necessary > > for apps to run, but the end goal is not security though. > > Unsurprisingly, I totally disagree: this is the very definition of > improved "security": reduced attack surface, confined trust, etc. there are different ways to define the meaning of the word "security". Of course containers reduce attack surface, etc. The 'attack surface' as a mitigation from malicious users is not always the goal of running containers. Ask yourself why containers are used in the datacenters where only root can ssh into a server, only signed packages can ever be installed, no browsers running, and no remote code is ever downloaded? > > Linux has become a single user system. > > I hope this is just hyperbole, because it's not true in reality. I agree > that the vast majority of Linux devices are single-user-at-a-time > systems now (rather than the "shell servers" of yore), but the system > still has to be expected to confine users from each other, root, and the > hardware. Switching users on Chrome OS or a distro laptop, etc is still > very much expected to _mean_ something. of course. > > > If user can ssh into the host they can become root. > > If arbitrary code can run on the host it will be break out of any sandbox. > > Containers are not providing the level of security that is enough > > to run arbitrary code. VMs can do it better, but cpu bugs don't make it easy. > > I'm not sure why you draw the line for VMs -- they're just as buggy > as anything else. Regardless, I reject this line of thinking: yes, > all software is buggy, but that isn't a reason to give up. hmm. are you saying you want kernel community to work towards making containers (namespaces) being able to run arbitrary code downloaded from the internet? In other words the problems solved by user space sandboxing, gvisor, etc should be solved by the kernel? I really don't think it's a good idea. > If you look at software safety as a binary, you will always be > disappointed. If you look at it as it manifests in the real world, > then there is some perspective to be had. Reachability of flaws becomes > a major factor; exploit chain length becomes a factor. There are very > real impacts to be had from security hardening, sandboxing, etc. Of > course nothing is perfect, but the current state of the world isn't > as you describe. (And I say this with the knowledge of how long > the lifetime of bugs are in the kernel.) No arguing here. Security today is mainly the number of layers. Hardening at all levels, sanboxing do help. namespaces is one of the layers provided by the kernel. The point that the kernel did its job already. All other security layers are in user space. Looking for bugs at every layer is still must have. In the kernel, systemd, qemu, OS, browsers, etc. Containers provide one level of security. VMs have another. > > Some people call it more 'secure', but it's clearly not secure for > > arbitrary code > > Perhaps it's just a language issue. "More secure" and "safer" mean > mostly the same thing to me. I tend to think "safer" is actually > a superset that includes things that wreck the user experience but > aren't actually in the privilege manipulation realm. In the traditional > "security" triad of confidentiality, integrity, and availability, I tend > to weigh availability less highly, but a bug that stops someone from > doing their work but doesn't wreck data, let them switch users, etc, > is still considered a "security" issue by many folks. The fewer bugs > someone is exposed to improves their security, safety, whatever. The > easiest way to do that is confinement and its associated attack surface > reduction. tl;dr: security and safety are very use-case-specific > continuum, not a binary state. yep > > > When we say 'unprivileged bpf' we really mean arbitrary malicious bpf program. > > It's been a constant source of pain. The constant blinding, randomization, > > verifier speculative analysis, all spectre v1, v2, v4 mitigations > > are simply not worth it. It's a lot of complex kernel code without users. > > There is not a single use case to allow arbitrary malicious bpf > > program to be loaded and executed. > > The world isn't binary (safe code/malicious code), and we need to build > systems that can be used safely even when things go wrong. Yes, probably > no one has a system that _intentionally_ feeds eBPF into the kernel from > a web form. But there is probably someone who does it unintentionally, > or has a user login exposed on a system where unpriv BPF is enabled. The > point is to create primitives as safely as possible so when things DO > go wrong, they fail safe instead of making things worse. > > I'm all for a "less privileged than root" API for eBPF, but I get worried > when I see "security" being treated as a binary state. Especially when > it is considered an always-failed state. :) 'security as always failed state' ? hmm. not sure where this impression came from. One of the goals here is to do sysctl kernel.unprivileged_bpf_disabled=1 which will make the system overall _more_ secure. I hope we can agree on that.
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 2019-08-15 18:43 ` Jordan Glover 2019-08-15 19:46 ` Kees Cook 2019-08-15 23:46 ` Alexei Starovoitov [this message] 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 \ --firstname.lastname@example.org \ --email@example.com \ --cc=Kernelfirstname.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 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