Warum ist PL / Python nicht vertrauenswürdig?

Laut den Dokumenten:

PL / Python ist nur als "nicht vertrauenswürdige" Sprache verfügbar, was bedeutet, dass es keine Möglichkeit bietet, die Möglichkeiten der Benutzer einzuschränken, und daher den Namen plpythonu trägt. Eine vertrauenswürdige Variante von plpython wird möglicherweise in Zukunft verfügbar sein, wenn in Python ein sicherer Ausführungsmechanismus entwickelt wird.

Warum genau ist es schwierig, einen sicheren Ausführungsmechanismus für Python zu entwickeln, nicht jedoch für andere Sprachen wie Perl?

— foobar0100
quelle

Es hat mit dem Objektmodell von Python zu tun - es gibt immer eine Möglichkeit, einen Verweis auf Objekte zu erhalten, die unsicher sein könnten. In der Dokumentation zum rexec-Modul und im Kapitel zur eingeschränkten Ausführung der Dokumente finden Sie einige Informationen zu den Problemen sowie:

Die Einschränkungen haben nichts mit PostgreSQL selbst zu tun, sie sind der CPython-Interpreter-Implementierung oder möglicherweise sogar der Python-Sprache selbst eigen.

Einige andere Sprachen wie Perl, Java, JavaScript und Lua haben die Laufzeiten überprüft. Die meisten von ihnen hatten mit einer Reihe von Sicherheitsproblemen zu kämpfen, da solche eingeschränkten Ausführungsumgebungen nur sehr schwer vor allen möglichen Jailbreak-Exploits zu schützen sind.

Nichts hindert PostgreSQL wirklich daran, einen semitrusted Python-Interpreter hinzuzufügen, da rexec für viele Zwecke "gut genug" ist. PostgreSQL neigt nicht dazu, nur - meistens - irgendwie - gut genug - vielleicht zu sein. Es wird wahrscheinlich nur akzeptiert, wenn es als Nur-Superuser markiert ist, aber Sie können dann immer bestimmten Benutzern Zugriff darauf gewähren. Es wäre besser als nicht vertrauenswürdiges Python.

Persönlich denke ich, dass PL / V8 oder ähnliches die Zukunft hier ist, und würde gerne sehen, dass es in Richtung Kernunterstützung geht.

Ich habe auch vage die Idee eines vertrauenswürdigen Mono untersucht, das "sichere" Assemblys laden kann, die in C #, VB.NET, IronPython oder was auch immer geschrieben sind, aber nicht viel zu diesem Thema tun konnten.

— Craig Ringer
quelle

Ich habe dies nie als Grund dafür gesehen, warum es als nicht vertrauenswürdig angesehen wird. Standardmäßig gelten Java, V8, TCL, R und andere als nicht vertrauenswürdig. Der einzige Grund, warum Perl vertrauenswürdig ist, ist, dass sie eine spezielle vertrauenswürdige Version von Perl mit PostgreSQL postgresql.org/docs/11/plperl-trusted.html

— TheSteve0

@ TheSteve0 Du hast es vielleicht nicht als solches gesehen, aber deshalb ist es so. PostgreSQL hatte früher plpythonu und wurde nach der Ablehnung des Python- rexecModuls als inhärent unsicher entfernt, wie oben verlinkt. Ich stelle mir vor, dass eine plpython mit PyPi möglicherweise einen eingeschränkten Modus liefern kann, den Pg dann verwenden kann. Ich habe nicht nachgesehen, ob es viel Arbeit gibt. Sie irren sich auch über eine "spezielle vertrauenswürdige Version von Perl" - es ist in der Tat ganz normales Perl, der gleiche Interpreter wird für plperl und plperlu verwendet. Der Unterschied ist die Laufzeitkonfiguration.

— Craig Ringer

@ TheSteve0 plperl konfiguriert die Perl-Interpreter-Instanzen zur Laufzeit unterschiedlich. Siehe plperl.c für die Details, insbesondere pp_require_safeund plperl_trusted_init. Ich weiß nicht genug, um eine Meinung über die wahre Sicherheit einer eingeschränkten Perl-Ausführung zu haben. Ich würde es vorziehen, eine vertrauenswürdige Version von Lua zu sehen oder eine bessere Mindshare und Akzeptanz zu erhalten, einen vertrauenswürdigen JavaScript-Interpreter. Aber was wir haben, ist vorerst plperl.

— Craig Ringer

@ TheSteve0 Übrigens, die Java-JVM mit Java- oder Groovy-Code oder die Mono-VM mit C # oder VB.NET scheinen sehr sinnvoll zu sein, da beide Laufzeiten über robuste Sandbox- und Sicherheitsverwaltungsfunktionen verfügen. Javas SecurityManager zum Beispiel. Leider verwenden beide Laufzeiten Heavyweight-Startup-, Threaded- und Shared-Everything-Standard-Ausführungsmodelle, die schlecht zu PostgreSQLs leichtgewichtigem Prozess Shared-Nothing-By-Default-Fork () passen - ohne Exec-Modell. Sie sind nicht wirklich fork () fähig. Daher können wir sie in PostgreSQL nicht sehr effektiv einsetzen.

— Craig Ringer

Die Leser hier könnten an dieser GitHub-Ausgabe interessiert sein, die ich im Rahmen des Mono-Projekts zur Verwendung von Mono in Fork () -Laufzeiten erstellt habe: github.com/mono/mono/issues/11857

— Craig Ringer