¿Hay alguna manera de evitar que los sudoers editen cosas en / etc / ssh / sshd_config?

En última instancia, las listas negras no funcionan : sería un esfuerzo vano tratar de encontrar todas las formas en que un usuario equivalente de raíz podría alterar el contenido de /etc/ssh/sshd_config y tratar de corregirlo todos. Por ejemplo, muchos comandos pueden generar algunos datos en un archivo cuyo nombre se proporciona como parámetro, que podría usarse para alterar /etc/ssh/sshd_config .

En su lugar, usa listas blancas : permite explícitamente a los sudoers ejecutar un pequeño conjunto de comandos explícitos (por ejemplo, un comando para activar un reinicio, si eso es relevante para tu situación), y todos otros deben estar prohibidos.

Alternativamente, use SELinux para restringir a los sudoers a un rol no exactamente correcto y obtener /etc/ssh/sshd_config out de su alcance. Pero esto puede implicar un trabajo de configuración considerable (SELinux parece estar a la altura de la tarea, pero no lo he intentado, por lo que no garantizo el éxito aquí). Además, tenga en cuenta que el poder de la molestia de un usuario root malintencionado tiende a ser generalizado: hay muchas muchas formas en que dicho usuario puede dañar su seguridad. Parece mejor no confiar en las personas malvadas con los poderes del sudo. O tal vez se justifique una capa de aislamiento más completa: en lugar de tener varios usuarios en una sola máquina, con algunos poderes semi-administrativos, entregue una máquina virtual a cada usuario, para que pueda jugar a voluntad sin afectar a los demás usuarios. Dependiendo de su contexto, esto puede o no ser aplicable.

Lo más cercano a lo que será imposible es utilizar un conjunto extremadamente restringido de lo que es posible a través de sudo. Tendrás que prohibir el acceso a vi, editores, shells y su. Es mejor intentar determinar qué comandos son necesarios y esperar que ninguno de ellos tenga la capacidad de editar archivos o directorios o ejecutar comandos.

En última instancia, si le está dando privilegios a alguien en su sistema, está invitando a riesgos.

Hay otras alternativas que puede considerar:

Monitoree los registros SSH para inicios de sesión de root con autenticación de contraseña Ese es su principal indicador de que su archivo ha sido cambiado.

Supervise ese archivo para detectar cambios con un cron que se ejecuta con frecuencia. Si alguien modifica ese archivo y no se da cuenta del monitor, lo capturará.

Sí , con AppArmor podría ser posible:

He probado un poco con el uso de MAC (control de acceso obligatorio) y el LSM de AppArmor (módulo de seguridad de Linux) y descubrí que es posible que tenga un cambio con AppArmor para hacer que /etc/ssh/sshd_config sea imposible escribir con sudo .

Este perfil de AppArmor limitaría lo que el usuario puede hacer después de haber ganado el "poder raíz" a través de sudo

/usr/bin/sudo {
  capability setgid,
  capability setuid,
  / rw,
  /** rwmix,
  deny /etc/ssh/sshd_config w,
  deny /usr/sbin/aa* rw,
  deny /sbin/app* rw,
  deny /usr/bin/sudo rw,
  deny /etc/apparmor.d/profile.usr.bin.sudo rw,
  deny /sys/kernel/security/apparmor/ rw,
  deny /sys/kernel/security/apparmor/** rw,
}

Para estar seguro, primero busque si ya existe un perfil de AppArmor preexistente para /usr/bin/sudo

$ aa-status | grep sudo

En caso de que no haya ninguno, la salida está vacía! Si no está vacío, es mejor que hable con aquellos que hayan configurado el perfil y que no sigan aquí.

Si, como se esperaba, aún no hay un perfil, puede crear uno con este comando:

root@computer:/root/# echo "/usr/bin/sudo {
>   capability setgid,
>   capability setuid,
>   / rw,
>   /** rwmix,
>   deny /etc/ssh/sshd_config w,
>   deny /usr/sbin/aa* rw,
>   deny /sbin/app* rw,
>   deny /usr/bin/sudo rw,
>   deny /etc/apparmor.d/profile.usr.bin.sudo rw,
>   deny /sys/kernel/security/apparmor/ rw,
>   deny /sys/kernel/security/apparmor/** rw,
> } " > /etc/apparmor.d/yourprofile.usr.bin.sudo

Luego puedes iniciar / configurar el nuevo perfil

root@computer:/root/# apparmor_parser -r /etc/apparmor.d/yourprofile.usr.bin.sudo
root@computer:/root/# aa-enable /etc/apparmor.d/yourprofile.usr.bin.sudo

como resultado, para un usuario, este debería ser el resultado:

ssh_user@computer:~$ sudo bash -c "echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config"
[sudo] password for ssh_user: 
bash: /etc/ssh/sshd_config: Permission denied
ssh_user@computer:~$ sudo -i
root@computer:/root/$ echo 'PermitRootLogin yes' >> /etc/ssh/sshd_config
-bash: /etc/ssh/sshd_config: Permission denied
root@computer:/root/$ aa-disable profile.usr.bin.sudo
Can't open perl script "/usr/sbin/aa-disable": Permission denied

Lamentablemente, no puedo darte una idea de cómo implementar esto en otros LSM como SELinux o grsecurity.

De todos modos, agradecería recibir comentarios si la solución te ayudara :)

Tenga en cuenta que las limitaciones con respecto a lo que se puede hacer con el sudo son para todos y eso significa que si usa sudo para obtener la potencia de superusuario, sufrirá las mismas limitaciones (es decir, no puede deshabilitar a apparmor, ni /etc/ssh/sshd_config usted mismo. Solo uno que puede es una raíz real a través de inicio de sesión.

Puede escribir su / etc / ssh / sshd_config en una unidad de solo lectura física. En ese caso, aunque haya iniciado sesión como root, no podría cambiar sshd_config.

Pero entonces tendrías que estar atento

• si el usuario puede montar y desmontar unidades, podría desmontar cualquier unidad en la que tenga sshd_config
• si el usuario tiene acceso físico a su máquina, entonces simplemente podría reemplazar el disco