Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1691662 - [machines]User can still view and operate the system VMs on UI when it's deleted from libvirt group.
Summary: [machines]User can still view and operate the system VMs on UI when it's dele...
Keywords:
Status: ASSIGNED
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: libvirt-dbus
Version: 8.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Pavel Hrdina
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-22 07:59 UTC by YunmingYang
Modified: 2019-04-04 12:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description YunmingYang 2019-03-22 07:59:48 UTC
Description of problem:

When a user is deleted from libvirt group, it can still view and operate system VMs on cockpit-mahcines UI

Version-Release number of selected component (if applicable):
cockpit-machines-184.1-1.el8.noarch
libvirt-dbus-1.2.0-2.module+el8+2704+d2eddeb5.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create system VMs using UI or cmdline.
2. Create a user and add it to libvirt group. Log into cockpit with the user, and check system VMs on Virtual Machines page.
3. Delete the user from libvirt group by running `gpasswd -d ${user} libvirt` on host
4. Re-login to cockpit with the user, and check if system VMs disappear on Virtual Machines page

Actual results:
1. After step2, the user can view and operate the system VMs on Virtual Machines page.
2. After step4, the system VMs doesn't disappear and can be operated by the user.

Expected results:
1. After step4, the user shouldn't see the system VMs on UI, as it's not in libvirt group anymore.

Additional info:

Comment 1 Katerina Koukiou 2019-03-22 09:22:36 UTC
@Yunming are you connecting with a user that has sudo privileges and you are choosing when logging in 'Reuse my password for privileged tasks'? If yes, this is expected to behave like this since it's same like doing from CLI 'sudo virsh list --all' for example and giving your password.

Comment 2 YunmingYang 2019-03-22 09:36:46 UTC
I just add the user to the libvirt group.However,the user doesn't have the sudo privileges and I don't choose the 'Reuse my password for privileged tasks'.

Comment 3 Katerina Koukiou 2019-03-22 10:06:58 UTC
(In reply to YunmingYang from comment #2)
> I just add the user to the libvirt group.However,the user doesn't have the
> sudo privileges and I don't choose the 'Reuse my password for privileged
> tasks'.

Do you by any chance get the same results from virsh CLI or is this cockpit UI specific?

Comment 4 YunmingYang 2019-03-22 10:34:29 UTC
(In reply to Katerina Koukiou from comment #3)
> (In reply to YunmingYang from comment #2)
> > I just add the user to the libvirt group.However,the user doesn't have the
> > sudo privileges and I don't choose the 'Reuse my password for privileged
> > tasks'.
> 
> Do you by any chance get the same results from virsh CLI or is this cockpit
> UI specific?

The result from virsh CLI is different from the cockpit UI. I can't get the system VMs through virsh CLI, but i can get it through cockpit UI.

Comment 5 Martin Pitt 2019-03-22 10:44:52 UTC
The privilege enforcement needs to be done in the libvirt-dbus daemon, we can't do it on the cockpit side. So if libvirt-dbus allows calling methods as normal user who isn't in the libvirt group for system:/// instances, then this is a security issue. It seems like you already checked that these are not session:/// (i. e. per-user) VMs?

Comment 6 YunmingYang 2019-03-22 11:22:28 UTC
(In reply to Martin Pitt from comment #5)
> The privilege enforcement needs to be done in the libvirt-dbus daemon, we
> can't do it on the cockpit side. So if libvirt-dbus allows calling methods
> as normal user who isn't in the libvirt group for system:/// instances, then
> this is a security issue. It seems like you already checked that these are
> not session:/// (i. e. per-user) VMs?

Sure,i only create one VM with 'the root user' in my test environment.It seems like the privilege of the normal user who isn't in the libvirt group become normal if i restart the dbus service with cmd 'systemctl restart dbus'

Comment 7 Martin Pitt 2019-03-22 11:32:45 UTC
That would explain it then. Restarting the entire dbus is an unnecessarily big hammer, `pkill -e libvirt-dbus` ought to be enough. I suspect that libvirt-dbus only reads the NSS database at startup, so while it's running it does not notice changes in groups. I'm not sure if that times out after a few minutes of inactivity, so that it will clean up itself.

But this is not a vulnerability per se -- in Linux it's incredibly hard to really reliably remove a user from a group without a reboot (the user could always fork off a long-running background process which still has the group membership).


Note You need to log in before you can comment on or make changes to this bug.