RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 570526 - vdsm libvirt - verify rw unix socket with vdsm's key
Summary: vdsm libvirt - verify rw unix socket with vdsm's key
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: vdsm
Version: 6.0
Hardware: All
OS: Linux
high
medium
Target Milestone: rc
: ---
Assignee: Dan Kenigsberg
QA Contact: Daniel Paikov
URL:
Whiteboard:
Depends On: 658144
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-04 16:19 UTC by Dan Kenigsberg
Modified: 2016-04-26 14:40 UTC (History)
14 users (show)

Fixed In Version: vdsm-4.9-37.el6
Doc Type: Enhancement
Doc Text:
VDSM now configures libvirt so that connection to its local read-write UNIX domain socket is password-protected by SASL. The intention is to protect virtual machines from human errors of local host administrators. All operations that may change the state of virtual machines on a Red Hat Enterprise Virtualization-controlled host must be performed from Red Hat Enterprise Virtualization Manager.
Clone Of:
Environment:
Last Closed: 2011-08-19 15:24:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Dan Kenigsberg 2010-03-04 16:19:41 UTC
mgmt is worried of local root using virsh to mess with libvirt below vdsm feet. conigure libvirt to verify connection to its rw unix socket with vdsm's key, so that only vdsm (or an admin impersonating to vdsm) could open a rw connection to libvirt.

Comment 2 Itamar Heim 2010-03-09 08:26:45 UTC
moving to next version since past exception only date

Comment 3 Daniel Veillard 2010-03-09 15:39:37 UTC
Seems to me this would make access for monitoring though libvirt impossible.
In any case that sounds fairly wromg to me, if someone had root acccess on
the box all bets are off, and libvirtd access can be worked around by
just restarting libvirtd -> trying to put a level of protection there
is guaranteed useless.

Daniel

Comment 4 Hugh Brock 2010-03-09 16:04:30 UTC
Well, without blocking on the uselessness (or not) of the request, it is *doable* with libvirt, is it not? If so, how?

Comment 5 Dan Kenigsberg 2010-03-09 16:19:04 UTC
Dan, would you remind me your suggestion how this can be done with current libvirt auth configuration option?

Comment 6 Daniel Berrangé 2010-03-15 11:04:51 UTC
In /etc/libvirt/libvirtd.conf


  auth_unix_rw = "sasl"


Then in /etc/sasl2/libvirt.conf  ensure

  mech_list: digest-md5
  sasldb_path: /etc/libvirt/passwd.db

(These are the default SASL config so should not need changing)

  # echo "mypassword" | saslpasswd2 -p -a libvirt vdsm


Now when VDSM connects to libvirt, it must supply 'vdsm' and 'mypassword' to the connect method auth callback

Apps which connect to libvirt in read-only mode continue unchanged

Further info here

  http://libvirt.org/auth.html#ACL_server_username

Comment 7 RHEL Program Management 2010-05-27 18:00:12 UTC
This feature request did not get resolved in time for Feature Freeze
for the current Red Hat Enterprise Linux release and has now been
denied. You may re-open your request by requesting your support
representative to propose it for the next release.

Comment 8 Dan Kenigsberg 2010-09-19 10:27:49 UTC
Daniel, after a long delay, I am trying to implement your suggestion, but I fail to make sasl authentication work. The following script ends with

plain open failed
openAuth succeeded

even though the auth credentials are non-existing. Any idea why?


!#/usr/bin/python

import libvirt

#uri = "qemu://localhost/system?no_verify=1"
uri = "qemu://danken-temp.qa.lab.tlv.redhat.com/system"

#auth = [[], lambda x,y: None, None ]
auth = [[], None, None]

try:
    conn = libvirt.open(uri, 0)
except:
    print "plain open failed"

conn = libvirt.openAuth(uri, auth, 0)

if conn.getCapabilities():
    print "openAuth succeeded"

Comment 9 Daniel Berrangé 2010-09-20 09:52:53 UTC
> uri = "qemu://danken-temp.qa.lab.tlv.redhat.com/system"

