dashboard/app: separate flaw non-root accessibility

[cgwalters]

Filing this in response to this Twitter thread: https://twitter.com/dvyukov/status/1354339035322449922

Today, AFAIK the main syskaller instances all run as "real root" i.e. CAP_SYS_ADMIN without user namespaces. This finds a lot of bugs in the kernel which should ideally be fixed; but most of them aren't critical security flaws because we're already running as root.

In contrast for example in OpenShift we run user containers by default under a restricted security context constraint which runs them as non-root. Hopefully soon Kubernetes upstream will gain user namespaces too.

Many other systems do this too; there are many systems out there which are still much like the "traditional Unix timesharing" model of having users ssh into machines as non-root and expecting that to be "secure".

Here "secure" doesn't mean "perfectly without flaws" - it means we believe we can fix bugs that arise and don't expect bugfixes to need fundamental redesigns.

I think it'd be useful if syskaller first when it found a flaw, tried reproducing it as non-root too.

And it'd also be good I think to e.g. steer a larger percentage of the computational resources towards "unprivileged accessible" code paths, and have a separate list for anything that arises here. For all of us Linux OS vendors we basically need to keep that list empty.

A great example is the recent change to allow unprivileged overlayfs mounts. Per your twitter thread - indeed, mounting traditional filesystems requires privileges - you can't do it in Kubernetes/podman/docker. That recent change moves overlayfs into the accessible list, so ideally more syzkaller computation is targeted at it.

[dvyukov]

Hi Colin,

Is there any plan to do anything concrete with such non-root bugs if syzbot provides this info? So far I get an impression that for upstream developers it's mostly uninteresting, for some subsystems all bugs are fixed regardless of root/non-root, for some -- non are fixed, some are somewhere in between. If there is no concrete plan, it may just make script kiddies work easier :)

[dvyukov]

There is another interesting aspect in the context of fuzzing: some critical non-root bugs require some actions from root as well. Consider, root just creates a particular privileged socket type, or normal socket type with privileged setsockopt, or loads a bpf program, and then a remote side a particular network packet and exploits the machine. This won't be found by the non-root targeted instances and won't be classified as non-root.

[dvyukov]

This will probably require #608 as a prerequisite as a way to mark bugs and correct automatic marking.

[cgwalters]

Is there any plan to do anything concrete with such non-root bugs if syzbot provides this info?

It depends on the result of the bug, but if e.g. it looks like memory corruption then it should be treated as a CVE I'd say.

And that really is the heart of this discussion; on the Twitter thread you implied that because there were a lot of root accessible flaws that that meant Linux namespaces are worthless - but I strongly disagree with that and I think a lot of others would too.

So far I get an impression that for upstream developers it's mostly uninteresting, for some subsystems all bugs are fixed regardless of root/non-root, for some -- non are fixed, some are somewhere in between.

If it's non-root accessible then I would say it should follow the Linux kernel security report flow.

If there is no concrete plan, it may just make script kiddies work easier :)

Well yes, they are almost certainly running private instances of fuzzers like syzkaller, watching commits that affect the attack surface and likely front-running with custom rules. And you and I are here on the opposite side to protect people's computers, trying to stay ahead of the attackers. Part of that is prioritizing the same thing they prioritize. The vast, vast majority of syzkaller bugs are irrelevant to them because they already assume root. And hence they should be treated as a "pool of background things to fix", not an indictment of Linux in general.

To rephrase and simplify: You guys have a choice where to spend your time and the CPU hours of the Google syzkaller instance, as well as the time of the kernel maintainers. I think (again to pick a random number) at least 50% of that time should focus on non-root paths.

[dvyukov]

Is there any plan to do anything concrete with such non-root bugs if syzbot provides this info? It depends on the result of the bug, but if e.g. it looks like memory corruption then it should be treated as a CVE I'd say.

I meant: who will do what with these results? Who will triage them and file CVEs?

[cgwalters]

There is another interesting aspect in the context of fuzzing: some critical non-root bugs require some actions from root as well.

That's an interesting case and I think it boils down to: Are there parts of shipping Linux userspace that follow that pattern? For example, systemd does set up bpf programs attached to sockets, so indeed fuzzing that path makes sense; maybe someone comes by and adds some socket API that somehow allows corrupting that bpf state or something.

But otherwise - like obscure scenarios where a root app calls perf_event_open() and passes that down to an unprivileged process...if no one is doing that in practice, then it's treated as a bug, not a CVE.

[cgwalters]

I meant: who will do what with these results? Who will triage them and file CVEs?

I'm not a kernel maintainer, and at this point we should probably get one in this discussion :smile: But I suggested the existing kernel security contact list above - or you could try direct email to the maintainer(s).

I know you've gotten some pushback about the unending flow of syzkaller reports, and I hope taking this more targeted approach could help with that.

[dvyukov]

That's an interesting case and I think it boils down to: Are there parts of shipping Linux userspace that follow that pattern?

privileged setsockopt's, all network setup, mounting an fs and then provoking a bug by just creating a file in that fs there seems to be lots of such cases