¿Permitir que usuarios no administradores instalen paquetes a través de apt o rpm?

13

¿Es posible permitir que usuarios no root instalen paquetes en todo el sistema usando apt o rpm?

El lugar donde trabajo actualmente tiene una configuración desactualizada en las cajas de Linux, y los administradores están cansados de tener que hacer todas las instalaciones para los usuarios que lo soliciten, por lo que están pensando en otorgar todos los derechos de sudo a todos los usuarios. Esto tiene desventajas de seguridad obvias. Entonces, me pregunto si hay una manera de permitir que los usuarios normales instalen software, y que lo actualicen y lo eliminen.

— nada101
fuente

44

Si otorga privilegios para instalar paquetes, esencialmente ha otorgado derechos de administrador completos, ya que un usuario podría instalar un paquete con un shell setuid-root.

— camh

@camh hrm ... podrías tener un repositorio examinado y no permitir que los usuarios agreguen repositorios nuevos, ¿no? ¿O apt le permite instalar paquetes desde archivos .deb? Me doy cuenta de que un repositorio examinado probablemente sería más trabajo a largo plazo, esta es más una pregunta conceptual :)

— nada101

1

apt-secure(8)dice: "apt-get actualmente solo advertirá sobre archivos sin firmar, las futuras versiones podrían obligar a verificar todas las fuentes antes de descargar paquetes de ellas". Dependiendo de cuán sofisticado sea un ataque, podría ser posible secuestrar la conexión a la fuente del repositorio e inyectar un paquete no confiable. Sin embargo, lea esa página de manual para más detalles. Es posible que tenga una solución lo suficientemente segura para su modelo de hilo.

— camh

Relacionados: el usuario del sistema local de gestión de paquetes

— Piotr Dobrogost

1

Relacionado: Gerentes de paquetes no raíz

— Piotr Dobrogost

21

Puede especificar los comandos permitidos con sudo, no tiene que permitir el acceso ilimitado, p. Ej.

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

Esto permitiría ejecutar el nombre de usuario sudo apt-gety sudo aptitudesin contraseña, pero no permitiría ningún otro comando.

También puede usar packagekit combinado con PolicyKit para un nivel de control más fino que sudo.

Permitir a los usuarios instalar / eliminar paquetes puede ser un riesgo. Pueden hacer que un sistema no funcione con bastante facilidad simplemente desinstalando el software necesario como libc6, dpkg, rpm, etc. La instalación de software arbitrario de los archivos definidos puede permitir a los atacantes instalar software obsoleto o explotable y obtener acceso a la raíz. La pregunta principal en mi opinión es ¿cuánto confía en sus empleados?

Por supuesto, su equipo de administración también podría comenzar a usar un sistema de administración de configuración como títeres, chef o investigar la caminata espacial para administrar su sistema. Esto les permitiría configurar y administrar el sistema desde un sistema central.

— Ulrich Dangel
fuente

Lo dejé fuera de mi pregunta, pero ¿tiene algún comentario sobre la reducción de seguridad implícita al permitir esto? Es decir, no puede cambiar los repositorios de paquetes, por lo que probablemente no obtendrá acceso completo a sudo, pero puede escribir en cualquier archivo usando aptitude (opciones> preferencias> "Archivo para registrar acciones"), lo que podría Causar algunos daños graves. Estoy menos seguro sobre PolicyKit ...

— naught101

1

@ naught101 ok, agregué algunos comentarios sobre seguridad. JFTR ya que el juego de políticas no proporcionará acceso a la raíz, sería menos problemático que usar sudo

— Ulrich Dangel

Hay formas de ejecutar un shell desde dpkg o rpm. Por ejemplo: dpkg preguntará cuando haya un cambio en el archivo de configuración que choque, y una de las opciones será iniciar un shell para examinar la situación . Esto iniciará un shell como root si se ejecuta a través de sudo. Del mismo modo, si puede ejecutar un editor desde la herramienta, ya que la mayoría de los editores le permiten ejecutar comandos de shell arbitrarios desde ellos (por ejemplo, el comando en vi).

— David Gardner

@ naught101 Probaría la escalada de privilegios a través de un RPM que contiene un shell SUID como lo describe este blog: nosedookie.blogspot.com/2011/07/… Sin embargo, en un escenario de inyección de shell donde la cuenta de sudoer está comprometida, uno podría mitigar escalada de privilegios a través de sudo al requerir que se ingrese una contraseña , en lugar de NOPASSWD.

— Matt

7

aptdcon

De las páginas del manual:

aptdcon: permite realizar tareas de gestión de paquetes, por ejemplo, instalar o eliminar software, utilizando aptdaemon. No hay necesidad de ser root para ejecutar este programa.

— pl1nk
fuente

1

Aunque no necesita privilegios de root / sudo para ejecutar aptdcon, inmediatamente inicia un cuadro de diálogo de autenticación para usuarios sin privilegios: acabo de probar en Ubuntu. Si no es un usuario privilegiado / autorizado, esto no agrega / elimina paquetes.

— sabio

1

No funciona en operaciones

ERROR: 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
fuente

1

También busqué algo así, pero no apareció nada, así que codifiqué esta solución fácil "softwarechannels":

https://github.com/alfem/softwarechannels

Es un sistema muy simple para permitir que los usuarios comunes (sin administrador) instalen paquetes de catálogos restringidos.

Simplemente defina 'canales' (grupos de paquetes) en un archivo de texto simple y otorgue a sus usuarios permisos para iniciar canales de software.

Solo verán paquetes en canales que coincidan con sus grupos unix.

— Alfonso EM
fuente