This is telling libvirt to connect to the TLS-enabled socket. The instructions I gave above, show how to setup SASL on the UNIX socket.  If you want to do this over TCP, then also set

 auth_tls='sasl'
 auth_tcp='sasl'  (for the non-TLS enabled socket)

Comment 10 Dan Kenigsberg 2010-09-21 15:53:46 UTC
Thanks (though this still does not explain why simple open failed while silly openAuth succeeded).

Anyway, with uri = "qemu:///system" openAuth is failing too - no matter what I give for the auth list.

Does the following client-side debug help you find what I'm doing wrong?
11:48:08.759: debug : virInitialize:341 : register drivers
11:48:08.759: debug : virRegisterDriver:929 : registering Test as driver 0
11:48:08.759: debug : virRegisterNetworkDriver:735 : registering Test as network driver 0
11:48:08.759: debug : virRegisterInterfaceDriver:766 : registering Test as interface driver 0
11:48:08.759: debug : virRegisterStorageDriver:797 : registering Test as storage driver 0
11:48:08.759: debug : virRegisterDeviceMonitor:828 : registering Test as device driver 0
11:48:08.759: debug : virRegisterSecretDriver:859 : registering Test as secret driver 0
11:48:08.759: debug : virRegisterNWFilterDriver:890 : registering Test as network filter driver 0
11:48:08.759: debug : virRegisterDriver:929 : registering ESX as driver 1
11:48:08.759: debug : virRegisterInterfaceDriver:766 : registering ESX as interface driver 1
11:48:08.759: debug : virRegisterNetworkDriver:735 : registering ESX as network driver 1
11:48:08.759: debug : virRegisterStorageDriver:797 : registering ESX as storage driver 1
11:48:08.759: debug : virRegisterDeviceMonitor:828 : registering ESX as device driver 1
11:48:08.759: debug : virRegisterSecretDriver:859 : registering ESX as secret driver 1
11:48:08.759: debug : virRegisterNWFilterDriver:890 : registering ESX as network filter driver 1
11:48:08.759: debug : virRegisterDriver:929 : registering remote as driver 2
11:48:08.759: debug : virRegisterNetworkDriver:735 : registering remote as network driver 2
11:48:08.759: debug : virRegisterInterfaceDriver:766 : registering remote as interface driver 2
11:48:08.759: debug : virRegisterStorageDriver:797 : registering remote as storage driver 2
11:48:08.759: debug : virRegisterDeviceMonitor:828 : registering remote as device driver 2
11:48:08.759: debug : virRegisterSecretDriver:859 : registering remote as secret driver 2
11:48:08.759: debug : virRegisterNWFilterDriver:890 : registering remote as network filter driver 2
11:48:08.772: debug : virConnectOpenAuth:1471 : name=qemu:///?no_verify=1, auth=0x7fff07b45e10, flags=0
11:48:08.772: debug : do_open:1206 : name "qemu:///?no_verify=1" to URI components:
  scheme qemu
  opaque (null)
  authority (null)
  server (null)
  user (null)
  port 0
  path /

