Bug 570526
Summary: | vdsm libvirt - verify rw unix socket with vdsm's key | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Dan Kenigsberg <danken> |
Component: | vdsm | Assignee: | Dan Kenigsberg <danken> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Daniel Paikov <dpaikov> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 6.0 | CC: | apevec, bazulay, berrange, cpelland, hateya, hbrock, iheim, plyons, pmatouse, Rhev-m-bugs, riek, snagar, veillard, ykaul |
Target Milestone: | rc | Keywords: | FutureFeature |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2011-08-19 15:24:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 658144 | ||
Bug Blocks: |
Description
Dan Kenigsberg
2010-03-04 16:19:41 UTC
moving to next version since past exception only date 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 Well, without blocking on the uselessness (or not) of the request, it is *doable* with libvirt, is it not? If so, how? Dan, would you remind me your suggestion how this can be done with current libvirt auth configuration option? 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 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. 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" > 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)
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) 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" 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. 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. - pmatouse - I assume you'll be looking at this as well. 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. 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. 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. |