-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
harden insecure permissions inside /dev/xen
folder / research security impact of the Qubes /dev/xen
folder permissions
#9717
Comments
I did some research on this and discussed it with Demi and Marek in the Qubes OS Matrix room. I tried to condense down what I learned so that it's easier to figure out the next steps. Here's what I wrote down: Qubes OS currently uses an in-qube security model that essentially assumes that gaining root within an individual qube is not a risk. This makes sense, since Qubes OS is designed to enforce isolation with AppVMs, not user accounts. However, as a form of defense-in-depth, it is worthwhile to prevent software from being able to get passwordless root access within a qube even though this isn't directly useful for isolating data from an attacker. The main reason for this is that most attacks that would allow breaking out of a VM into dom0 require that an attacker be able to get root in a VM first. Making this a hurdle could at least significantly increase the difficulty of an attack and potentially save users from becoming compromised when they otherwise would have been. In order to allow Qubes OS's qrexec functionality to work, Qubes OS currently allows all devices under /dev/xen inside of a qube to be accessed by any user in the group qubes. This group includes the default user account, user. The reason this is necessary is because qrexec uses Xen's libxenvchan to allow data transfer between VMs. libxenvchan uses Xen grants in the background, which are a mechanism for sharing memory pages between VMs. Sharing memory to other VMs and gaining access to memory shared by other VMs requires the ability to use the /dev/xen devices (specifically gntdev, gntalloc, and privcmd), so they have to be accessible by everything that works with qrexec, including things that don't or shouldn't run as root. Each grant has a grant reference, which is basically an ID number used to refer to that grant. The issue with Xen grants is that they only secure inasmuch as a block of memory shared with a particular VM will only be able to be accessed by the specified VM. Xen's grants are guest-agnostic, and so while they do prevent a malicious guest from gaining access to another guest's shared memory, they do not prevent processes from interfering with each other's grants. There is no concept of processes in Xen grants; the guest has to "do the right thing" with the memory it gives and receives, whatever "the right thing" is in each context. This can potentially be used to corrupt data. A malicious process in a VM can very likely guess the grant ID used by a privileged component of the system (such as blkfront, Xen's virtual disk driver), and use it in unexpected ways. For instance, blkfront uses grants to communicate with dom0 for allowing disk contents to be sent back and forth. If a malicious process can guess a grant used by blkfront, it can attempt to tell other things in dom0 to use that same grant for other purposes (for instance, providing it to dom0 for use with qrexec). This should usually result in an error since two things will be trying to use the same area of memory at the same time, but it can potentially result in data corruption, which could potentially be used to gain kernel-level privileges within a qube. Preventing this within the Linux kernel will probably require a driver that can provide functionality similar to libxenvchan but without requiring grant functionality to be exposed directly. This would allow qrexec to function without requiring the grant management devices to be directly accessible to almost everything in a qube. The kernel would still use grants in the background, but they would be abstracted away from the end user, and channel IDs would be managed separately from grant references. (This is also in the Kicksecure dev documentation so it doesn't get lost: https://www.kicksecure.com/wiki/Dev/Qubes#Root_Privilege_Isolation_and_libxenvchan) As for something actionable to be done, it seems the best solution is for someone to make an in-kernel, grant-based libxenvchan alternative in the kernel. Depending on what my priorities at work end up being, I may give this a shot. |
Quote @DemiMarie in #2695 (comment)
|
No strong opinions from my side.
But I would refer this to people more knowledgeable about Xen.
I would hope that Wayland support (#3366) gets implemented eventually. Unless critically important, I would suggest to not spend any effort on X11 and rather redirect that effort towards Wayland. This ticket could be implemented as if, assuming that the Qubes port to Wayland has already been completed to avoid one ticket blocking another. |
Based on prior discussions, I think option 1 is likely to be the most preferable. Having privileged daemons sounds good, but I think that runs into the X11 problems that Demi mentioned. It also means that any application implemented with libxenvchan has to be implemented in a similarly tricky manner, since the problem at its core is that the job libxenvchan does can't be done in a fully safe way in userland. Implementing a libxenvchan-like API in the kernel allows doing things like sharing files between VMs without a domU being able to make dom0 corrupt things. |
@ArrayBolt3 I think it would be best to use actual |
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)
Additional information
Expected behavior
Secure permissions or any other secure implementation.
Actual behavior
Potentially insecure permissions.
The text was updated successfully, but these errors were encountered: