[Kimchi-devel] [RFC] Github #329: Kimchi must not run as root

Thu Mar 6 12:14:12 UTC 2014

I've tested libvirt Connection authentication in RHEL6.5, Ubuntu and 
Fedora 19. This is the link I've used as guide: 
http://libvirt.org/auth.html#ACL_server_unix_perms

The idea was to make a simple sanity check to verify libvirt 
connectivity using the python binding. In kimchi's root dir:

$ PYTHONPATH=src python
Python 2.7.5 (default, Nov 12 2013, 16:18:42)
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from kimchi.model.libvirtconnection import LibvirtConnection
 >>> libvirt_conn =  LibvirtConnection('qemu:///system')
 >>> conn = libvirt_conn.get()

This test was successful in Fedora 19 (Lenovo T410 laptop) and in Ubuntu 
12.04.3 LTS running in a Intel server. This test FAILED in RHEL6.5 
running in Intel.

In the RHEL6.5 test I've tried leaving the socket open to R+W to all 
(777), which in theory would let anyone open a libvirt connection 
regardless of group permission. Still no good. A non-root user couldn't 
open a libvirt connection:

$ PYTHONPATH=src python
Python 2.6.6 (r266:84292, Nov 21 2013, 10:50:32)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> from kimchi.model.libvirtconnection import LibvirtConnection
 >>> libvirt_conn =  LibvirtConnection('qemu:///system')
 >>> conn = libvirt_conn.get()
libvir: XML-RPC error : authentication failed: Authorization requires 
authentication but no agent is available.
Unable to connect to libvirt.
libvir: XML-RPC error : authentication failed: Authorization requires 
authentication but no agent is available.
Unable to connect to libvirt.

This test runs with no error if using "sudo" to launch the python 
interpreter.

I haven't tested in Suse, but I believe these tests I've made are enough 
to show that we might run into issues if we rely solely in the 
functioning of libvirt across all the distros kimchi supports. A 
solution for that is running all related libvirt calls with root. I 
agree with Royce and Mark that we don't need to run the entire backend 
as root, but for this first interaction I think it's simpler to run all 
the backend as root.

About the frontend/backend separation, I'll look into what Sheldon said. 
Perhaps cherrypy can provide an easier way to communicate both parts.

Daniel

On 03/06/2014 04:51 AM, Sheldon wrote:
> On 03/05/2014 10:49 PM, Daniel H Barboza wrote:
>> Information about the issue:
>>
>> https://github.com/kimchi-project/kimchi/issues/329
>>
>> We had some ideas about it in the last weekly scrum:
>>
>> - creating an user 'kimchi' with a lot of privileges. It is the 
>> simplest of the solutions but
>> implies in a lot of annoyances (different system paths between 
>> distros, libvirt does not
>> work the same way in all distros). There is no tell about the amount 
>> of new bugs and
>> issues that shall emerge from such change.
>>
>> - Separating the UI and the backend. This is my personal favourite 
>> but I believe it is also
>> the hardest. We can implement this by separating frontend and backend
>> as 2 separate cherrypy processes, the backend runs as root and the 
>> frontend runs as a
>> regular user. The communication would be done using the REST API. The 
>> other approach
>> would be the backend running as a regular python daemon, with root 
>> privileges, and
>> kimchi would communicate with it using RPC. I believe the latter is 
>> more elegant and the
>> former is easier to implement.
>>
> from the cherrypy doc, we can customized the components of cherrypy 
> flexibly.
>
> Not sure, we can customized WSGI components or other components.
>
> And the let cherrypy daemon start with root, and it fork one process 
> with root user, let this process
> to handle the libvirt API or other API need root privilege.
>
> The father cherrypy daemon then changes him self user to "kimchi".
> It handle other request does not need root privilege.
>
> Maybe we need process communication between these processes.
>
> That's need to look into the CherryPy mechanism to see the feasibility.
>
>
>
> [DOC]:
> Finally, there is the CORE LAYER, which uses the core API's to construct
> the default components which are available at higher layers. You can 
> think
> of the default components as the 'reference implementation' for CherryPy.
> Megaframeworks (and advanced users) may replace the default components
> with customized or extended components. The core API's are:
>
> * Application API
> * Engine API
> * Request API
> * Server API
> * WSGI API
>
> These API's are described in the CherryPy specification:
>
>> Things to consider:
>>
>> - Distro support: Ubuntu, for example, behaves very different from 
>> Fedora as far as
>> libvirt is concerned. The packaging model (apt-get instead of yum) 
>> differs in support
>> as well. I think it's a fair guess that RHEL 6 and Suse will have 
>> different behavior as well.
>>
>> - VM visibility: in the first idea (different user) only the VMs 
>> created by this specific user
>> would be visible to kimchi, unless we do something about it (tweaking 
>> libvirt configuration
>> perhaps?).
>>
>> - User authentication. Right now the user authentication presented in 
>> kimchi exists simply
>> to authenticate it as a regular user of the host. The owner of the 
>> process will be root, doesn't
>> matter which user logs in (and I guess this is the critical security 
>> flaw we have). Do we need
>> ro rethink the authentication model as well?
>>
>>
>>
>> Please provide your input and ideas!
>>
>>
>>
>> Daniel
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>>
>>
>
>