Autoriser les utilisateurs non administrateurs à installer des packages via apt ou rpm?

13

Est-il possible d'autoriser les utilisateurs non root à installer des packages à l'échelle du système en utilisant apt ou rpm?

L'endroit où je travaille actuellement a une configuration obsolète sur les boîtiers Linux, et les administrateurs en ont assez de devoir faire toutes les installations pour les utilisateurs sur demande, alors ils envisagent de donner des droits sudo complets à tous les utilisateurs. Cela présente des inconvénients de sécurité évidents. Je me demande donc s'il existe un moyen de permettre aux utilisateurs normaux d'installer des logiciels - et de les mettre à niveau et les supprimer?

linux package-management sudo software-installation rien101
la source
4
Si vous accordez des privilèges pour installer des packages, vous avez essentiellement accordé des droits d'administration complets, car un utilisateur peut simplement installer un package avec un shell setuid-root.
camh
@camh hrm .. vous pourriez avoir un référentiel approuvé et ne pas laisser les utilisateurs ajouter de nouveaux référentiels, non? Ou apt vous permet-il d'installer des packages à partir de fichiers .deb? Je réalise qu'un repo approuvé serait probablement plus de travail à long terme, c'est plus une question conceptuelle :)
naught101
1
apt-secure(8)dit: "apt-get avertira actuellement uniquement pour les archives non signées, les futures versions pourraient forcer toutes les sources à être vérifiées avant de télécharger des paquets à partir de celles-ci". Selon le degré de sophistication d'une attaque, il peut être possible de détourner la connexion à la source du référentiel et d'injecter un package non approuvé. Cependant, lisez cette page de manuel pour plus de détails. Vous pouvez avoir une solution suffisamment sécurisée pour votre modèle de thread.
camh
Connexe: Système de gestion des packages utilisateur-local
Piotr Dobrogost
1
Connexes: gestionnaires de packages non root
Piotr Dobrogost

Réponses:

21

Vous pouvez spécifier les commandes autorisées avec sudo, vous n'avez pas à autoriser un accès illimité, par exemple

username ALL = NOPASSWD : /usr/bin/apt-get , /usr/bin/aptitude

Cela permettrait au nom d'utilisateur de s'exécuter sudo apt-getet sudo aptitudesans aucun mot de passe, mais ne permettrait aucune autre commande.

Vous pouvez également utiliser packagekit combiné avec PolicyKit pour un niveau de contrôle plus fin que sudo.

Permettre aux utilisateurs d'installer / supprimer des packages peut être un risque. Ils peuvent facilement rendre un système non fonctionnel simplement en désinstallant les logiciels nécessaires comme libc6, dpkg, rpm etc. L'installation de logiciels arbitraires à partir des archives définies peut permettre aux attaquants d'installer des logiciels obsolètes ou exploitables et d'accéder à la racine. À mon avis, la question principale est de savoir à quel point vous faites confiance à vos employés?

Bien sûr, votre équipe d'administration pourrait également commencer à utiliser un système de gestion de configuration comme marionnette, chef ou se pencher sur la sortie dans l'espace pour gérer votre système. Cela leur permettrait de configurer et de gérer le système à partir d'un système central.

Ulrich Dangel
la source
Je l'ai laissé hors de ma question, mais avez-vous des commentaires sur la réduction de sécurité impliquée en autorisant cela? Je veux dire, vous ne pouvez pas modifier les référentiels de packages, donc vous n'obtiendrez probablement pas un accès sudo complet, mais vous pouvez écrire dans n'importe quel fichier en utilisant aptitude (options> préférences> "Fichier dans lequel enregistrer les actions"), ce qui pourrait causer de graves dommages. Je suis moins sûr de PolicyKit ...
naught101
1
@ naught101 ok j'ai ajouté quelques commentaires sur la sécurité. JFTR car policykit ne fournira pas d'accès root, ce serait moins problématique que d'utiliser sudo
Ulrich Dangel
Il existe des façons d'exécuter un shell à partir de dpkg ou rpm. Par exemple: dpkg demandera quand il y a un changement de fichier de configuration qui se bloque, avec l'une des options étant de démarrer un shell pour examiner la situation . Cela démarrera un shell en tant que root s'il est exécuté via sudo. De même, si vous pouvez exécuter un éditeur à partir de l'outil, car la plupart des éditeurs vous permettent d'exécuter des commandes shell arbitraires à partir de celles-ci (par exemple! Commande dans vi).
David Gardner
@ naught101 Je testerais l'escalade de privilèges via un RPM qui contient un shell SUID comme ce blog le décrit: nosedookie.blogspot.com/2011/07/… Dans un scénario d'injection de shell, cependant, où le compte sudoer est compromis, on pourrait atténuer élévation de privilèges via sudo en exigeant la saisie d' un mot de passe , par opposition à NOPASSWD.
Matt
7

aptdcon

Depuis les pages de manuel:

aptdcon: permet d'effectuer des tâches de gestion de paquets, par exemple l'installation ou la suppression de logiciels, à l'aide d'aptdaemon. Il n'est pas nécessaire d'être root pour exécuter ce programme.

pl1nk
la source
1
Bien que vous n'ayez pas besoin des privilèges root / sudo pour exécuter aptdcon, il lance immédiatement une boîte de dialogue d'authentification pour les utilisateurs non privilégiés - je viens de tester sur Ubuntu. Si vous n'êtes pas un utilisateur privilégié / autorisé, cela n'ajoute / ne supprime pas de packages.
sage
1
Ne fonctionne pas sur les opérationsERROR: You are not allowed to perform this action. ('system-bus-name', {'name': ':1.716'}): org.debian.apt.install-or-remove-packages
JacopKane
4 
username ALL = NOPASSWD : /usr/bin/yum, /bin/rpm
fromnaboo
la source
1

J'ai également cherché quelque chose comme ça, mais rien ne s'est présenté, j'ai donc codé cette solution facile "softwarechannels":

https://github.com/alfem/softwarechannels

Il s'agit d'un système très simple permettant aux utilisateurs ordinaires (sans administrateur) d'installer des packages à partir de catalogues restreints.

Il vous suffit de définir des «canaux» (groupes de packages) dans un simple fichier texte et de donner à vos utilisateurs les autorisations pour lancer des canaux logiciels.

Ils ne verront que les packages dans les canaux correspondant à leurs groupes Unix.

Alfonso EM
la source