> LPE: On distributions such as RHEL, /dev/kvm is world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root.

Why on Linux device files are accessible by untrusted applications?

▲

tryauuum a day ago | parent | next [-]

Not all device files, only /dev/kvm. I assume the logic was "with /dev/kvm access the user can ...allocate memory and execute code, which they already can, so why not allow it?". Could also make rootless isolation easier

	▲	codedokode a day ago \| parent [-]
		Different kernel modules might have different vulnerabilities.

▲

Intralexical a day ago | parent | prev | next [-]

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!

▲

yjftsjthsd-h a day ago | parent | prev | next [-]

1: As siblings note, some device files are wide open, some are limited to a given user group, and some are root-only.

2: Because it's desirable for users to be able to run VMs.

▲

fulafel 20 hours ago | parent | prev | next [-]

Linux controls access using configurable file permissions, so this has a false premise. The better question is doesn't RHEL really use a kvm group to limit access like other distributions? If so, why?

▲

rwmj 15 hours ago | parent | next [-]

Because you want users to use virtualization for sandboxing without needing to make system-wide changes. That generally improves security overall. You might as well ask "why allow users to run anything at all?" since they can make system calls into a gigantic C program that is likely full of unknown bugs.

▲

fulafel 12 hours ago | parent [-]

I get where you're coming from but I'd argue the kvm group is still better even when you automatically give all human users membership. You can then have less-privileged accounts for service roles, for example nginx doesn't need kvm acccess.

	▲	rwmj 11 hours ago \| parent [-]
		nginx might not, but some automated tool / cron job using libguestfs might. Kernel KVM has a very good record for security so it's not something to worry about, compared to (for example) lesser used drivers/filesystems or other dusty corners of the kernel.

▲

codedokode 17 hours ago | parent | prev [-]

The permissions are per-user, not per-app and that is the problem. The distibution developers assume that you trust the programs you run, but how can I trust commercial and proprietary software? How can I trust the code from a random guy on Github without a passport verification?

	▲	fulafel 12 hours ago \| parent [-]
		Depends on your setup, you can have per-app permissions too. Flatpak, snap etc do this for desktop apps, Android does it, containerized server apps do it. But of course if it turns out you're running malware, you're going to have problems when it transpires that you've delegated something valuable to it, even if it doesn't break out of its permission set.

▲

cyberax a day ago | parent | prev | next [-]

???

That's been the case forever: /dev/null, /dev/zero, /dev/stdin, ...

	▲	inigyou 15 hours ago \| parent [-]
		/dev/stdin is a symlink to /proc/self/fd/0

▲

20 hours ago | parent | prev | next [-]

[deleted]

▲

colechristensen a day ago | parent | prev [-]

Very many "devices" aren't at all device-like.