Cómo restringir el shell de los usuarios permitiendo ejecutar programas de shell

¿Es posible evitar que cualquier usuario no use comandos como ls, rm y otros comandos del sistema que podrían dañar el sistema? Pero los usuarios deberían poder ejecutar programas de shell.

Tu pregunta debe ser:

No confío en mis usuarios. Los tontos ven algo en Internet y lo prueban sin entender lo que hace. A los tortuosos les gusta curiosear y mirar los archivos de otras personas y robar sus ideas. Y los flojos, no me hagas empezar con los flojos.

¿Cómo protejo mi sistema y mis usuarios de mis usuarios?

Primero, Unix tiene un sistema de permisos de sistema de archivos muy completo. Este parece ser un tutorial decente sobre los permisos del sistema de archivos Unix . La esencia de esto es que los directorios se pueden configurar de modo que un usuario pueda ingresar a un directorio y ejecutar programas fuera de ese directorio pero no pueda ver el contenido de ese directorio. Si hace esto, por ejemplo, en / home, si el usuario ejecuta ls en / home, recibirá un error de permiso denegado.

Si realmente le tienes miedo a tus usuarios y quieres pegarlos en un entorno restringido de tipo supermax , usa algo como las cárceles de freebsd o las zonas de solaris: cada usuario obtiene su propio entorno a medida. Para obtener puntos adicionales, use ZFS para poder tomar una instantánea del entorno cuando inicien sesión, por lo que si eliminan sus archivos, simplemente puede sacarlos de la instantánea.

Hay tres cosas que deben estar en su lugar para hacer completamente lo que está pidiendo:

1. Un shell personalizado que carece de los comandos que le interesan . Esto es algo difícil de conseguir, pero si realmente no desea que los usuarios tengan acceso a algunas primitivas de shell, esta es la única forma de eliminarlas.
2. Establecer correctamente los permisos de archivo . ¿No quieres que los usuarios dañen el sistema? Establezca los permisos para que no puedan dañar el sistema, incluso si tienen las herramientas adecuadas. De estos tres pasos, este es el paso más fácil.
3. Utilice una tecnología de control de acceso obligatoria como AppArmor . Los MAC como AppArmor y SELinux incorporan permisos en el núcleo. Esto evita que los usuarios ejecuten las herramientas correctas incluso si las encuentran en algún lugar (y, al igual que los permisos de archivos, evitan que las usen fuera del cuadro restringido).

Cinturón, tirantes y una pistola de grapas para una buena medida. Difícil equivocarse allí.

AppArmor es interesante ya que todos sus hijos heredan el MAC para un ejecutable específico. Establezca el inicio de sesión de un usuario /bin/bash-bob, establezca el perfil de AppArmor para ese derecho binario específico, y la única forma en que está saliendo de esa cárcel de permisos es a través de las vulnerabilidades del kernel. Si alguna secuencia de comandos de instalación diferida se puede escribir de forma /var/opt/vendor/tmpglobal por alguna razón estúpida, el usuario que use /bin/bash-bobsu shell no podrá escribir allí . Configure el perfil bash-bob para que solo permita la escritura en su directorio de inicio /tmpy dichos errores de permisos no se pueden aprovechar. Incluso si de alguna manera encuentran la contraseña de root, el perfil de AppArmor /bin/bash-bobtodavía se aplicará incluso después de que se suactiven desde entonces suy el bashproceso del que se genera son hijos /bin/bash-bob.

La parte difícil es construir ese perfil de AppArmor.

1. Cree un perfil de AppArmor para / bin / bash-bob y configúrelo en modo auditoría
2. Establezca el shell de inicio de sesión de Bob en / bin / bash-bob
3. Inicie sesión como Bob. Haz todo lo que quieras que Bob pueda hacer.
4. Use el registro de auditoría para crear el perfil de AppArmor (SUSE tiene herramientas para esto, no estoy seguro acerca de otras distribuciones de Linux). Esto es monstruosamente tedioso, pero debe suceder si necesita este nivel de seguridad.
   1. Harás cosas como:
      • Aprobar el acceso de lectura a la mayoría de las bibliotecas del sistema
      • Aprobar los derechos de lectura y ejecución de los pocos comandos del sistema permitidos seleccionados
      • Aprobar acceso de escritura a espacios temporales
      • Aprobar la creación de socket, si es necesario
5. Establezca la política para hacer cumplir.
6. Inicia sesión como Bob, haz las cosas.
7. Hacer ajustes.

En mi opinión, solo necesita los pasos 2 y 3, ya que en combinación ambos evitan la capacidad de hacer algo dañino fuera de la caja cuidadosamente construida que configuró en ambos pasos.

Bueno, puedes configurar el shell del usuario en un programa que hayas escrito que solo les permita ejecutar ciertos scripts de shell.

Por supuesto, esto solo sería tan seguro como el programa y los scripts de shell; en la práctica, este tipo de shell restringido generalmente no es seguro contra un atacante inteligente.

