The Linux kernel already has the infrastructure required for that. Heck, Android itself, including its permission system, is built atop the Linux kernel.

Making sandboxing the default instead of having to restrict programs.

What’s missing for that is work on userspace software and app packaging. The kernel can’t automatically know what a program should and shouldn’t be allowed to do.

Some of that work has happened, like moving from X11, which really wasn’t designed around sandboxing, to Wayland.

But a lot of it requires making a permission system the norm and creating a system such that software is normally distributed with restricted permissions and developers develop around that. Like, I can use firejail and disallow write access to parts of the filesystem or network access to a program, but there isn’t a broad system of appropriate pre-created profiles that applications are distributed with and way to view this. We don’t have a convention for an application-private space on disk and lack of access to most of the filesystem, which Android does and apps need to be written around.

IMHO, one of the largest jumps would be Valve doing this for Steam games — a lot of games are going to be amenable to being sandboxed, don’t need broad access to the system, and are closed source. There are some issues there; for Windows binaries run under Proton, WINE wasn’t originally written around being isolated, and the game developers writing the software are writing to a Windows API that aren’t under the control of people on the Linux side of things.

I haven’t poked at snaps much or their technical underpinnings, but my understanding is that the snap packages distribute apps in a sandboxed form, so that might be the closest Linux-native approach. I don’t recall seeing an obvious set of permissions required a la Android package managers, though.