Because if /dev/kvm isn't accessible to unprivileged users, then people will start using `sudo` to run anything involving virtualization, which would be much worse for security overall.

▲

CoastalCoder a day ago | parent [-]

I'm just starting to read up on capabilities-based security in Linux.

Would they potentially be a solution to sudo's all-or-nothing granularity in this domain?

▲

msm_ a day ago | parent [-]

Linux capabilities have many problems (they are too coarse-grained and too many capabilities are root-equivalent). But anyway this is an overkill in this case probably. In may distributions access to /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.

▲

Intralexical a day ago | parent | next [-]

Would capabilities enable granting access to specific programs and not just users? Like using AppArmor profiles. So QEMU, gVisor, Docker etc. can still use KVM for unprivileged users, but malware wouldn't be able to access it directly.

	▲	codedokode 17 hours ago \| parent [-]
		That's the problem with many Linux distributions - their developers assume that you trust programs you run and if you run malware it is your fault. But you cannot trust commercial and closed-source programs so Linux is not ready for using them. Instead of solving the problem they simply make it user's responsibility. So as a responsible user I am slowly writing my own sandboxes, struggling with lack of documentation and designing workarounds.

▲

quotemstr 20 hours ago | parent | prev [-]

> /dev/kvm is guarded by membership in the kvm group - no need for new capability, just regular old filesystem permissions.

Which is precisely why many kinds of kernel feature should be exposed as operations on device nodes, not as system calls usable out of thin air. UGO and ACL permissions work on device nodes!