11:48:08.772: debug : do_open:1216 : trying driver 0 (Test) ...
11:48:08.772: debug : do_open:1222 : driver 0 Test returned DECLINED
11:48:08.772: debug : do_open:1216 : trying driver 1 (ESX) ...
11:48:08.772: debug : do_open:1222 : driver 1 ESX returned DECLINED
11:48:08.772: debug : do_open:1216 : trying driver 2 (remote) ...
11:48:08.772: debug : doRemoteOpen:570 : proceeding with name = qemu:///
11:48:08.773: debug : remoteIO:9748 : Do proc=66 serial=0 length=28 wait=(nil)
11:48:08.773: debug : remoteIO:9823 : We have the buck 66 0x271aca0 0x271aca0
11:48:08.773: debug : remoteIODecodeMessageLength:9179 : Got length, now need 64 total (60 more)
11:48:08.773: debug : remoteIOEventLoop:9674 : Giving up the buck 66 0x271aca0 (nil)
11:48:08.773: debug : remoteIO:9854 : All done with our call 66 (nil) 0x271aca0
11:48:08.773: debug : remoteAuthSASL:6842 : Client initialize SASL authentication
11:48:08.775: debug : do_open:1222 : driver 2 remote returned ERROR
11:48:08.775: debug : virUnrefConnect:294 : unref connection 0x24c5780 1
11:48:08.775: debug : virReleaseConnect:249 : release connection 0x24c5780
libvir: Remote error : authentication failed: Failed to create SASL client context: -7 (invalid parameter supplied)
Traceback (most recent call last):
  File "bla.py", line 100, in <module>
    conn = libvirt.openAuth(uri, auth, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 111, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirt.libvirtError: authentication failed: Failed to create SASL client context: -7 (invalid parameter supplied)

Comment 11 Dan Kenigsberg 2010-10-09 17:46:33 UTC
Ok, the following script works just fine with tcp connection, but fails over unix domain sockets. Is that related to https://www.redhat.com/archives/libvir-list/2010-September/msg00240.html ? If so, we should probably backport it into RHEL6.

import libvirt

uri = "qemu+tcp://localhost/system"
#uri = "qemu:///system"

def req(credentials, user_data):
    for cred in credentials:
        if cred[0] == libvirt.VIR_CRED_AUTHNAME:
            cred[4] = 'vdsm'
        elif cred[0] == libvirt.VIR_CRED_PASSPHRASE:
            cred[4] = 'mypassword'
    return 0

auth = [[libvirt.VIR_CRED_AUTHNAME, libvirt.VIR_CRED_PASSPHRASE], req, None]

conn = libvirt.openAuth(uri, auth, 0)

if conn.getCapabilities():
    print "openAuth succeeded"

Comment 12 Daniel Berrangé 2010-10-11 10:14:55 UTC
Yes, it appears as though we either broke SASL over UNIX sockets at some point, or only the Kerberos SASL plugin ever worked over UNIX sockets.

Comment 17 Dan Kenigsberg 2010-11-30 19:32:16 UTC
make sure that:
- vdsm has rw access to libvirt
- no one else has rw access; even root, as long as she does not use vdsm's key.
- everyone and his uncle haw read-onlu access to libvirt.
-

Comment 18 Yaniv Kaul 2010-11-30 22:28:59 UTC
pmatouse - I assume you'll be looking at this as well.

Comment 20 Haim 2011-02-03 07:48:00 UTC
verified on latest vdsm (4.9-47).

vdsm and libvirt communicating with SASL, and when one wants to use libvirt 
API (virsh), he's required to type in special key.
on startup, vdsm configures libvirt to work with SASL, goes as follows: 

auth_unix_rw="sasl" # by vdsm



[root@rhev-i32c-04 ~]# virsh list
Please enter your authentication name:

only read only access is allowed; which goes as follows: 

[root@rhev-i32c-04 ~]# virsh -r  list
 Id Name                 State
----------------------------------
 11 FC-rhel6-001         running
 12 FC-rhel6-002         running
 13 FC-rhel6-003         running
 14 FC-rhel6-005         running
 15 FC-rhel6-004         running

[root@rhev-i32c-04 ~]#

this is not fully secured as vdsm stores the password on the host, which means root user can dig and find it, but i guess this was the requirement.

Comment 22 Dan Kenigsberg 2011-12-01 12:38:03 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Vdsm now configures libvirt so that connection to its local read-write unix domain socket is password-protected by SASL. The intention is to protect VMs from human errors of local host admin. All operations that may change the state of virtual machines on a RHEV-controlled host must be performed from RHEV-M.

Comment 23 Martin Prpič 2011-12-01 17:23:23 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-Vdsm now configures libvirt so that connection to its local read-write unix domain socket is password-protected by SASL. The intention is to protect VMs from human errors of local host admin. All operations that may change the state of virtual machines on a RHEV-controlled host must be performed from RHEV-M.+VDSM now configures libvirt so that connection to its local read-write UNIX domain socket is password-protected by SASL. The intention is to protect virtual machines from human errors of local host administrators. All operations that may change the state of virtual machines on a Red Hat Enterprise Virtualization-controlled host must be performed from Red Hat Enterprise Virtualization Manager.


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