gistfile1.txt

People mostly want an efficient concurrent pool of workers for OpenERP for SaaS usage where several company databases are hosted on the same OpenERP server (so with Gunicorn or Circus).

But OpenERP has e number of eval where admin user OpenERP can inject arbitrary code. That is especially true when advanced users want to customize their reports which are mostly done using evaling reprting engines.

A typical exploit here would be to eval a database connection to other SaaS databases and do what ever the fuck they want with it (steal the data, hack it, etc...)

So at Akretion we don't do shared hosting of OpenERP because of this obvious security hole, a precaution that is not taken by everybody...

Developing efficient "non evaling" reporting technology (Jinja2 sandbox etc..) can be done but obviously OpenERP won't be rewritten secured overnight (there is no chance that terrible RML technology get that for instance).

So the only way I see unleashed shared OpenERP hosting (way cheaper because it optimize the RAM and CPU sharing) working properly is if we can somehow have the master process to switch say a circus worker user before it serves its request. we would typically read what database this worker has to serve, and then somewhat map the database to a specific unix user and then switch the worker to that user before serving the request.

Can this be achieve safely with Gunicorn or Circus?

Thanks

if we can somehow have the master process to switch say a circus worker user before it serves its request.

Sorry I still don't understand what you mean by 'switch before'

You can start a process with a specific linux user/group, but once it's started it's not possible to change the user for the process.

But your problem looks like a Database connection issue, not a web app one.

The only safe thing to do would be to connect to the DB from OPenERP with a DB user with restricted access.

You can also probably mitigate the risks by having two different open erp web servers, one that is configured to be able to change everything in the DB (A) and one that has a restricted access (B).

Then you can decide in nginx for example, depending on the user, which web app to access, A or B

But that's not to solve at the web process workers

Hello Tarek, thanks for your comment.

Yes this is definitely a "database connection issue": if a python process can connect to n customers databases and if it can eval arbitrary admin user code (yes it can), then you cannot be sure every company will gently connect only to their own database.

So indeed, doing shared OpenERP hosting safely means at the bare minimum isolated db users. Now, if that's a password based connection, if a process can read a password of one database, it can read the password to connect to other databases too. So the only solution then is to have isolated Unix users too.

Indeed, the idea would be to start a worker under a specific user. May be then keeping the worker in a customer wise worker pool could make the cut (not sure if that is easy). Having workers alive for a given amount of time per database and being able to quickly fire a new one is still much better than solutions like having alive (RAM consuming) virtual machines and dynamically addings CPU's or workers to them or even waking the VM's up dynamically (slow).

I like your 2 servers idea, that's may be doable, I'll investigate the idea. Like non admin users access a shared host with a unfied unix user but cannot execute arbitrary connections while a admin tasks are done using a server that is restricted to the right database by some mean.
But an admin user could still upload a malicious report doing request in other databases and wait for a non admin user of the shared host to execute them (so with unlimited databases access privileges), so not as simple as it looks...

And yes, eval and evaling reports isn't your friend ;-)

Thank you for your time anyway.

if a process can read a password of one database, it can read the password to connect to other databases too. So the only solution then is to have isolated Unix users too.

Why is that ? You can have the DB connection info as startup options

But an admin user could still upload a malicious report doing request in other databases and wait for a non admin user of the shared host to execute them (so with unlimited databases access privileges), so not as simple as it looks...

You're getting a bit out of the scope. If you want true isolation, and can't trust admins, don't share the host in the first place.