Description of problem: Customer reports after upgrading to 4.2, their users are able to 'steal' console sessions from the previous user, either through VM portal or admin portal. - User1 is connected to a VM running windows7 or windows10. - This windows VM is: - using SPICE as console protocol. - "Console Disconnect Action" is set to "lock screen". - "Disable strict user checking" is unchecked. - Everything is working normal for User1. - If a User2 -without superuser role- tries to connect to the console of the same VM (using VM portal or admin portal), User2 gets the console without any kind of warning and the previous session from User1 is exposed to User2. Expected result: the session from User1 is locked. This is the behavior the customer was used to in 4.1. I see they have SSO enabled via guest-agent, I'm not sure if this could be the reason that User2 can login without any kind of prompt. Version-Release number of selected component (if applicable): rhvm-4.2.8.5-0.1.el7ev.noarch ovirt-engine-webadmin-portal-4.2.8.5-0.1.el7ev.noarch
Michal, this looks like a regression of this BZ? https://bugzilla.redhat.com/show_bug.cgi?id=1297018
I was able to reproduce with the following setup: ~ Engine: rhvm-4.2.8.5-0.1.el7ev.noarch ovirt-engine-webadmin-portal-4.2.8.5-0.1.el7ev.noarch ~ Host: redhat-virtualization-host-image-update-4.2-20190411.1.el7_6.noarch vdsm-4.20.48-1.el7ev.x86_64 spice-server-0.14.0-6.el7_6.1.x86_64 ~ Client: Fedora 29 - virt-viewer-7.0-1.fc29.x86_64 ~ VM: Windows 10 Enterprise - Build 17763.rs5_release.180914-1434 RHV Guest tool: 4.2.9 Spice-Agent64: 4.42.1 ~ By default, "Disable strict user checking" is not checked for new VMs, so I get the correct behavior: - Admin user connects to this VM's console via SPICE from Admin Portal. - Login within the VM. - Regardless if admin user closes remote viewer or not, normal user with UserRole assigned to this VM cannot get the console from VM Portal. - Normal user only gets "Failed to retrieve VM console details Conflict" message. Now, if I check "Disable strict user checking" for this VM: - Admin user connects to this VM's console from admin portal and login within the VM. - If the Admin user does not close the remote-viewer, a normal user from VM portal clicks on the console button, and without any prompt or warning, resumes the console session from the Admin user. - If the Admin user is done working and manually closes the remote-viewer, then the VM is locked. Any user attempting to connect to the console sees the ctrl+alt+del to unlock screen within the VM. So the issue seems to be in the guest-agent. If a console is already opened (SPICE or VNC) and a new console connection is requested from a new user, the disconnection from the first session does not cause the VM to lock itself. Which should be the correct behavior.
Definitely related to 1631150, but with a different result We expect in that case that 2 different users won't be able to open each other's consoles (verified in current 4.2) versions. Federico -- 'strict user checking' is specifically designed for this case. If this works without disabling this, I'd expect it to be NOTABUG, especially with such an easy fix (enable strict user checking if console security matters). Am I missing something?
(In reply to Federico Sun from comment #4) > So the issue seems to be in the guest-agent. If a console is already opened > (SPICE or VNC) and a new console connection is requested from a new user, > the disconnection from the first session does not cause the VM to lock > itself. Which should be the correct behavior. I don't think this has ever worked this way. As Ryan says, this is NOTABUG. Per documentation: Disable strict checking with caution, because you can expose the previous user’s session to the new user.
Ryan and Tomáš, The customer claims that in 4.1, whenever they connect to an already established console session, the VM would locked itself, thus, they are expecting it in 4.2 as well. So if 'Strict User Checking' should've worked this way in 4.1 too, was this is a bug in 4.1?
It's possible that 4.1 had a regression of https://bugzilla.redhat.com/show_bug.cgi?id=1297018, but testing would need to be done To be clear, though, there are no further updates to 4.1 (or 4.2, really), and this has a clear workaround, which is already in the docs. But there are two issues here -- One is what the console disconnectAction is set to (VM->Edit->Console->Disconnect Action). If it's set to "Lock" and the screen doesn't lock, there's a potential problem with the guest agent. The last change to this was in 4.1, with no reports since then (and if SSO is used for the guest agent, it would not be noticable anyway). what is this set to? The other is that some users may be able to open the consoles of other users. The guest-agent tries to auto-login if the screen is locked through SSO. If users do not want other users to be able to open their consoles, strict user checking should be enabled.
Reading the bug again, it seems like the user is interested in the effect of stealing a VM from another user (thus - disable strict checking is enabled). But they are concerned about the case when it is used by an admin user and then a regular user stealing the session and reuses the admin credentials. (In reply to Ryan Barry from comment #9) > It's possible that 4.1 had a regression of > https://bugzilla.redhat.com/show_bug.cgi?id=1297018, but testing would need > to be done > > To be clear, though, there are no further updates to 4.1 (or 4.2, really), > and this has a clear workaround, which is already in the docs. But there are > two issues here -- > > One is what the console disconnectAction is set to > (VM->Edit->Console->Disconnect Action). If it's set to "Lock" and the screen > doesn't lock, there's a potential problem with the guest agent. The last > change to this was in 4.1, with no reports since then (and if SSO is used > for the guest agent, it would not be noticable anyway). what is this set to? I am unsure I understand this comment. If using SSO and Action is set Lock, does it mean that the user should not be able stealing the credentials ever, only the session? Or if the VM has not been released by the previous user, the session and the credentials will be stolen by the new user? I.E. the VM console must be closed to avoid this, but this is actually the same condition as Disable Strict Checking. I.e. if enable the Disable Strict Users Checking, there is no way to prevent the credential stealing today. Ryan, can you confirm my understanding please? > > The other is that some users may be able to open the consoles of other > users. The guest-agent tries to auto-login if the screen is locked through > SSO. If users do not want other users to be able to open their consoles, > strict user checking should be enabled.
(In reply to Marina Kalinin from comment #10) > If using SSO and Action is set Lock, does it mean that the user should not > be able stealing the credentials ever, only the session? Or if the VM has > not been released by the previous user, the session and the credentials will > be stolen by the new user? I.E. the VM console must be closed to avoid this, > but this is actually the same condition as Disable Strict Checking. > I.e. if enable the Disable Strict Users Checking, there is no way to prevent > the credential stealing today. > Ryan, can you confirm my understanding please? > > Right -- if "Disable Strict User Checking" is used, anyone who is logged in is able to see this. If using SSO, and the action is set to lock, guest agent *should* automatically log the user in with his domain account (so it will not be the same as whatever session was previously used). Neither of these is stealing credentials (except a kerberos ticket, but that's not "credentials" as much as authorization for the ticket window), and locking means that the session cannot be stolen even with SSO unless it's the same user
(In reply to Ryan Barry from comment #11) > (In reply to Marina Kalinin from comment #10) > > If using SSO and Action is set Lock, does it mean that the user should not > > be able stealing the credentials ever, only the session? Or if the VM has > > not been released by the previous user, the session and the credentials will > > be stolen by the new user? I.E. the VM console must be closed to avoid this, > > but this is actually the same condition as Disable Strict Checking. > > I.e. if enable the Disable Strict Users Checking, there is no way to prevent > > the credential stealing today. > > Ryan, can you confirm my understanding please? > > > > > Right -- if "Disable Strict User Checking" is used, anyone who is logged in > is able to see this. > > If using SSO, and the action is set to lock, guest agent *should* > automatically log the user in with his domain account (so it will not be the > same as whatever session was previously used). Neither of these is stealing > credentials (except a kerberos ticket, but that's not "credentials" as much > as authorization for the ticket window), and locking means that the session > cannot be stolen even with SSO unless it's the same user Federico, based on the last comment from Ryan, this is something that we should go back to the customer and check. If indeed, the user is different, than things work, just not as obvious. If no, and, in the case of the admin user, a regular user get the admin session, than this is a bug. Can you please check this?
sync2jira
This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly
ok, closing. Please reopen if still relevant/you want to work on it.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days