Re b): Yeah but, like, colloquially "root" means "a process in the init user namespace with all UIDs set to 0 and a full capability mask".
Re a):
If you are root in that sense (and haven't been blanket-denied the ability to use capabilities like CAP_SYS_ADMIN by an LSM), and not subject to a strict seccomp policy, then you cannot really in general be securely constrained with LSMs.
The kernel essentially treats CAP_SYS_ADMIN in the init userns as the catch-all for "you have been granted the ability to administer and access anything on the system", for anything that doesn't have a more specific permission and isn't access-controlled by UID. And if you can, like, call swapon() on an arbitrary file to make the kernel swap memory from the whole system into that file of your choice, LSM-enforced security boundaries probably don't work all that well anymore.
seccomp does not use the eBPF userspace interface or any of the associated permission checks. seccomp (and also the classic socket filter interface) take cBPF (classic BPF), with no privilege checks; they use completely separate verification logic for this cBPF bytecode (the eBPF verifier is not involved IIRC), and then the cBPF code is (on almost all architectures) translated into eBPF. The eBPF kernel component is then only responsible for execution/JITting of this already-verified code, nothing else.
I think that on linux, you ideally don't want /dev/urandom, you want a recent kernel and getrandom(buf, len, 0). From the manpage:
If the GRND_RANDOM bit is not set, then the /dev/urandom pool
will be used. Unlike using read(2) to fetch data from
/dev/urandom, if the urandom pool has not been sufficiently
initialized, getrandom(2) will block (or return -1 with the
errno set to EAGAIN if the GRND_NONBLOCK bit is set in flags).
Then again, that's probably not important if you interactively launch gpg on a desktop system that wasn't just installed a minute ago or so.
Aaaactually, if you read the code, you'd see that he XORs the bytes from rand() with bytes from /dev/random. This project is horrible, but that's not one of the completely wrong parts.
You can embed \x1b (escape) into a webpage. When you copy-and-paste that, it has the same effect as hitting ESC in the editor. So, I'd just have to make you copy "<evil command>#\x1b:wq\n" to also catch the case that you're using vim instead of directly pasting. However, I can't figure out a way to escape from nano.
(Tested it with the combination chromium+xterm+vim.)
Right... for a real attack, you'd have to hide the evil commands near the end of the normal-looking one (the string you see there is truncated). I thought about doing that, but it'd give you a few seconds to react in this example because you'd have the git command run first. Hmm, maybe it'd be doable using backticks or so? Those could be put at the end and would evaluate first anyway...
Re a): If you are root in that sense (and haven't been blanket-denied the ability to use capabilities like CAP_SYS_ADMIN by an LSM), and not subject to a strict seccomp policy, then you cannot really in general be securely constrained with LSMs.
The kernel essentially treats CAP_SYS_ADMIN in the init userns as the catch-all for "you have been granted the ability to administer and access anything on the system", for anything that doesn't have a more specific permission and isn't access-controlled by UID. And if you can, like, call swapon() on an arbitrary file to make the kernel swap memory from the whole system into that file of your choice, LSM-enforced security boundaries probably don't work all that well anymore.