¿Hay algo entre una cuenta de usuario normal y root?

Question

Estoy desarrollando una aplicación que gestiona interfaces de red en nombre del usuario y llama a varios programas externos (como ifconfig) que requieren root para realizar cambios. (Específicamente, cambiando la dirección IP de una interfaz local, etc.) Durante el desarrollo, he estado ejecutando el IDE como root (ugh) y el depurador como root (double-ugh). ¿Hay una buena manera para que el usuario final los ejecute bajo una cuenta no root? No me gusta mucho el tamaño de la superficie de ataque presentada por GTK, wxPython, Python y mi aplicación cuando se ejecuta como root.

He examinado las capacidades, pero se ven a medias y no estoy seguro de si podría usarlas en Python, especialmente si están basadas en hilos. La única opción que no he explorado es un demonio que tiene el bit setuid establecido y hace todo el tipo de raíz en nombre de la interfaz de usuario. Dudo en presentar esa complejidad tan temprano en el proyecto, ya que ejecutarse como root no es un factor decisivo para los usuarios.

Answer 1

Tu idea sobre el demonio tiene mucho mérito, a pesar de la complejidad que presenta. Siempre que las acciones no requieran alguna interacción de la interfaz de usuario como root , un daemon le permite controlar qué operaciones están permitidas y no permitidas.

Sin embargo, puede usar SUDO para crear un compromiso controlado entre ROOT y los usuarios normales ... simplemente otorgue a SUDO acceso a los usuarios en cuestión para las herramientas específicas que necesitan. Eso reduce la superficie de ataque permitiendo solo " permitido " lanzamientos de raíz.

Answer 2

Lo que quieres es un " Grupo "

Usted crea un grupo, especifica que la cuenta que desea realizar la acción pertenece al grupo, luego especifica que el recurso al que desea acceder es miembro de ese grupo.

A veces, la administración de grupo puede ser un poco irritante, pero debería permitirle hacer lo que quiera, y es el usuario el que está autorizado, no su programa.

(Si desea que su programa sea autorizado, puede crear un usuario específico para ejecutarlo y darle a ese usuario la membresía de grupo adecuada, luego su a ese grupo dentro de su programa para ejecutar la operación sin darle la capacidad al usuario en ejecución. )

Answer 3

Puede crear y distribuir una política de selinux para su aplicación. Selinux permite el tipo de acceso de grano fino que necesita. Si no puede o no usará selinux, entonces el demonio es el camino a seguir.

Answer 4

No ejecutaría la aplicación a tiempo completo como root, pero es posible que desee explorar cómo hacer que su aplicación sea setuid root, o setuid para algún id que pueda convertirse en root usando algo como sudo para aplicaciones particulares. Es posible que pueda configurar una cuenta que no pueda iniciar sesión, usar setuid para cambiar la identificación de su programa (temporalmente cuando sea necesario) y configurar sudo para no solicitar una contraseña, pero siempre permitir el acceso a esa cuenta para tareas específicas.

De esta manera, su programa no tiene privilegios especiales cuando se ejecuta normalmente, solo aumenta sus privilegios cuando es necesario, y está restringido por sudo para ejecutar solo ciertos programas.

Ha pasado un tiempo desde que hice mucho desarrollo de Unix, por lo que no estoy realmente seguro de si es posible configurar sudo para que no solicite una contraseña (o incluso si hay una API para ello), pero como en caso contrario, puede habilitar setuid para rootear solo cuando sea necesario.

[EDITAR] Parece que sudo tiene un modo NOPASSWD, así que creo que debería funciona ya que estás ejecutando los programas como comandos externos.

Answer 5

La forma tradicional sería crear y usar un ayudante setuid para hacer lo que necesites. Sin embargo, tenga en cuenta que escribir un ayudante setuid de manera adecuada es complicado (hay varios vectores de ataque contra los que tiene que protegerse).

La forma moderna sería usar un demonio (que se ejecuta como root, iniciado en el arranque) que escucha las solicitudes del resto de la aplicación. De esta manera, su superficie de ataque se limita principalmente a cualquier IPC que elija (sugeriría d-bus, que parece ser la forma moderna).

Finalmente, si está administrando interfaces de red, lo que hace es muy similar a lo que hace el administrador de red en una distribución moderna. Sería una buena idea intentar integrar de alguna manera lo que está haciendo con el administrador de red (para que no entre en conflicto con sus manipulaciones), o al menos ver cómo funciona.

Answer 6

No hay un solo usuario que esté a medio camino entre un " normal " usuario y root. Tienes root, y luego tienes usuarios; Los usuarios pueden tener diferentes niveles de capacidades. Si quieres algo que sea más poderoso que un "normal" usuario pero no tan poderoso como root, solo crea un nuevo usuario con las capacidades que desea, pero no le otorga los privilegios que no desea que tenga.

Answer 7

No estoy lo suficientemente familiarizado con Python para decirle cuáles serían los comandos necesarios en ese idioma, pero debería poder lograr esto mediante el bifurcación y el uso de un conducto para comunicarse entre los procesos padre e hijo. Algo a lo largo de las líneas de:

• Ejecuta el programa como root a través de sudo o suid
• Al iniciarse, el programa inicia y establece de inmediato un conducto para la comunicación entre los procesos primarios y secundarios
• El proceso hijo retiene la energía de la raíz, pero simplemente se queda allí esperando la entrada de la tubería
• El proceso principal elimina la raíz (cambia su uid de nuevo al del usuario que lo ejecuta), luego muestra la GUI, interactúa con el usuario y maneja todas las operaciones que están disponibles para un usuario sin privilegios.
• Cuando se va a realizar una operación que requiere privilegios de root, el proceso principal (no root) envía un comando por el conducto al proceso secundario (root) que lo ejecuta y, opcionalmente, informa al padre

Es probable que esto sea un poco más fácil de escribir que un demonio independiente, así como más conveniente de ejecutar (ya que no tiene que preocuparse de si el demonio se está ejecutando o no), al tiempo que permite la GUI y otras cosas que no necesitan poderes de root para que se ejecuten como no root.