Wandering Thoughts archives

2020-04-17

We've disabled eBPF for normal users on our Linux machines

In late March, there was a Linux kernel security issue, CVE-2020-8835 (also). This was, to quote the Ubuntu CVE description:

In the Linux kernel 5.5.0 and newer, the bpf verifier (kernel/bpf/verifier.c) did not properly restrict the register bounds for 32-bit operations, leading to out-of-bounds reads and writes in kernel memory. The vulnerability also affects the Linux 5.4 stable series, starting with v5.4.7, [...]

We were lucky. Because we run the standard Ubuntu 18.04 server kernels instead of the HWE kernels, we were not affected by this and did not have to go through a fleet wide kernel update and reboot while working from home.

You might wonder why an issue in eBPF creates a security vulnerability, as I did at the time. The answer is that these days, eBPF programs can be used by ordinary users on their own sockets (contrary to what the current bpf(2) manpage says; per the exploit writeup, this was a change added in kernel 4.4). This means that bugs in the eBPF verifier and JIT translation that allow bad stuff to slip through are fatal; the entire system's security rests on them being completely right all of the time.

Fortunately there is a kernel sysctl that controls whether normal users can use eBPF, kernel.unprivileged_bpf_disabled; if set to '1', normal users can't use eBPF. You can probably guess what we immediately did when this CVE came out, even though it didn't apply to us; we immediately pushed out a local update to all of our machines that turned this on, disabling user eBPF programs. Much like user namespaces (which kept enabling kernel security issues) and overlayfs, we feel that allowing user eBPF programs is too much risk right now for too little potential gain. Perhaps someday there will be a compelling usage for this, but for now we'd rather avoid a whole class of potential security issues.

(If anything has broken as a result of this, people haven't told us.)

linux/DisablingUserEBPF written at 23:24:22; Add Comment

Some bits of grep usage are where I disagree with Shellcheck

I have come to very much like shellcheck and now automatically use it on any shell script I'm writing or revising (at least any scripts for work; personal ones I'm sometimes lazier with). Although some of its issues are a little bit picky, using it is good for me so I go along with them. Well, with one exception, because I cannot go along with Shellcheck's views on using egrep and fgrep.

If you've used Shellcheck on scripts, especially older ones, you have probably run into SC2196 and SC2197:

egrep is non-standard and deprecated. Use grep -E instead.
fgrep is non-standard and deprecated. Use grep -F instead.

Sorry, nope. Both egrep and fgrep are long standing programs and names for these versions of grep, and they will be present on any sane Unix until the end of time (and I don't mean 2038, the end of the 32-bit Unix epoch). I have a visceral and probably irrational reaction to the idea of using the POSIXism of 'grep -E' and 'grep -F' for them, and I have no intention of switching my scripts away from using fgrep and egrep.

(And grep already has enough flags to keep track of, including important ones for searching test files in GNU Grep.)

Fortunately modern versions of Shellcheck (including the one in Ubuntu 18.04) can disable these warnings for your entire script, as covered in the wiki's page on ignoring errors. Just put a line in the comment at the start of your script to turn them off:

#!/bin/sh
[...]
# Disable warnings about use of egrep and fgrep
# shellcheck disable=SC2196,SC2197

(I don't want to use a $HOME/.shellcheckrc for this, because I want our scripts to Shellcheck cleanly regardless of who runs Shellcheck.)

programming/ShellcheckAndGrep written at 00:48:05; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.