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

[Sheldon]

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
>
>
>


-- 
Thanks and best regards!

Sheldon Feng(冯少合)<shaohef at linux.vnet.ibm.com>
IBM Linux Technology Center