Script Security Plugin

Benutzerhandbuch

(angepasst aus Informationen über das Template-Plugin im CloudBees Plugins-Leitfaden)

Verschiedene Jenkins-Plugins erfordern, dass Benutzer benutzerdefinierte Skripte definieren, meistens in der Groovy-Sprache, um das Verhalten von Jenkins anzupassen. Wenn alle, die diese Skripte schreiben, Jenkins-Administratoren sind – insbesondere, wenn sie die Berechtigung Overall/RunScripts besitzen, die beispielsweise über den Script Console-Link genutzt wird – dann können sie beliebige Skripte schreiben. Diese Skripte können unter Verwendung derselben API, die auch Plugins zur Verfügung steht, direkt auf interne Jenkins-Objekte verweisen. Solche Benutzer müssen vollständig vertrauenswürdig sein, da sie alles in Jenkins tun können (sogar die Sicherheitseinstellungen ändern oder Shell-Befehle auf dem Server ausführen).

Wenn jedoch einige Skriptautoren „normale Benutzer“ mit nur eingeschränkteren Berechtigungen sind, wie z.B. Job/Configure, ist es nicht angemessen, ihnen die Ausführung beliebiger Skripte zu erlauben. Um eine solche Aufgabenteilung zu unterstützen, kann die Script Security-Bibliothek in verschiedene Feature-Plugins integriert werden. Sie unterstützt zwei verwandte Systeme: Skriptgenehmigung und Groovy-Sandboxing.

Skriptgenehmigung

Das erste und einfachere Sicherheitssystem besteht darin, jede Art von Skript auszuführen, jedoch nur mit Zustimmung eines Administrators. Es gibt eine global geführte Liste genehmigter Skripte, die als nicht bösartig beurteilt wurden.

Wenn ein Administrator eine Konfiguration speichert (z.B. einen Job), werden diejenigen Skripte, die vom Administrator bearbeitet wurden, automatisch genehmigt und sind ohne weiteren Eingriff ausführbar. Für Skripte, die von Benutzern mit geringeren Berechtigungen eingereicht wurden, werden entsprechende Warnungen angezeigt, die darauf hinweisen, dass eine Genehmigung erforderlich ist. Administratoren können diese Skripte über die Skriptgenehmigungs-Konfigurationsseite genehmigen oder indem sie das Skript bearbeiten und speichern. In früheren Versionen des Script Security Plugins konnten Administratoren Skripte, die von nicht privilegierten Benutzern eingereicht wurden, automatisch genehmigen, indem sie sie ohne Änderungen speicherten, aber diese Funktionalität wurde deaktiviert, um Angriffe durch Social Engineering zu verhindern. („Speichern“ bedeutet in der Regel über die Web-UI, könnte aber auch das Hochladen einer neuen XML-Konfiguration über REST oder CLI bedeuten.)

Wenn ein Nicht-Administrator eine Vorlagenkonfiguration speichert, wird geprüft, ob enthaltene Skripte gegenüber einem genehmigten Text geändert wurden. (Genauer gesagt, ob der angeforderte Inhalt jemals zuvor genehmigt wurde.) Falls nicht, wird eine Anfrage zur Genehmigung dieses Skripts einer Warteschlange hinzugefügt. (Eine Warnung wird auch in der Konfigurationsbildschirm-UI angezeigt, wenn der aktuelle Text eines Skripts nicht genehmigt ist.)

Ein Administrator kann nun zu Manage Jenkins » In-process Script Approval gehen, wo eine Liste der auf Genehmigung wartenden Skripte angezeigt wird. Wenn nichts Gefährliches aussehendes angefordert wird, klicken Sie einfach auf Approve, damit das Skript fortan ausgeführt werden kann.

Wenn Sie versuchen, ein nicht genehmigtes Skript auszuführen, schlägt dies einfach fehl, in der Regel mit einer Meldung, die erklärt, dass die Genehmigung aussteht. Sie können es erneut versuchen, sobald das Skript genehmigt wurde. Die Details dieses Verhaltens können je nach dem integrierenden Plugin variieren.

Groovy-Sandboxing

Darauf zu warten, dass ein Administrator jede noch so triviale Änderung an einem Skript genehmigt, kann in einem über Zeitzonen verteilten Team oder bei knappen Fristen inakzeptabel sein. Als alternative Option ermöglicht das Script Security-System die Ausführung von Groovy-Skripten ohne Genehmigung, solange sie sich auf Operationen beschränken, die als inhärent sicher gelten. Diese eingeschränkte Ausführungsumgebung wird als Sandbox bezeichnet. (Derzeit sind keine Sandbox-Implementierungen für andere Sprachen verfügbar, daher müssen alle solche Skripte genehmigt werden, wenn sie von Nicht-Administratoren konfiguriert werden.)

Um in diesen Modus zu wechseln, aktivieren Sie einfach das Kontrollkästchen „Use Groovy Sandbox“ unter dem Eingabefeld des Groovy-Skripts. Sandbox-Skripte können sofort von jedem ausgeführt werden. (Auch von Administratoren, obwohl das Skript denselben Einschränkungen unterliegt, unabhängig davon, wer es geschrieben hat.) Wenn das Skript ausgeführt wird, wird jeder Methodenaufruf, jede Objektkonstruktion und jeder Feldzugriff gegen eine Whitelist genehmigter Operationen geprüft. Wenn eine nicht genehmigte Operation versucht wird, wird das Skript abgebrochen und die entsprechende Jenkins-Funktion kann noch nicht verwendet werden.

Das Script Security Plugin wird mit einer kleinen Standard-Whitelist ausgeliefert, und integrierende Plugins können dieser Liste Operationen hinzufügen (typischerweise Methoden, die für dieses Plugin spezifisch sind).

Sie sind jedoch nicht auf die Standard-Whitelist beschränkt: Jedes Mal, wenn ein Skript fehlschlägt, bevor es eine noch nicht whitelistierte Operation ausführt, wird diese Operation automatisch einer weiteren Genehmigungswarteschlange hinzugefügt. Ein Administrator kann zur selben Seite gehen, die oben für die Genehmigung ganzer Skripte beschrieben wurde, und eine Liste ausstehender Betriebsgenehmigungen sehen. Wenn neben der Signatur einer Operation auf Approve geklickt wird, wird sie sofort zur Whitelist hinzugefügt und für Sandbox-Skripte verfügbar.

Die meisten Signaturen haben die Form method class.Name methodName arg1Type arg2Type…, was einen Java-Methodenaufruf mit einer bestimmten „Empfänger“-Klasse (this), Methodennamen und einer Liste von Argument- (oder Parameter-)Typen angibt. (Die allgemeinste Signatur eines versuchten Methodenaufrufs wird zur Genehmigung angeboten, auch wenn das tatsächliche Objekt, auf dem er aufgerufen werden sollte, von einem spezifischeren Typ war, der diese Methode überschreibt.) Sie können auch staticMethod für statische (Klassen-)Methoden, new für Konstruktoren und field für Feldzugriffe (get oder set) sehen.

Administratoren in sicherheitsrelevanten Umgebungen sollten sorgfältig überlegen, welche Operationen whitelistiert werden sollen. Operationen, die den Zustand persistierter Objekte (wie Jenkins-Jobs) ändern, sollten generell abgelehnt werden. Die meisten getSomething-Methoden sind harmlos.