Avoid managing network parameters in addons

"By uploading a new version of the module": Surely the access to upload or activate new modules has to be severely restricted to admins anyway?
The request does not make sense to me...
A+. Sean.

@Sean :
Thank you for your comment. However I'm not sure you got the point.
Which admin do you refer to ? database admin ? super admin ? unix admin ?
Why a database admin or super admin is trustful ?
Why should he be capable of hacking another server ?
regards
Dominique

17-june-2010 : Unfortunatly, seems this blueprint is not considered in V6, and security hole will remain wide open for next two years. Too bad !
Dominique

-----------------
18-jun-2010:
I tend to agree with Sean here, even if you consider multi-tenant deployments (typically SaaS).
Let's consider 2 different roles:
  1) the OpenERP admin of any OpenERP database in any OpenERP deployment, typically the highest role you will grant to a customer, even in a multi-tenant system
  2) the unix sysadmin (that is, root!) of the machine where OpenERP is deployed, typically an employee of the SaaS vendor

Role 1:
I think your main concern here is that Role 1 is able to upload new modules that could have a global effects on the OpenERP instance, even if her access is normally local to a single OpenERP database. This is indeed the case, but you will agree that it matters mostly in a multi-tenant environment.
In a multi-tenant environment, restricting access to "network parameters" in modules is hardly a sufficient answer. If you look at the technical side, we don't run the modules in a 'sandbox' that restricts the extent of what they can do. This would make module development for contributors quite a bit more complicated, and would severely cripple the system by default.
What if a partner needs to develop a module that accesses system resources to interface with dedicated hardware (think printers, weighing machine, anything...), or needs to write files into a remote network disk for some reason, etc. You cannot provide a 'restricted' API that covers ALL the possible ways a module may want to to access the system in a perfectly valid manner. And if you don't implement such a global sandbox, then don't even think about restricting 'network parameters' or anything else, it's like leaving a bank's gold vault open all the time with a sign that says "Please don't steal the gold, a bank employee will provide a withdrawal service during business hours. Thank you."

So yes, a module could technically run any kind of system code, even accessing the filesystem, other databases, etc, all using the same 'unix' user OpenERP is running. That's a great advantage, and if you are afraid of that, don't install untrusted modules in your systems, that's all. We do have a list of official and extra addons that are safe for this purpose.

Now obviously in public SaaS mode, you cannot trust the admins of customer databases, so you have to implement some kind of restriction to keep the system safe. This is what we do in ODOO for example, by only allowing certified modules, and disabling the import module wizard, and it simply makes sense. Given the above you see that there's no way around this, short of crippling OpenERP in general.

Role 2:
Now role 2 is a completely different matter. The rule is in fact simple: you have to trust the sysadmin of the machine, because he's root and can do basically anything. It doesn't even make sense to try to restrict what the sysadmin can do, because by definition he is not restricted. And this is true in multi-tenant too. As soon as we talk about real system logins on the machine where the server is deployed, the usual permission model of the operating system applies, and we should only see OpenERP as a regular program running on the system, so use your common sense there.

I hope this clarifies our view on this, and explains why there's no 'security hole' to patch here, it's just the way OpenERP works, you just need to understand it and use it properly to keep your system safe, as for any other software out there.

Olivier Dony
-----------------
18 june 2010
Hello Olivier,

Thank you for taking time considering my last comment on this blueprint and giving detailed feed-back. You understand the point and provide valid arguments, some are factual.

Separating configuration and code is a so obvious rule that it should never be done else way and therefore this blue-print should have been implemented since the beginning . Nevertheless I won't argue on this, because you didn't answer to the blueprint content but reacted on the keyword "security hole" of my sad and off-topic comment, and I'll dig this point a little bit further with you.

To replace this discussion in its context, then I declare <shout>"THERE IS NO SECURITY HOLE IN ODOO" </shout>. I hope everybody feels better now. A feature is not a security hole if you prevent its use, I admit my last comment was off-topic in fact. I did it, convinced that nobody would read it. I was wrong.

About the Roles 1 and 2 you describe, may I add this precision :
• to save/restore his database from the gui, the customer must know about the super-admin password which is kept in the server configuration file.

Let's first list points on which I agree :
- openerp super-admin and sysadmin are two separate roles.
- by openerp design, a module is not jailed and can attempt to do nasty things. My blueprint was not about changing this.
- odoo is protected by restriction.
- protecting a system against sys-admin makes no sens.

Nevertheless, I must disagree on two assumptions you made. I'll detail them below :

First wrong assumption, multi-tenant system is for Saas only.
This is not true. Multi-tenant system is a wonderful feature for all users. All my customers get a three instance server : production, training and test. In real life you appreciate to train you users and you test modules on separated instances, to replicate and move your database as you want.. In addition, you can prefer multi-tenant system rather than multi-company feature if you don't need it. In any case, running a multi-tenant system requires an ugly patch of the code in document module, which you seem to consider as normal.

Second wrong assumption, multi-tenant system can safely share a single unix user if you block module upload.
I don't think so, do you ? All my openerp servers run separate and limited unix users and use postgresql separate roles.
What prevents me to print in a rml report the super-user password of my neighbor (../../../../your_conf_file) ? I don't need upload right to do this.
If I can, then this discussion was useful. :-(

Regarding your conclusion :
- "there's no 'security hole'" : I hope so and honor is safe.
- "the way OpenERP works, you just need to understand it" : Is writing a blue-print still useful ? At fisrt, this blue-print was written upon a request from Tiny ;-)

my conclusion :
Putting ftp parameters in config file instead of hard-coding them would probably take less time than arguing on why this is not useful. ;-) I still don't know what your position is regarding the content of the blue-print.
regards

--------------------------------------------------------
2010-09-08:

Dominique,

I'm afraid I'm not following you there... it seems to me we are quite on-topic, unless you want to discard everything but the first sentence of your blueprint description. If that is really the case, then we can close this blueprint, as FTP params have been added to server config a while ago (see bug 515507 and the related code revisions), and you can stop reading now.

However when reading again the blueprint description it really looks like you had deeper security concerns in mind.
Now you say you understand the inherent freedom all addons are granted by design (and that your point is not about changing this), so it follows that:

1) Yes, of course we can put FTP params in the server config, as we did (because it needed to be configurable, not because it somehow makes the server immune to other threats)

2) No, doing so does not help guarantee that "protocol parameters should be defined exclusively by the system administrator and shouldn't be modified after server start by any means"...
Even if we moved the whole FTP code in the server, because addons are not sandboxed by design, there's no way to guarantee anything as long as untrusted ones can be installed, period.

So:
 - either you don't allow installing untrusted addons, and then I wonder what the rest of this blueprint is about
 - or you do want to allow untrusted addons, and then this blueprint can't guarantee anything

In both cases: what's the point?

Now don't get me wrong, I think it might make sense eventually to provide a better abstraction API to addons, and network management could be a part of it, but that's a totally different blueprint and scope, and one not mainly driven by security concerns.

To conclude: were we on-topic after all, or does it still look like "pure denial" to you?

Olivier
------------------------------------------------------------