Cómo garantizar la separación del usuario en un servidor shell de la vieja escuela


9

Quiero ejecutar un servidor shell de la vieja escuela para un par de personas, es decir. uno donde los usuarios obtienen acceso ssh para que puedan ejecutar software (propio o proporcionado). Mi preocupación es la separación apropiada entre los usuarios.

No quiero que se vean los procesos, accedan a los archivos de los demás (a menos que esté explícitamente permitido), etc. Sería bueno no ser mordido por cada error de escalada de privilegios o reiniciar el servidor con cada actualización menor del núcleo. Sería perfecto mantener la opción de ejecutar servicios comunes (como alojamiento web y de correo) con estas medidas de seguridad.

En el pasado usaba grsec, pero esto requiere permanecer en un kernel más antiguo y lidiar con la molestia de compilarlo usted mismo. ¿Existe una forma más moderna y más Ubuntu de garantizar la separación de los usuarios en un servidor compartido?

¿Quizás pueda hacer algo con AppArmor para ese efecto? ¿O tal vez hay un repositorio de núcleos preconfigurados para entornos compartidos? ¿O una solución basada en contenedores? Estos han estado de moda últimamente.


Respuestas:


9

hidepid

procfsen Linux ahora es compatible con la hidepidopción. De man 5 proc:

hidepid=n (since Linux 3.3)
      This   option   controls  who  can  access  the  information  in
      /proc/[pid]  directories.   The  argument,  n,  is  one  of  the
      following values:

      0   Everybody  may  access all /proc/[pid] directories.  This is
          the traditional behavior, and  the  default  if  this  mount
          option is not specified.

      1   Users  may  not  access  files and subdirectories inside any
          /proc/[pid]  directories  but  their  own  (the  /proc/[pid]
          directories  themselves  remain  visible).   Sensitive files
          such as /proc/[pid]/cmdline and /proc/[pid]/status  are  now
          protected  against other users.  This makes it impossible to
          learn whether any user is running  a  specific  program  (so
          long  as  the program doesn't otherwise reveal itself by its
          behavior).

      2   As for mode 1, but in addition the  /proc/[pid]  directories
          belonging  to other users become invisible.  This means that
          /proc/[pid] entries can no longer be used  to  discover  the
          PIDs  on  the  system.   This  doesn't  hide the fact that a
          process with a specific PID value exists (it can be  learned
          by  other  means,  for  example,  by "kill -0 $PID"), but it
          hides a process's UID and  GID,  which  could  otherwise  be
          learned  by  employing  stat(2)  on a /proc/[pid] directory.
          This greatly complicates an  attacker's  task  of  gathering
          information   about  running  processes  (e.g.,  discovering
          whether some daemon is  running  with  elevated  privileges,
          whether  another  user  is  running  some sensitive program,
          whether other users are running any program at all,  and  so
          on).

gid=gid (since Linux 3.3)
      Specifies  the  ID  of  a  group whose members are authorized to
      learn  process  information  otherwise  prohibited  by   hidepid
      (ie/e/,  users  in this group behave as though /proc was mounted
      with hidepid=0.  This group should be used instead of approaches
      such as putting nonroot users into the sudoers(5) file.

Por lo tanto, montar /proccon hidepid=2es suficiente para ocultar los detalles de los procesos de otros usuarios en Linux> 3.3. Ubuntu 12.04 viene con 3.2 por defecto, pero puede instalar núcleos más nuevos. Ubuntu 14.04 y superior cumplen fácilmente este requisito.

ACL

Como primer paso, elimine los rwxpermisos para otros de cada directorio de inicio (y también para el grupo, si lo requiere). Supongo, por supuesto, que las carpetas que contienen los directorios principales no tienen permisos de escritura para nadie, excepto root.

Luego, otorgue servicios como el servidor web y el servidor de correo a los directorios apropiados mediante ACL. Por ejemplo, para otorgar acceso al proceso del servidor web a las páginas de inicio del usuario, suponiendo que www-dataes el usuario y ~/public_htmldonde se guarda la página de inicio:

setfacl u:www-data:X ~user
setfacl d:u:www-data:rX ~user/public_html

Del mismo modo, agregue ACL para los procesos de correo y los directorios del buzón.

Las ACL están habilitadas de manera predeterminada en ext4 al menos en Ubuntu 14.04 y superior.

/tmp y umask

Otro problema es /tmp. Establezca la opción umaskpara que los archivos no sean legibles en grupo o en todo el mundo, de modo que los archivos temporales de los usuarios no sean accesibles para otros usuarios.


Con estas tres configuraciones, los usuarios no deberían poder acceder a los archivos de otros usuarios ni examinar sus procesos.


2
Una alternativa o adición a los archivos separados colocados en /tmpel paquete libpam-tmpdir: crea un directorio propiedad de root, no legible por el mundo y directorios /tmp/userpropiedad del usuario, no legible por el mundo, no transitable /tmp/user/$UIDpor el mundo para cada usuario (en su primer iniciar sesión) y establece la variable de entorno TMP_DIRpara apuntar a este último. La mayoría de los programas funcionan bien y colocan sus archivos temporales dentro $TMP_DIRsi están configurados.
David Foerster
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.