Plugin Jenkins offrant des workflows d'approbation de scripts et un sandboxing Groovy pour garantir une exécution sécurisée des scripts, avec des contrôles de permissions tenant compte des ACL et une gestion de liste blanche pour les administrateurs.
(adapté des informations du Plugin Template dans le guide des plugins CloudBees)
Divers plugins Jenkins exigent que les utilisateurs définissent des scripts personnalisés, le plus souvent en langage Groovy, pour personnaliser le comportement de Jenkins. Si tous ceux qui écrivent ces scripts sont des administrateurs Jenkins — plus précisément s'ils disposent de la permission Overall/RunScripts, utilisée par exemple par le lien Console de scripts — alors ils peuvent écrire les scripts de leur choix. Ces scripts peuvent référencer directement des objets internes de Jenkins en utilisant la même API offerte aux plugins. Ces utilisateurs doivent être complètement fiables, car ils peuvent tout faire sur Jenkins (même modifier ses paramètres de sécurité ou exécuter des commandes shell sur le serveur).
Cependant, si certains auteurs de scripts sont des « utilisateurs normaux » avec des permissions plus limitées, telles que Job/Configure, il est inapproprié de les laisser exécuter des scripts arbitraires. Pour soutenir une telle division des rôles, le plugin de bibliothèque Script Security peut être intégré dans divers plugins fonctionnels. Il prend en charge deux systèmes connexes : l'approbation de scripts et le sandboxing Groovy.
Le premier système de sécurité, et le plus simple, consiste à autoriser l'exécution de tout type de script, mais uniquement avec l'approbation d'un administrateur. Il existe une liste globalement maintenue de scripts approuvés qui sont considérés comme n'effectuant aucune action malveillante.
Lorsqu'un administrateur enregistre une configuration (par exemple, un job), les scripts qui ont été édités par l'administrateur sont automatiquement approuvés et prêts à être exécutés sans intervention supplémentaire. Pour les scripts soumis par des utilisateurs moins privilégiés, des avertissements appropriés indiqueront qu'une approbation est requise. Les administrateurs peuvent approuver ces scripts via la page de configuration Script Approval ou en modifiant le script et en l'enregistrant. Dans les versions précédentes du Plugin Script Security, les administrateurs pouvaient approuver automatiquement les scripts soumis par des utilisateurs non privilégiés en les enregistrant sans effectuer de modifications, mais cette fonctionnalité a été désactivée pour prévenir les attaques d'ingénierie sociale. (« Enregistrer » signifie généralement via l'interface Web, mais peut aussi signifier le téléchargement d'une nouvelle configuration XML via REST ou CLI.)
Lorsqu'un non-administrateur enregistre une configuration de modèle, une vérification est effectuée pour savoir si des scripts contenus ont été édités par rapport à un texte approuvé. (Plus précisément, si le contenu demandé a déjà été approuvé auparavant.) Si ce n'est pas le cas, une demande d'approbation de ce script est ajoutée à une file d'attente. (Un avertissement est également affiché dans l'interface de l'écran de configuration lorsque le texte actuel d'un script n'est pas actuellement approuvé.)
Un administrateur peut maintenant se rendre dans Gérer Jenkins » Approbation de script en cours où une liste des scripts en attente d'approbation sera affichée. En supposant que rien de dangereux n'est demandé, il suffit de cliquer sur Approuver pour que le script puisse être exécuté par la suite.
Si vous essayez d'exécuter un script non approuvé, il échouera simplement, généralement avec un message expliquant qu'il est en attente d'approbation. Vous pouvez réessayer une fois le script approuvé. Les détails de ce comportement peuvent varier selon le plugin fonctionnel intégrant cette bibliothèque.
Attendre qu'un administrateur approuve chaque modification d'un script, même apparemment triviale, peut être inacceptable dans une équipe répartie sur plusieurs fuseaux horaires ou lors de délais serrés. En alternative, le système Script Security permet d'exécuter des scripts Groovy sans approbation tant qu'ils se limitent à des opérations considérées comme intrinsèquement sûres. Cet environnement d'exécution limité est appelé un bac à sable (sandbox). (Actuellement, aucune implémentation de bac à sable n'est disponible pour d'autres langages, donc tous ces scripts doivent être approuvés s'ils sont configurés par des non-administrateurs.)
Pour passer à ce mode, cochez simplement la case Utiliser le bac à sable Groovy sous le champ de saisie du script Groovy. Les scripts en bac à sable peuvent être exécutés immédiatement par tout le monde (même les administrateurs, bien que le script soit soumis aux mêmes restrictions, quel que soit son auteur). Lorsque le script est exécuté, chaque appel de méthode, construction d'objet et accès à un champ est vérifié par rapport à une liste blanche d'opérations approuvées. Si une opération non approuvée est tentée, le script est tué et la fonctionnalité Jenkins correspondante ne peut pas encore être utilisée.
Le plugin Script Security est livré avec une petite liste blanche par défaut, et les plugins intégrateurs peuvent ajouter des opérations à cette liste (généralement des méthodes spécifiques à ce plugin).
Mais vous n'êtes pas limité à la liste blanche par défaut : chaque fois qu'un script échoue avant d'exécuter une opération qui n'est pas encore dans la liste blanche, cette opération est automatiquement ajoutée à une autre file d'attente d'approbation. Un administrateur peut se rendre sur la même page décrite ci-dessus pour l'approbation de scripts entiers et voir une liste des approbations d'opérations en attente. Si Approuver est cliqué à côté de la signature d'une opération, celle-ci est immédiatement ajoutée à la liste blanche et disponible pour les scripts en bac à sable.
La plupart des signatures sont de la forme method class.NomMéthode typeArg1 typeArg2…, indiquant un appel de méthode Java avec une classe « réceptrice » spécifique (this), un nom de méthode et une liste de types d'arguments (ou paramètres). (La signature la plus générale d'un appel de méthode tenté sera proposée pour approbation, même si l'objet réel sur lequel il devait être appelé était d'un type plus spécifique surchargeant cette méthode.) Vous pouvez également voir staticMethod pour les méthodes statiques (de classe), new pour les constructeurs et field pour les accès aux champs (get ou set).
Les administrateurs dans des environnements sensibles à la sécurité doivent examiner attentivement les opérations à mettre sur liste blanche. Les opérations qui modifient l'état des objets persistés (tels que les jobs Jenkins) doivent généralement être refusées. La plupart des méthodes getSomething sont inoffensives.
Soyez conscient cependant que même certaines méthodes « getter » sont conçues pour vérifier des permissions spécifiques (en utilisant une ACL : liste de contrôle d'accès), alors que les scripts sont souvent exécutés par un pseudo-utilisateur système à qui toutes les permissions sont accordées. Ainsi, par exemple, method hudson.model.AbstractItem getParent (qui obtient le dossier ou la racine Jenkins contenant un job) est en soi inoffensif, mais l'appel ultérieur possible method hudson.model.ItemGroup getItems (qui liste les jobs par nom dans un dossier) vérifie Job/Read. Ce deuxième appel serait dangereux à mettre sur liste blanche sans condition, car cela signifierait qu'un utilisateur disposant de Job/Create dans un dossier pourrait lire au moins certaines informations de tous les jobs de ce dossier, même ceux qui sont censés être cachés selon une stratégie d'autorisation basée sur les projets ; il suffirait de créer un job dans le dossier incluant un script Groovy comme celui-ci (les détails varieraient selon le plugin intégrateur) :
println("I sniffed ${thisjob.getParent().getItems()}!");
Lors de l'exécution, la sortie du script afficherait au moins les noms de projets supposés secrets. Un administrateur peut plutôt cliquer sur Approuver en supposant une vérification de permission pour getItems ; cela permettra l'appel lorsqu'il est exécuté en tant qu'utilisateur réel (si le plugin intégrateur le fait jamais), tout en l'interdisant lorsqu'il est exécuté en tant qu'utilisateur système (ce qui est plus typique). Dans ce cas, getItems est en fait implémenté pour ne retourner que les jobs auxquels l'utilisateur actuel a accès, donc s'il est exécuté dans le premier cas (en tant qu'utilisateur spécifique), la description montrera juste les jobs qu'il pourrait de toute façon voir. Ce bouton plus avancé n'est affiché que pour les appels de méthode (et les constructeurs), et ne doit être utilisé que là où vous savez que Jenkins effectue une vérification de permission.
Pour une intégration Groovy typique, dans laquelle vous offrez à l'utilisateur l'option d'utiliser soit l'approbation de script, soit le bac à sable, changez le champ de script de type String de votre descriptible en un champ SecureGroovyScript. Dans votre constructeur, avant de stocker la valeur, appelez configuringWithKeyItem (s'il ne peut y avoir qu'un seul tel script par élément de premier niveau) ou configuringWithNonKeyItem (s'il peut y en avoir plusieurs). Le formulaire de configuration doit utiliser <f:property field="…"/> pour récupérer la configuration du script et du bac à sable. Lorsque vous voulez exécuter le script, appelez simplement evaluate.
(Pour la compatibilité avec les anciennes données, choisissez un nom de champ différent et dépréciez l'original. Vous pouvez ensuite définir une méthode readResolve qui définit le nouveau champ sur un SecureGroovyScript avec le bac à sable désactivé, appelle configuring(ApprovalContext.create()) dessus pour notifier le système qu'un script non approuvé a été chargé, et efface l'ancien champ.)
À utiliser si vous avez besoin de plus de contrôle que SecureGroovyScript n'en offre :
Introduisez un champ booléen sandbox dans votre configuration.
Lorsque non défini, vous devez appeler ScriptApproval.configuring dans le @DataBoundConstructor. Utilisez ApprovalContext.withCurrentUser, et aussi withItemAsKey le cas échéant (lorsqu'il n'y a qu'un seul script par job) ; sinon au moins withItem le cas échéant, et/ou withKey lorsque vous pouvez identifier de manière unique cette utilisation à partir du contexte (StaplerRequest.findAncestorObject est utile ici). Cela permet au système de savoir qu'un script (peut-être) nouveau a été configuré par une personne particulière. Vous aurez également besoin d'un readResolve qui appelle configuring pour notifier le système lorsqu'un configurable avec script a été chargé depuis le disque (et donc que le configurateur est inconnu). Appelez ScriptApproval.using lorsque le script est exécuté, et attrapez UnapprovedUsageException si nécessaire. Le descripteur doit utiliser la validation de formulaire sur le champ de script et appeler ScriptApproval.checking (généralement, votre descripteur devrait déjà effectuer au moins une vérification syntaxique sur ce champ).
Lorsque le champ sandbox est défini, vous devez simplement configurer le shell Groovy avec GroovySandbox.createSecureCompilerConfiguration puis appeler GroovySandbox.run ; soyez prêt à attraper RejectedAccessException et à appeler ScriptApproval.accessRejected.
Pour pré-approuver certains appels de méthode particuliers, annotez-les simplement avec @Whitelisted si dans votre plugin ; sinon, vous pouvez enregistrer (avec @Extension) un ProxyWhitelist déléguant à StaticWhitelist.from et charger un fichier texte listant les méthodes mises sur liste blanche.
Lors de la construction d'un GroovyShell pour évaluer un script, ou lors de l'appel à ecureGroovyScript.evaluate, vous devez passer un ClassLoader qui représente le classpath effectif pour le script. Vous pouvez utiliser le chargeur du cœur de Jenkins, ou de votre plugin, ou Jenkins.getInstance().getPluginManager().uberClassLoader.
Quoi que vous choisissiez, ne permettez pas à un utilisateur non privilégié d'ajouter des entrées de classpath arbitraires en créant un URLClassLoader ! Cela rendrait trivial le contournement de toutes les sécurités lors de l'utilisation du bac à sable. (Un utilisateur n'a qu'à faire en sorte que ce job ou un autre archive un JAR contenant une classe avec une méthode statique marquée @Whitelisted et faisant ce qu'il veut, puis appeler la méthode depuis son script.) Aucune attaque n'a encore été démontrée lors de l'utilisation de l'approbation de script entier — un URLClassLoader avec délégation normale parent-first ne permettrait pas un masquage trivial d'API anodines par des versions compromises — mais il est probable qu'une utilisation astucieuse de META-INF/services/org.codehaus.groovy.transform.ASTTransformation ou similaire pourrait amener un script par ailleurs sûr à se comporter de manière inattendue et non autorisée. JENKINS-22834 suggère une alternative standard sûre.
Lors de l'écriture de tests pour des plugins qui utilisent le Plugin Script Security, vous pouvez rencontrer certaines erreurs dans vos tests.
Si vos tests appellent, directement ou indirectement, la méthode ScriptApproval.get(), alors vos tests unitaires doivent utiliser JenkinsRule pour que Jenkins.getInstance() ne retourne pas null. Il est probable que des tests qui fonctionnaient auparavant commencent à échouer si vous n'utilisez pas le bac à sable. Cela se produit car ils sont mis en file d'attente pour approbation. Si vous avez besoin d'exécuter des scripts indépendamment des approbations, ScriptApproval.get().preapprove(script, GroovyLanguage.get()) garantira que tous les scripts configurés sont approuvés. Alternativement, vous pouvez faire exécuter les scripts par vos tests en utilisant le bac à sable. Dans ce cas, vous devrez peut-être mettre sur liste blanche les méthodes utilisées par vos tests — soit généralement pour les utilisateurs réels, soit en utilisant un @TestExtension pour avoir une liste blanche uniquement pour les tests.
Voir le changelog
