¿Cómo puede root iniciar un proceso que sólo root puede eliminar?

¿Cómo puede root iniciar un proceso que sólo root puede eliminar?

Es fácil iniciar un proceso en segundo plano o convertirlo como systemdservicio.

Sin embargo, si quiero iniciar un proceso que monitoree las actividades en la máquina Linux, es blanco de ataques. Si algún usuario quiere hacer algo malo, primero finalizará este proceso, incluso si solo son sudousuarios wheel, simplemente ejecutando killo systemctl stop.

¿Hay alguna manera de hacer cumplir un proceso que sólo rootpuede matar?


Chicos, sólo con pensar que incluso rsyslogse puede eliminar el servicio, deberían reconocer lo vulnerable que es realmente Linux. Es como si un piloto pudiera apagar una caja negra. ¿Alguna aerolínea permite que esto suceda? ¿O alguno le da al piloto una lista de permitidos para impedirle hacer todo lo posible para salvar el avión? Por supuesto, el piloto puede estrellar el avión, pero la caja negra lo registrará.

Mi propuesta sobre una lista de prohibición es legítima desde la perspectiva de la seguridad, aunque pueda asustarte. Así que no intentes culpar al tipo que planteó la pregunta, ¿de acuerdo?

Respuesta1

Al tener privilegios sudo/wheel ilimitados, cualquiera podrá deshacer cualquier cosa que hayas hecho. Incluso si logra lograr esto eliminando la posibilidad de finalizar el proceso directamente, por ejemplo, con sudo kill, esto aún podría evitarse usando otros comandos sudoed, o también se bloqueará fuera de la administración.

Pregúntese, en primer lugar, ¿por qué los usuarios que no son de confianza tienen privilegios sudo ilimitados? No deberían hacerlo. Sólo conceda esos privilegios a aquellos en quienes confíe plenamente. Si hay algunos comandos privilegiados que aún deben ejecutarse, habilite sudo solo para esos comandos:

+netmgr /usr/sbin/ifup, /usr/sbin/ifdown

(úselo visudo -f /etc/sudoers.d/netmgrpara poner esto en el archivo complementario sudoers).

De esta manera, puede permitir que un usuario solo ejecute sudo /usr/sbin/ifupy sudo /usr/sbin/ifdown, pero ningún otro comando sudo. Muchos otros ejemplos, instrucciones y consideraciones de seguridad se encuentran en man sudoers. ¡Léelo!

La auditoría se realiza normalmente de otra manera. En particular, usted configuraotromáquina, configure su syslog para aceptar registros de estaciones remotas. En la máquina en cuestión, configuró el registro para que envíe todos los registros a la máquina de registro, además de almacenarlos localmente. Incluso si alguien desactiva este envío de registros, la acción de desactivarse se registrará, así al menos sabrás quién es el culpable.

Respuesta2

No puedes darle a alguien un poder y luego impedirle que lo use. Tienes que enfocar estrictamente el poder que les das para incluir solo lo que quieres que tengan.

En un comentario dijiste:

Tengo que permitirles el uso killporque systemctl stophay algunas aplicaciones que necesitan estos privilegios para hacer su trabajo.

Eso no significa que esosusuariosnecesita acceso a esos comandos, sólo aquellosaplicaciones. El usuario tiene permisos limitados para ejecutar sudo ./someprogramy una vez que el programa se ejecuta como root, puede usarlo kill, etc., según sea necesario. Sin embargo, el usuario no tiene acceso directo a esos comandos internos.

Básicamente, los usuarios no necesitan acceder acomandos, necesitan acceso afuncionalidad. Si killes demasiado arriesgado, bloquee el acceso y proporcione alguna otra forma más segura de lograr el mismo resultado. Quizás cree una pequeña utilidad safekillque actúe killpero rechace solicitudes para finalizar ciertos procesos. Dé a sus usuarios acceso sudo safekillpero no al real kill. Si los usuarios siempre usan estos comandos para hacer lo mismo, encapsule todo el proceso en un pequeño programa y haga que lo usen en lugar de hacerlo manualmente (por ejemplo, ejecutarían sudo restart_webserversen lugar de eliminar y reiniciar todos los procesos del servidor individualmente). . Sus usuarios aún tienen acceso a la funcionalidad que necesitan, pero no pueden empuñar las armas peligrosas directamente.

Existe otro mecanismo de aplicación más extremo que podría estar disponible dependiendo de su configuración particular. Algunos procesadores tienentemporizadores de vigilanciadisponible. Modifique su programa de monitoreo de actividad para iniciar el mecanismo de vigilancia y restablecerlo cada dos segundos. Si alguien logra apagar su monitor, el temporizador de vigilancia expirará y el sistema se reiniciará, reiniciando el programa del monitor al inicio. Esto no evitaría estrictamente que se deshabilite el monitor, pero prohibiría que cualquiera haga algo significativo después de deshabilitarlo. Esto también creará grandes señales de alerta en los registros de su sistema. La mayoría de los sistemas con perros guardianes informarán cuando el perro guardián activó un reinicio específico. Un reinicio activado por el perro guardián que ocurre mientras un usuario inició sesión en el shell debe verse comomuysospechoso.

Respuesta3

Novato de Linux aquí. ¿Podrías considerar escribir programas o scripts que hagan solo lo que estos tipos deben hacer, luego convertirlos en propietarios raíz y agregarles un bit setuid? Por supuesto, un gran problema es que es posible que no quieras que otras personas ejecuten estos comandos. No estoy seguro de poder obtener la información del usuario original. Y, por supuesto, siempre es necesario tener especial cuidado con setuid/setgid.

Respuesta4

¡Se me ocurrió Un comienzo!

rootPuede establecer un SHELL PREDETERMINADO en un usuario como este:

useradd [someuser] -s [a certain executable]

Entonces, si cierto ejecutable = Un script de censura que:

  1. Censura automáticamente la ejecución de ciertos comandos. Me gusta stopy rsyslogcombinado.

  2. prohíbe comandos para escapar de este shell y usar otro incluso el originalbash

  3. prohíbe los comandos para evitar que el usuario obtenga el rol rootcomo el que @ usuario253751 mencionó anteriormente.

  4. Pasa el resto de comandos a/bin/bash

Luego configúrelo r+xpara cualquier usuario.

Cualquier sugerencia se agradece en esta respuesta. Especialmente para 2 y 3 parece que existen varios medios.


Bash cargará la configuración en /etc/profiley /etc/bashrcprimero. He notado que este último trata con la PROMPT_COMMANDvariable. Es posible secuestrar esto en la última línea para agregarlo en el script de censura, pero se necesita un nombre de usuario de exención para algunos sistemas ya que, de forma predeterminada, nadie tiene privilegios de root para volver a cambiarlo.

Una censura completa que satisfaga los 4+1 anteriores se marcará como respuesta legítima.

Nunca marcaré una respuesta de "renunciarás" como legítima.

preguntas relacionadas son:

¿Cómo puedo registrar los comandos bash de los usuarios?

¿Cómo puedo hacer que bash registre los comandos de Shell en syslog?

Inicie sesión sin ejecutar bash_profile o bashrc

información relacionada