Pourquoi PL / Python n'est pas approuvé?

11

Selon les documents:

PL / Python est uniquement disponible en tant que langage "non fiable", ce qui signifie qu'il n'offre aucun moyen de restreindre ce que les utilisateurs peuvent y faire et est donc nommé plpythonu. Une variante plpython de confiance pourrait devenir disponible à l'avenir si un mécanisme d'exécution sécurisé est développé en Python.

Pourquoi est-il difficile de développer un mécanisme d'exécution sécurisé pour Python mais pas pour d'autres langages tels que Perl?

postgresql security python plpython foobar0100
la source

Réponses:

13

Cela a à voir avec le modèle d'objet de Python - il y a toujours un moyen d'obtenir une référence à des objets qui pourraient être dangereux. Voir la documentation du module rexec et le chapitre sur l'exécution restreinte de la documentation pour quelques informations sur les problèmes, ainsi que:

Les limitations n'ont rien à voir avec PostgreSQL lui-même, elles sont inhérentes à l'implémentation de l'interpréteur CPython ou peut-être même au langage Python lui-même.

Certaines autres langues ont vérifié les temps d'exécution, comme Perl, Java, JavaScript et Lua. La plupart d'entre eux ont été confrontés à une série de problèmes de sécurité car ces environnements d'exécution confinés sont très difficiles à protéger contre tous les exploits possibles de jailbreak.

Il n'y a vraiment rien qui empêche PostgreSQL d'ajouter un interpréteur Python semi-fiable, car rexec est "assez bon" à de nombreuses fins. Cependant, PostgreSQL n'a pas tendance à aimer seulement - la plupart du temps - assez bien assez bien. Il ne serait probablement accepté que s'il est marqué comme superutilisateur uniquement, mais vous pouvez toujours lui accorder l'accès à des utilisateurs spécifiques. Ce serait mieux que Python non fiable.

Personnellement, je pense que PL / V8 ou similaire est l'avenir ici, et j'aimerais qu'il évolue vers un support de base.

J'ai également vaguement exploré l'idée d'un Mono de confiance qui peut charger des assemblys «sûrs» écrits en C #, VB.NET, IronPython, ou quoi que ce soit, mais je n'ai pas pu faire grand-chose sur ce sujet.

Craig Ringer
la source
Je n'ai jamais vu cela comme une raison pour laquelle il est considéré comme non fiable. Par défaut, Java, V8, TCL, R et autres sont considérés comme non fiables. La seule raison pour laquelle Perl est digne de confiance, c'est parce qu'ils expédient une version spéciale de Perl avec PostgreSQL postgresql.org/docs/11/plperl-trusted.html
TheSteve0
1
@ TheSteve0 Vous ne l'avez peut-être pas vu comme tel, mais c'est pourquoi il en est ainsi. PostgreSQL avait auparavant plpythonu, et il a été supprimé après la dépréciation du rexecmodule Python comme intrinsèquement non sécurisé, comme indiqué ci-dessus. J'imagine qu'un plpython utilisant PyPi pourrait être en mesure de fournir un mode restreint que Pg pourrait ensuite utiliser. Je n'ai pas cherché à voir s'il y avait beaucoup de travail. Vous avez également tort sur une "version spéciale de confiance de Perl" - c'est en fait parfaitement Perl ordinaire, le même interprète est utilisé pour plperl et plperlu. La différence est la configuration d'exécution.
Craig Ringer
@ TheSteve0 plperl configure différemment les instances de l'interpréteur Perl au moment de l'exécution. Voir plperl.c pour les détails gorey, en particulier pp_require_safeet plperl_trusted_init. Je n'en sais pas assez pour avoir une grande opinion sur la véritable sécurité de l'exécution restreinte de Perl. Je préférerais voir une version de confiance de Lua ou obtenir une meilleure prise de conscience et adoption, un interprète JavaScript de confiance. Mais ce que nous avons, c'est pour l'instant.
Craig Ringer
@ TheSteve0 BTW, la JVM Java utilisant du code Java ou Groovy, ou la VM Mono utilisant C # ou VB.NET semble avoir beaucoup de sens car les deux runtimes ont des fonctionnalités robustes de sandbox et de gestion de la sécurité. SecurityManager de Java par exemple. Mais malheureusement, les deux runtimes utilisent des modèles d'exécution lourds de démarrage, filetés, partagés tout par défaut qui conviennent mal au processus léger de PostgreSQL shared-nothing-by-default fork () - sans modèle exec. Ils ne sont pas vraiment capables de fork (). Nous ne pouvons donc pas les utiliser très efficacement dans PostgreSQL.
Craig Ringer
Les lecteurs ici pourraient être intéressés par ce problème GitHub que j'ai fait sur le projet Mono concernant l'utilisation de Mono dans les exécutions de fork (): github.com/mono/mono/issues/11857
Craig Ringer