No intente limitar los comandos, limite los permisos de archivo. Prácticamente no se puede limitar el acceso de las personas a las llamadas al sistema, por lo que todo lo que alguien tiene que hacer es proporcionar su propia copia de los comandos "peligrosos" que no desea que ejecuten, y está lleno.

Si desea que el usuario solo pueda ejecutar ciertos scripts / binarios, puede usar un shell restringido . Esto (como menciona el artículo de Wikipedia) no es completamente seguro, pero si puede garantizar que ninguna aplicación que se le permita ejecutar sea capaz de ejecutar un nuevo shell, entonces es una buena alternativa.

Para configurar un shell restringido de usuarios, establezca /bin/rbash(o similar, la mayoría de los shells entran en modo restringido cuando el binario se denomina r *** name *) como shell de usuarios. Luego, edite **. Bashrc (o equivalente) y configúrelo $PATHen un directorio donde se almacenen todos los archivos binarios / scripts permitidos.

Sí, es posible, pero en la práctica requeriría mucho trabajo y planificación. Puede crear scripts y hacer que se ejecuten como un uso privilegiado, luego elimine todos los privilegios del usuario en cuestión. O bien, puede configurar el shell del usuario en algo de su propia creación que le permita hacer solo lo que usted permite explícitamente.

Sin embargo, los permisos estándar en Linux hacen que sea casi imposible para un usuario normal "dañar el sistema". ¿Qué tipo de daño estás tratando de prevenir? Es trivial evitar que los usuarios puedan instalar software o ejecutar programas fuera de su directorio de inicio, y puede usar chroot para bloquear el sistema aún más.

Es posible que desee probar [lshell] [1] (shell limitado).

lshell es un shell codificado en Python, que le permite restringir el entorno de un usuario a conjuntos limitados de comandos, elegir habilitar / deshabilitar cualquier comando sobre SSH (por ejemplo, SCP, SFTP, rsync, etc.), registrar los comandos del usuario, implementar la restricción de tiempo, y más.

[1]: http://lshell.ghantoos.org/Overview lshell

La forma en que suelo implementar este tipo de restricciones requiere que se cumplan varias condiciones; de lo contrario, la restricción se puede eludir fácilmente:

• El usuario no pertenece al wheelgrupo, el único autorizado para usar su(impuesto a través de PAM).

• Al usuario se le proporciona una seguridad adecuada rbash con un solo lectura que PATHapunta a un privado ~/bin, este ~/bin/directorio contiene enlaces a utilidades simples:

  $ ll ~/bin
  total 0
  lrwxrwxrwx. 1 root dawud 14 Sep 17 08:58 clear -> /usr/bin/clear*
  lrwxrwxrwx. 1 root dawud  7 Sep 17 08:58 df -> /bin/df*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 egrep -> /bin/egrep*
  lrwxrwxrwx. 1 root dawud  8 Sep 17 08:58 env -> /bin/env*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 fgrep -> /bin/fgrep*
  lrwxrwxrwx. 1 root dawud  9 Sep 17 08:58 grep -> /bin/grep*
  lrwxrwxrwx. 1 root dawud 10 Sep 17 08:58 rview -> /bin/rview*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 rvim -> /usr/bin/rvim*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 sudo -> /usr/bin/sudo*
  lrwxrwxrwx. 1 root dawud 17 Sep 17 08:58 sudoedit -> /usr/bin/sudoedit*
  lrwxrwxrwx. 1 root dawud 13 Sep 17 08:58 tail -> /usr/bin/tail*
  lrwxrwxrwx. 1 root dawud 11 Sep 17 08:58 wc -> /usr/bin/wc*
  

• al usuario se le da una, de sólo lectura entorno restringido (pensar en cosas por el estilo LESSSECURE, TMOUT, HISTFILElas variables).

• el usuario se asigna al usuario SELinux staff_uy se le otorgan derechos para ejecutar comandos como otro usuario según sea necesario a través de sudo.

• del usuario /home, /tmpy posiblemente /var/tmpestán poliinstantiados a través de /etc/security/namespace.conf:

  /tmp       /tmp/.inst/tmp.inst-$USER-     tmpdir:create   root
  /var/tmp   /tmp/.inst/var-tmp.inst-$USER- tmpdir:create   root
  $HOME      $HOME/$USER.inst/              tmpdir:create   root
  

  Además, /etc/security/namespace.inithace que todos los archivos esqueléticos sean de solo lectura para el usuario y de su propiedad root.

De esta manera, puede elegir si $USERpuede ejecutar cualquier comando en su propio nombre (a través de un enlace en el ~/bindirectorio privado , provisto a través de /etc/skel, como se explicó anteriormente), en nombre de otro usuario (a través de sudo) o ninguno.

Sí, solo cambia los permisos de estos comandos.

Puede tener una mejor oportunidad de lucha escribiendo un comando de shell que se comporte según sus requisitos.

¿Qué no es apropiado de los permisos predeterminados para usuarios normales en Linux?