[Joel_Mckay]

Most production OS I saw would do this on boot-up completion:

echo 1 > /proc/sys/kernel/modules_disabled

Which is supposed to block dynamic loading modules until a reboot.

It would be interesting if the PoC can get around that trick too. =3

[worthless-trash]

Once you have memory write as ring0, all protections are dubious at best.

Why bother loading a module when you can inject code into any function you want.

[Joel_Mckay]

The encrypted page memory manager hardware in some ancient Sun systems prevented a lot of these context isolation problems. However, the modern IT landscape chose consumer grade processor architecture and bodged GPUs as the cloud infrastructure foundation.

Thus, there currently is economic inertia entrenching vulnerable system design. I don't think there is a company large enough to change the situation anytime soon, as the market has spoken. =3

Rule #3: popularity is not an indication of utility.

[lima]

If Kernel Lockdown is enabled, a zero-day exploit is required to bypass module restrictions without a reboot.

Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module.

The Linux kernel is not really an effective privilege boundary.

[Imustaskforhelp]

So what would you recommend instead? To run workflows in VMs?

[Joel_Mckay]

A kvm hypervisor is not perfect, as sandbox escape was demonstrated even with https://qubes-os.org/ . On modern AMD/Intel/ARM64 consumer processors it is not possible to completely prevent bleeding keys across regions.

Only the old Sun systems with hardware encrypted mmu pages could actually enforce context isolation.

If performance is not important, and people are dealing with something particularly nasty... than running an emulator on another architecture is a better solution. For example, MacOS M4 with a read-only windows amd64 backing-image guest OS is a common configuration.

https://github.com/86Box/86Box/releases

https://github.com/Moonif/MacBox/releases

Best of luck =3

[flipped]

I am hearing first time of a sandbox escape in QubesOS. Can you link the source?

[Joel_Mckay]

It was a POC from shortly after Spectre CVE dropped, and I'm not sure if the source code made it into the public. I heard about the exploit in a talk by Joanna Rutkowska, where she admitted the OS could no longer completely span TCSEC standards on consumer Intel CPUs. YMMV

The modern slop-web is harder to find things now, and I can't recall specifically if it was something more than just common hypervisor guest escape. =3

[worthless-trash]

Or only allow signed kernel modules. Aka secure boot.

This doesn't solve all vectors but afaics this will prevent non signed modules from loading.