4:49 p.m.
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.
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
9:53 p.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
9:41 a.m.
Talk with Mark about the separation of frontend/backend.
Thanks for him to contribute the following idea:
We think even for backend, not all codes need to run as root, such as
iso search, directory creation and so on.
Gurentee safe may be minimize of use of root.
For previledge cmd: run as super user and limit cmds needed to a single
module.
For libvirt connection: Enable libvirt connection authentication, we can
add sasl user in libvirt for kimchi.
On 2014年03月05日 22:49, 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.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
9:51 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
--
Thanks and best regards!
Sheldon Feng(冯少合)<shaohef(a)linux.vnet.ibm.com>
IBM Linux Technology Center
2:14 p.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
>
>
3:51 p.m.
(ps: this is the same comment I've made in github
https://github.com/kimchi-project/kimchi/issues/329)
I've been working in this issue for about 10 days. The approach I've
chosen was to use RPC to separate the backend (the 'model' and
'mockmodel' classes) running as root from the UI running as regular
user. If done right, the frontend code will use the model classes like
it always did, but these classes will have root privilege because they
were instanced by the RPC server (which runs as root).
Now I'll explain why it didn't work so far, lol. The RPC I've been using
is called PyRO (https://pypi.python.org/pypi/Pyro4). It's rather simple
to make it work and at first solved the problem. As far as I could tell
the UI, launched as regular user, was dealing with the RPC model object
just fine. However the model test (test/test_model.py) was failing in a
test called test_asynctask for a reason that at first I didn't
understand. After further investigation, the core reason was that this
RPC has limitations about the python objects it can provide across the
wire using serialization. The Model class does not contain elemental
python structures only. It contains threads, for example. And the
asynctask.py (invokd by test_asynctask AND uses threads) was not
behaving as it should, causing non-trivial errors in test_model (thus
wouldn't be usable by the UI as well).
My attempts to try to fix it weren't promising. I've tried a serializer
that is more generic to transmit the RPC, but this requires an update of
PyRO version. The version that Fedora 19 installs by default is 4.12, I
needed the latest (4.24). After the update I've been facing a lot of
misbehavior from the RPC, things that were working weren't working
anymore and so on. Then it occurred to me that this wouldn't be
acceptable (or would be a huge pain) to maintain in all the distros
kimchi supports, such as RHEL6.5. I do not believe we can rely on
another 3rd party software behavior across all the supported distros for
the proper behavior of kimchi. And there's also the uncertainty that
even with the latest version, there's no guarantee that the model
classes would get too complex to be "serializable" by the RPC and sooner
of later stop working properly.
That said, I'm putting this RPC effort to a halt. What I've started to
do is try to launch a second cherrypy process, running as root, running
only the backend classes (no UI enabled), to provide the frontend with
the info it can't get from the regular user. I believe this approach
will require more work, but it's certain to work across all distros
without relying in another 3rd party software.
As always, any help/tips are appreciated :)
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.
- 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.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
4047
days inactive
4055
days old
5 comments
4 participants
participants (4)
-
Aline Manera -
Daniel H Barboza -
Royce Lv -
Sheldon