Jenkins-Plugin, das Skriptgenehmigungsworkflows und Groovy-Sandboxing bereitstellt, um eine sichere Skriptausführung zu erzwingen, mit ACL-bewussten Berechtigungsprüfungen und Whitelist-Verwaltung für Administratoren.
(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.
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.
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.
Beachten Sie jedoch, dass selbst einige „Getter“-Methoden darauf ausgelegt sind, bestimmte Berechtigungen zu prüfen
(unter Verwendung einer ACL: Access Control List), während Skripte oft von einem System-Pseudo-Benutzer ausgeführt werden,
dem alle Berechtigungen gewährt werden. So ist beispielsweise method hudson.model.AbstractItem getParent
(welches den Ordner oder die Jenkins-Wurzel, die einen Job enthält, abruft) an sich harmlos, aber der mögliche Folgeaufruf
method hudson.model.ItemGroup getItems (welches Jobs nach Namen innerhalb eines Ordners auflistet) prüft
Job/Read. Dieser zweite Aufruf wäre gefährlich, wenn er bedingungslos whitelistiert würde, da dies bedeuten würde,
dass ein Benutzer, der Job/Create in einem Ordner hat, zumindest einige Informationen aus beliebigen Jobs in diesem Ordner
lesen könnte, selbst aus solchen, die gemäß einer projektbasierten Autorisierungsstrategie versteckt sein sollten;
es würde ausreichen, einen Job im Ordner zu erstellen, der ein Groovy-Skript wie dieses enthält (Details würden je nach integrierendem Plugin variieren):
println("I sniffed ${thisjob.getParent().getItems()}!");
Bei der Ausführung würde die Skriptausgabe zumindest die Namen von angeblich geheimen Projekten anzeigen.
Ein Administrator kann stattdessen auf Approve klicken, unter der Annahme einer Berechtigungsprüfung für
getItems; dies erlaubt den Aufruf, wenn er als tatsächlicher Benutzer ausgeführt wird (falls das integrierende Plugin dies jemals tut),
während er verboten ist, wenn er als Systembenutzer ausgeführt wird (was typischer ist). In diesem Fall ist getItems
tatsächlich so implementiert, dass es nur die Jobs zurückgibt, auf die der aktuelle Benutzer Zugriff hat. Wenn also
im ersteren Fall (als bestimmter Benutzer) ausgeführt, zeigt die Beschreibung nur die Jobs an, die sie ohnehin sehen könnten.
Diese erweiterte Schaltfläche wird nur für Methodenaufrufe (und Konstruktoren) angezeigt und sollte nur verwendet werden,
wo Sie wissen, dass Jenkins eine Berechtigungsprüfung durchführt.
Vollständige Beispielintegration
Für eine typische Groovy-Integration, bei der Sie dem Benutzer die Möglichkeit bieten, entweder die Skriptgenehmigung
oder die Sandbox zu verwenden, ändern Sie das String-wertige Skriptfeld Ihres Describable in ein SecureGroovyScript-Feld.
Rufen Sie in Ihrem Konstruktor vor dem Speichern des Werts configuringWithKeyItem auf (wenn es nur ein solches Skript pro Top-Level-Element geben kann)
oder configuringWithNonKeyItem (wenn es mehrere geben könnte). Das Konfigurationsformular sollte
<f:property field="…"/> verwenden, um die Skript- und Sandbox-Konfiguration zu übernehmen. Wenn Sie das Skript ausführen möchten,
rufen Sie einfach evaluate auf.
(Für die Kompatibilität mit alten Daten wählen Sie einen anderen Feldnamen und markieren Sie das Original als veraltet.
Dann können Sie eine readResolve-Methode definieren, die das neue Feld auf ein SecureGroovyScript mit deaktivierter Sandbox setzt,
configuring(ApprovalContext.create()) darauf aufruft, um das System zu benachrichtigen, dass ein nicht genehmigtes Skript geladen wurde,
und das alte Feld zurücksetzt.)
Zu verwenden, wenn Sie mehr Kontrolle benötigen, als SecureGroovyScript bietet:
Führen Sie ein boolesches Sandbox-Feld in Ihrer Konfiguration ein.
Wenn es nicht gesetzt ist, müssen Sie ScriptApproval.configuring im @DataBoundConstructor aufrufen.
Verwenden Sie ApprovalContext.withCurrentUser und auch withItemAsKey, wo zutreffend (wenn es nur ein Skript pro Job gibt);
andernfalls zumindest withItem, wo zutreffend, und/oder withKey, wenn Sie diese Verwendung eindeutig aus dem Kontext identifizieren können
(StaplerRequest.findAncestorObject ist hier hilfreich). Dies teilt dem System mit, dass ein (möglicherweise) neues Skript von einer bestimmten Person konfiguriert wurde.
Sie benötigen auch eine readResolve-Methode, die configuring aufruft, um das System zu benachrichtigen, wenn ein konfigurierbares Element mit Skript
von der Festplatte geladen wurde (und der Konfigurierer daher unbekannt ist). Rufen Sie ScriptApproval.using auf, wenn das Skript ausgeführt wird,
und fangen Sie UnapprovedUsageException ab, falls erforderlich. Der Deskriptor sollte Formularvalidierung für das Skriptfeld verwenden
und ScriptApproval.checking aufrufen (im Allgemeinen sollte Ihr Deskriptor bereits zumindest eine Syntaxprüfung für dieses Feld durchführen).
Wenn das Sandbox-Feld gesetzt ist, müssen Sie lediglich die Groovy-Shell mit
GroovySandbox.createSecureCompilerConfiguration einrichten und dann GroovySandbox.run aufrufen;
seien Sie darauf vorbereitet, RejectedAccessException abzufangen und ScriptApproval.accessRejected aufzurufen.
Um bestimmte Methodenaufrufe vorab zu genehmigen, annotieren Sie diese einfach mit @Whitelisted, wenn sie in Ihrem Plugin sind;
andernfalls können Sie (mit @Extension) einen ProxyWhitelist registrieren, der an StaticWhitelist.from delegiert
und eine Textdatei mit den whitelistierten Methoden lädt.
Wenn Sie eine GroovyShell zur Auswertung eines Skripts erstellen oder SecureGroovyScript.evaluate aufrufen,
müssen Sie einen ClassLoader übergeben, der den effektiven Classpath für das Skript darstellt.
Sie könnten den Classloader von Jenkins Core oder Ihrem Plugin oder
Jenkins.getInstance().getPluginManager().uberClassLoader verwenden.
Was auch immer Sie wählen, erlauben Sie keinem nicht privilegierten Benutzer, durch Erstellen eines URLClassLoader
beliebige Classpath-Einträge hinzuzufügen! Dies würde es trivial machen, alle Sicherheitsvorkehrungen bei Verwendung der Sandbox zu umgehen.
(Ein Benutzer müsste lediglich diesen oder einen anderen Job ein JAR archivieren lassen, das eine Klasse mit einer statischen Methode enthält,
die mit @Whitelisted markiert ist und tut, was immer sie wollen, und dann die Methode aus ihrem Skript aufrufen.)
Es wurde noch kein Angriff bei Verwendung der Skriptgenehmigung für ganze Skripte demonstriert – ein URLClassLoader mit normaler Parent-First-Delegation
würde kein triviales Maskieren harmlos wirkender APIs durch kompromittierte Versionen erlauben – aber es ist wahrscheinlich, dass
eine clevere Verwendung von META-INF/services/org.codehaus.groovy.transform.ASTTransformation oder ähnlichem
dazu führen könnte, dass ein ansonsten sicheres Skript sich unerwartet und unbefugt verhält.
JENKINS-22834 schlägt eine sichere Standardalternative vor.
Beim Schreiben von Tests für Plugins, die das Script Security Plugin verwenden, können Sie auf einige Fehler in Ihren Tests stoßen.
Wenn Ihre Tests direkt oder indirekt die Methode ScriptApproval.get() aufrufen, dann
müssen Ihre Unit-Tests JenkinsRule verwenden, damit Jenkins.getInstance() nicht null zurückgibt.
Es ist wahrscheinlich, dass Tests, die bisher funktionierten, nun fehlschlagen, wenn Sie keine Sandbox verwenden.
Dies geschieht, weil sie zur Genehmigung in die Warteschlange gestellt werden. Falls Sie Skripte unabhängig von Genehmigungen ausführen müssen,
stellt ScriptApproval.get().preapprove(script, GroovyLanguage.get()) sicher, dass alle konfigurierten Skripte genehmigt sind.
Alternativ können Sie Ihre Tests Skripte mit der Sandbox ausführen lassen. In diesem Fall müssen Sie möglicherweise
Methoden whitelistieren, die von Ihren Tests verwendet werden – entweder allgemein für echte Benutzer oder mittels
einer @TestExtension, um eine Whitelist nur für Tests zu haben.
Siehe das Changelog
