[Kimchi-devel] [PATCH v2 0/4] Github #329: "YOU SHALL NOT ... run as root!"

[Zhou Zheng Sheng]

on 2014/04/10 21:32, Daniel H Barboza wrote:
> 
> On 04/10/2014 01:03 AM, Zhou Zheng Sheng wrote:
>> on 2014/04/09 04:50, Daniel Barboza wrote:
>>> From: Daniel Henrique Barboza <danielhb at linux.vnet.ibm.com>
>>>
>>> Changes:
>>> *v2:
>>> - adressed Ramon's comment about the python path in kimchid.in
>>>
>>> This patch series revamps the launch architecture to allow kimchi
>>> to not run as root while being exposed at an open http/https port.
>>>
>>> The solution adopted is using a reverse http proxy (nginx) to make
>>> the 'bridge' between two distinct cherrypy processes, one running
>>> as frontend as a regular user and another running as backend, as root.
>>> The communication with the outside will be done through nginx, running
>>> as a regular user too.
>>>
>>> The changes were heavy in the kimchid script, but the startup and
>>> usage options still the same. User-wise, there shouldn't be any
>>> functional change in the way kimchi works after applying this change.
>>>
>>> Refer to https://github.com/kimchi-project/kimchi/issues/329 for
>>> further information in all the other approaches considered and why
>>> they didn't work out.
>>>
>> Excellent investigation work and nice patch!
>>
>> Since the nginx is already run in non-root mode and forward the request
>> to Kimchi, it seems there is no need to separate kimchi-backend and
>> kimchi-frontend. The solution in this patch series does not improve
>> security but makes the internal of kimchi unnecessarily complicated.
>> This is because nginx forwards requests directly to kimchi-backend and
>> kimchi-frontend. The kimchi-backend and kimchi-frontend are in the same
>> level. To truly make it a secure architecture, the kimchi-backend should
>> sit behind kimchi-frontend, which means the following: nginx ->
>> kimchi-frontend -> kimchi-backend(root). However if we had this nginx ->
>> kimchi-frontend -> kimchi-backend(root), there would be no need to use
>> nginx because kimchi-frontend is non-root already.
>>
>> A simpler solution might be that we can just have one kimchi process
>> listening on localhost, and nginx on 0.0.0.0:8000/8001 and forward all
>> the requests to kimchi.
> 
> I agree that using nginx on top of kimchi is enough to solve the issue. The
> separation of frontend and backend makes sense in the design point of view
> and it was something I had to do in my other attempts, but it wouldn't be
> necessary to solve this particular bug.
> 
>>
>> As regard to your RPC investigations, I'm fully agree with you on the
>> opinion that objects are complex and not all objects are serialize.
>> Consider the complexity and variance of third-party libraries, it's
>> impossible to have an RPC solution that work seamless and transparently
>> between a so-called kimchi-frontend(root) and kimchi-backend.
>>
>> On the other hand. There is a way that RPC should work if we don't have
>> it run transparently. Suppose all models run in kimchi-backend(root),
>> and it exposes a RPC interface explicitly via JSON RPC, D-BUS or
>> whatever. And the objects passed to and returned from this RPC
>> interfaces should be only of the simple kind such as list, string,
>> integer, dict. Then all the controllers run in kimchi-frontend(non-root)
>> and it listens on 0.0.0.0:8000/8001. The controller objects should make
>> explicit RPC calls to the kimcih-backend(root). From my experience,
>> seamless remote objects style of RPC is always a dead end, explicit
>> style of RPC always works.
>>
>> In all, the RPC way may need more work, but it make perfect layered
>> separation between the models and controllers. If we don't have a
>> layered separation between the kimchi-frontend and kimchi-backend, there
>> is no need to start two kimchi process, just one is enough, then have
>> the nginx run in non-root and forward the requests.
> 
> I really liked the RPC idea. I still do. But, as you said, it needs more
> work
> than it looks. I've made several attempts, some of the were successful
> (ex: running run_command through RPC as root) but some parts of the
> code were too complex to put in RPC without reworking.
> 
> Perhaps we can solve this bug  by using the nginx approach (I am ok in
> firing only one cherrypy process as root) and then work gradually in the
> RPC approach? Once we have a full RPC framework we can ditch nginx
> and run kimchi as regular user, firing RPC calls to remote objects that
> run as root. Sounds good?
> 

Yes, I agree. It looks among the most practical ways to solve the
non-root problem.

>>
>>> Daniel Henrique Barboza (4):
>>>    Github #329: kimchid script changes
>>>    Github #329: new launch script and proxy template
>>>    Github #329: server, root and utils changes
>>>    Github #329: config.py.in, spec, readme and makefile changes
>>>
>>>   .gitignore                    |   2 +
>>>   contrib/kimchi.spec.fedora.in |   5 +-
>>>   contrib/kimchi.spec.suse.in   |   3 +
>>>   docs/README.md                |   4 +-
>>>   src/Makefile.am               |   9 +-
>>>   src/kimchi/config.py.in       |   9 +-
>>>   src/kimchi/root.py            |   6 +-
>>>   src/kimchi/server.py          | 100 ++++++++++++---------
>>>   src/kimchi/utils.py           |  42 ++++++++-
>>>   src/kimchid.in                | 202
>>> ++++++++++++++++++++++++++++++++++++------
>>>   src/kimchid_server.in         |  45 ++++++++++
>>>   src/nginx.conf.in             |  69 +++++++++++++++
>>>   12 files changed, 418 insertions(+), 78 deletions(-)
>>>   create mode 100644 src/kimchid_server.in
>>>   create mode 100644 src/nginx.conf.in
>>>
>>
> 


-- 
Thanks and best regards!

Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397