We've disabled eBPF for normal users on our Linux machines
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
says; per the
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.)
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.
egrep is non-standard and deprecated. Use grep -E instead. fgrep is non-standard and deprecated. Use grep -F instead.
Sorry, nope. Both
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