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

[Aline Manera]

On 03/05/2014 11:49 AM, 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.

It will be hard to implement as we use some python bindings - libvirt, 
yum, apt...
For libvirt we could use libvrt.openAuth() using a sudo user
But how about yum/apt which requires root privileges to run?

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

I personally tend to this solution as well.
My first attempt would be try to run everything under /model and 
mockmodel (which is the real
backend code) as root and start the cherrypy server as normal user.
We need to verify if cherrypy provides some built-in solution for it 
what can help us to solve
this problem.

> 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?).

It is not true.
All the kimchi requests will be performed in the same libvirt connection 
created for the
"kimchi" user.
So instead of manage all the vms on root user it will be on kimchi user.

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

I can't find a connection between those things.
Independent who is running the process (root or kimchi user) the 
authentication will be based on
system configuration (PAM auth)

>
> Please provide your input and ideas!
>
>
>
> Daniel
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>