KVM device assignment and user privileges
Hi all,
I've been working on adding device assignment to KVM tools, and started with the basics of just getting a device assigned using the KVM_ASSIGN_PCI_DEVICE ioctl.
What I've figured is that unprivileged users can request any PCI device to be assigned to him, including devices which he shouldn't be touching.
In my case, it happened with the VGA card, where an unprivileged user simply called KVM_ASSIGN_PCI_DEVICE with the bus, seg and fn of the VGA card and caused the display on the host to go apeshit.
Was it supposed to work this way? I couldn't find any security checks in the code paths of KVM_ASSIGN_PCI_DEVICE and it looks like any user can invoke it with any parameters he'd want - enabling him to kill the host.
Signature · 1 line
Sasha.
Quoted 6 lines · Sasha Levin
Hi all,
I've been working on adding device assignment to KVM tools, and started with the basics of just getting a device assigned using the
KVM_ASSIGN_PCI_DEVICEioctl.
Quoted 8 lines
What I've figured is that unprivileged users can request any PCI device to be assigned to him, including devices which he shouldn't be touching.
In my case, it happened with the VGA card, where an unprivileged user simply called
KVM_ASSIGN_PCI_DEVICEwith the bus, seg and fn of the VGA card and caused the display on the host to go apeshit.Was it supposed to work this way?
No, of course not.
Quoted 3 lines
I couldn't find any security checks in
the code paths ofKVM_ASSIGN_PCI_DEVICEand it looks like any user can invoke it with any parameters he'd want - enabling him to kill the host.
Alex, Chris?
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 10 lines · * Avi Kivity ([email protected]) wrote:
Quoted 9 lines · Sasha Levin
Hi all,
I've been working on adding device assignment to KVM tools, and started with the basics of just getting a device assigned using the
KVM_ASSIGN_PCI_DEVICEioctl.What I've figured is that unprivileged users can request any PCI device to be assigned to him, including devices which he shouldn't be touching.
Quoted 7 lines
Quoted 5 lines
In my case, it happened with the VGA card, where an unprivileged user simply called
KVM_ASSIGN_PCI_DEVICEwith the bus, seg and fn of the VGA card and caused the display on the host to go apeshit.Was it supposed to work this way?
No, of course not.
Indeed. A device is typically owned by a host OS driver which precludes device assignment from working. If it's not, the unprivilged guest will not have access to the device's config space or resource bars as they are only rw for a privileged user. And similarly, /dev/kvm was typically left as 0644. As you can see, it's fragile.
Quoted 5 lines
Quoted 3 lines
I couldn't find any security checks in
the code paths ofKVM_ASSIGN_PCI_DEVICEand it looks like any user can invoke it with any parameters he'd want - enabling him to kill the host.Alex, Chris?
The security checks were removed some time back. The expectation was that there was nothing an unprivleged user could usefully do w/ the assign device ioctl, and the assign irq ioctl only works after assign device. It's built on an overly fragile set of assumptions, however. Avi, the simplest short term thing to do now might be simply revert:
48bb09e KVM: remove CAP_SYS_RAWIO requirement from kvm_vm_ioctl_assign_irq
While it's a regression for existing unprivileged users it's better than a hole. And in the meantime, we can come up w/ something better to replace with.
thanks,
-chris
Quoted 31 lines · Chris Wright
Quoted 10 lines · * Avi Kivity ([email protected]) wrote:
Quoted 9 lines · Sasha Levin
Hi all,
I've been working on adding device assignment to KVM tools, and started with the basics of just getting a device assigned using the
KVM_ASSIGN_PCI_DEVICEioctl.What I've figured is that unprivileged users can request any PCI device to be assigned to him, including devices which he shouldn't be touching.
Quoted 7 lines
Quoted 5 lines
In my case, it happened with the VGA card, where an unprivileged user simply called
KVM_ASSIGN_PCI_DEVICEwith the bus, seg and fn of the VGA card and caused the display on the host to go apeshit.Was it supposed to work this way?
No, of course not.
Indeed. A device is typically owned by a host OS driver which precludes device assignment from working. If it's not, the unprivilged guest will not have access to the device's config space or resource bars as they are only rw for a privileged user. And similarly,
/dev/kvmwas typically left as 0644. As you can see, it's fragile.Quoted 5 lines
Quoted 3 lines
I couldn't find any security checks in
the code paths ofKVM_ASSIGN_PCI_DEVICEand it looks like any user can invoke it with any parameters he'd want - enabling him to kill the host.Alex, Chris?
Quoted 7 lines
The security checks were removed some time back. The expectation was that there was nothing an unprivleged user could usefully do w/ the assign device ioctl, and the assign irq ioctl only works after assign device. It's built on an overly fragile set of assumptions, however. Avi, the simplest short term thing to do now might be simply revert:
48bb09e KVM: remove
CAP_SYS_RAWIOrequirement fromkvm_vm_ioctl_assign_irq
That does nothing for for the KVM_ASSIGN_PCI_DEVICE ioctl.
Quoted 3 lines
While it's a regression for existing unprivileged users it's better than a hole. And in the meantime, we can come up w/ something better to replace with.
How about doing an access(2) equivalent check for one of the sysfs files used to represent the device? If libvirt already chowns them to the right user, then we have no regression, at least for that use case.
Signature · 1 line
error compiling committee.c: too many arguments to function