harden insecure permissions inside /dev/xen folder / research security impact of the Qubes /dev/xen folder permissions

[adrelanos]

Qubes OS release

R4.2

Brief summary

Permissions inside /dev/xen folder might be insecure in context of preventing user to root local privilege escalation attacks.

Steps to reproduce

Exact steps are unknown. But since Qubes developer @DemiMarie states this, a ticket is warranted.

Issue

Quote @DemiMarie in #8823 (comment)

Right now, various devices under /dev/xen are accessible by any user in the qubes group. This is needed for unprivileged processes to use vchans, but likely allows escalation from the qubes group to root.

There are a couple of alternatives:

1. Do nothing.
2. Have every vchan-using program be set-user-id root. I’m not sure if this is a reasonable approach, especially because I don’t know if the Xen libraries are safe to use in setuid programs.
3. Use a privileged daemon for all vchan and grant operations.
4. Move the libvchan implementation into a kernel module. I very much like this approach, but it it is quite a bit more work.

Additional information

ls -la /dev/xen

total 0
drwxr-xr-x  2 root root      160 Jan 16 06:40 .
drwxr-xr-x 17 root root     3.9K Jan 16 06:42 ..
crw-rw----  1 root qubes 10, 122 Jan 16 06:40 evtchn
crw-rw----  1 root qubes 10, 121 Jan 16 06:40 gntalloc
crw-rw----  1 root qubes 10, 120 Jan 16 06:40 gntdev
crw-rw----  1 root qubes 10, 118 Jan 16 06:40 hypercall
crw-rw----  1 root qubes 10, 119 Jan 16 06:40 privcmd
crw-rw----  1 root qubes 10, 125 Jan 16 06:40 xenbus

Expected behavior

Secure permissions or any other secure implementation.

Actual behavior

Potentially insecure permissions.