[Users] NAT configuration

[Sven Kieske]

Well I didn't know the exact background for this code
and I can understand it from a management perspective, but from
a sysadmin perspective it is useless (it does not prevent anything
against an informed "attacker") and may be even lead to false security
assumptions ("nobody can mess with libvirt, it's all authenticated").

But thanks for pointing out the reasoning behind this, I still don't
like it, but I can understand it.

(Funny side fact: the very first thing we did, when we found that
libvirt just allows authenticated access was to find out how to
create our own user, and every admin asks at first: how can I access
libvirt, when something goes wrong?)


Am 05.02.2014 13:45, schrieb Dan Kenigsberg:
> On Wed, Feb 05, 2014 at 09:50:04AM +0000, Sven Kieske wrote:
>> I can confirm that vdsm at ovirt does work.
>>
>> However, I have the strong feeling that
>> the password in /etc/pki/vdsm/keys/libvirt_password
>> is static for all installations.
>>
>> And gerrit proves me right:
>>
>> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/libvirt_password;h=09e60bce9bc401bb8943154f7cb9cb08bd0f49da;hb=refs/heads/master
>>
>> So what is the purpose of authentication when that information
>> is public?
>>
>> I created a BZ for this:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1061639
>>
>> PS: I hope, whoever coded this, feels a little bit ashamed
>> and perhaps buys a good book on writing secure code and reads it..
> 
> I feel ashamed, but not due to the "security" issue here.
> 
> Vdsm uses a unix domain socket to connect to libvirtd. That socket is
> owned by vdsm, so that only vdsm and root can use it. There is no
> security reason to use a password at all.
> 
> I am ashamed for caving in and adding an obfuscation layer, designed
> only to deter local administrators from messing with libvirt under the
> feet of ovirt. This little hurdle does not deter from messing with qemu
> directly, but I suppose that qemu's command line does a good job anyway.
> 
> Red Hat support folks repeatedly claim that this hurdle is more
> effective than putting a release note warning of the dangers in direct
> libvirt access.
> 
> Dan.
> 
> 
> 
> 
> 

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen