Página principal 
Introducción 

Seguridad Física 

Seguridad Local 

Seguridad del Sistema de Archivos 

Seguridad del Núcleo 

Seguridad de Red 

Seguridad del Root 

Preparación para la Seguridad 

¿Qué hacer en caso de Ruptura? 

Recursos 

segarchivos.gif (33117 bytes)

Permisos

Introducción

El árbol de directorios

Permisos

Enlaces

Tripwire

Limitar el espacio

Normas prácticas

Linux, como sistema multiusuario, asigna un propietario y un grupo a cada fichero (y directorio) y unos permisos al propietario, al grupo y al resto de los usuarios. La forma más rápida de comprobar esta característica es usar el comando ls -la. Así nos aparece el tipo de fichero, el propietario, el grupo, los permisos e información adicional. Por supuesto, el sistema de ficheros tiene que admitir esta característica, como es el caso del sistema de ficheros ext2 (Linux nativo). En los sistemas de ficheros pensados para entornos monousario, como msdos o vfat, no tenemos esta característica, por lo que son inseguros y su uso no es aconsejable bajo Linux.

Es conveniente tener claros los permisos que se pueden asignar a un fichero o directorio. Puede que algunas aplicaciones no funcionen bien si algún fichero no tiene el permiso o el propietario correctos, bien por falta de permisos o bien por exceso. Algunas aplicaciones son un poco quisquillosas en este aspecto. Por ejemplo, fetchmail es un programa que podemos usar para recoger el correo de un servidor pop (por ejemplo). Este programa se configura en el fichero .fetchmailrc, donde tendremos que indicar la clave que usamos en el servidor; pues bien, si este fichero tiene permiso de lectura para otro usuario que no sea el propietario, fetchmail no funcionará.

Otras aplicaciones, como por ejemplo inn (un servidor de noticias de Internet) tampoco funcionará si el propietario de sus ficheros es otro usuario distinto a news. Todo esto está perfectamente documentado en cada uno de los programas, por lo que es conveniente leer la documentación que aporta y las páginas del manual.

Permisos de ficheros y directorios

Como decíamos anteriormente, tenemos que asegurarnos de que los ficheros del sistema y los de cada usuario sólo son accesibles por quienes tienen que hacerlo y de la forma que deben. No sólo hay que protegerse de ataques o miradas indiscretas, también hay que protegerse de acciones accidentales.

En general, cualquier sistema UNIX divide el control de acceso a ficheros y directorios en tres elementos: propietario, grupo y otros. Tanto el propietario como el grupo són únicos para cada fichero o directorio. Eso sí, a un grupo pueden pertenecer múltiples usuarios. Otros hace referencia a los usuarios que ni son el propietario ni pertenecen al grupo.

Todas estas características se almacenan en el sistema de ficheros, en particular en un i-nodo, que es un elemento que describe las características de un fichero en disco (salvo su nombre).

Una rápida explicación de los permisos Unix:

Propiedad:
Qué usuario y grupo posee el control de los permisos del i-nodo. Se almacenan como dos valores numéricos, el uid (user id) y gid (group id).
Permisos:
Bits individuales que definen el acceso a un fichero o directorio. Los permisos para directorio tienen un sentido diferente a los permisos para ficheros. Más abajo se explican algunas diferencias.
  • Lectura (r):
    • Fichero: Poder acceder a los contenidos de un fichero
    • Directorio: Poder leer un directorio, ver qué ficheros contiene
  • Escritura (w):
    • Fichero: Poder modificar o añadir contenido a un fichero
    • Directorio: Poder borrar o mover ficheros en un directorio
  • Ejecución(x):
    • Fichero: Poder ejecutar un programa binario o guion de shell
    • Directorio: Poder entrar en un directorio

Estos permisos se pueden aplicar a:

  • usuario (u): El propietario del fichero
  • grupo (g): El grupo al que pertenece el fichero
  • otros (o): El resto de los usuarios del sistema
Nota:
Tenga mucho cuidado con aquellos directorios que tengan permiso de escritura. Cualquiera podría borrar un fichero, aunque no sea de su propiedad y esto puede ser un riesgo, tanto para el sistema como para los datos de los usuarios.

Además tenemos otros bits de permisos que no podemos pasar por alto cuando estamos tratando de temas de seguridad.

Sticky bit:
El sticky bit tiene su significado propio cuando se aplica a directorios. Si el sticky bit está activo en un directorio, entonces un usuario sólo puede borrar ficheros que son de su propiedad o para los que tiene permiso explícito de escritura, incluso cuando tiene acceso de escritura al directorio. Esto está pensado para directorios como /tmp, que tienen permiso de escritura global, pero no es deseable permitir a cualquier usuario borrar los ficheros que quiera. El sticky bit aparece como 't' en los listados largos de directorios.

drwxrwxrwt 19 root root 8192 Jun 24 14:40 tmp

Attributo SUID: (Para Ficheros)
Este bit describe permisos al identificador de usuario del fichero. Cuando el modo de acceso de ID de usuario está activo en los permisos del propietario, y ese fichero es ejecutable, los procesos que lo ejecutan obtienen acceso a los recursos del sistema basados en el usuario que crea el proceso (no el usuario que lo lanza). Por ejemplo /usr/bin/passwd es un ejecutable propiedad de root y con el bit SUID activo. ¿Por qué? Este programa lo puede usar cualquier usuario para modificar su clave de acceso, que se almacena en

-rw-r--r-- 1 root root 1265 Jun 22 17:35 /etc/passwd

pero según los permisos que observamos en este fichero, sólo root puede escribir y modificar en él. Entonces sería imposible que un usuario pudiera cambiar su clave si no puede modificar este fichero. La solución para este problema consiste en activar el bit SUID para este fichero:

-r-s--x--x 1 root root 10704 Apr 14 23:21 /usr/bin/passwd

de forma que cuando se ejecute, el proceso generado por él es un proceso propiedad de root con todos los privilegios que ello acarrea.

¿Piensa que esto puede ser un riesgo para la seguridad? Efectivamente lo podría ser si no mantenemos un mínimo de atención, ya que en este tipo de programas se pueden producir desbordamientos de búfer que comprometan su sistema. Recuerde siempre lo siguiente:

  • No asignar el bit SUID salvo cuando sea estrictamente necesario.
  • Comprobar que cualquier programa con est bit activo no tiene ningún desbordamiento de buffer (conocido).
  • No asignarlo jamás si el programa permite salir a la shell.
Atributo SGID: (Para ficheros)
Si está activo en los permisos de grupo, este bit controla el estado de "poner id de grupo" de un fichero. Actúa de la misma forma que SUID, salvo que afecta al grupo. El fichero tiene que ser ejecutable para que esto tenga algún efecto.
Atributo SGID: (Para directorios)
Si activa el bit SGID en un directorio ( con "chmod g+s directorio"), los ficheros creados en ese directorio tendrán puesto su grupo como el grupo del directorio.

A continuación se describen los significados de los permisos de acceso individuales para un fichero. Normalmente un fichero tendrá una combinación de los siguientes permisos:

-r-------- Permite acceso de lectura al propietario
--w------- Permite modificar o borrar el fichero al propietario
---x------ Permite ejecutar este programa al propietario, (los guiones de shell también requieren permisos de lectura al propietario)
---s------ Se ejecutará con usuario efectivo ID = propietario
-------s-- Se ejecutará con usuario efectivo ID = grupo
-rw------T No actualiza "instante de última modificación". Normalmente usado para ficheros de intercambio (swap)
---t------ No tiene efecto. (antes sticky bit)

A continuación se describen los significados de los permisos de acceso individuales para un directorio. Normalmente un directorio tendrá una combinación de los siguientes permisos:

dr-------- Permite listar el contenido pero no se pueden leer los atributos.
d--x------ Permite entrar en el directorio y usar en las rutas de ejecución completas.
dr-x------ Permite leer los atributos del fichero por el propietario.
d-wx------ Permite crear/borra ficheros.
d------x-t Previene el borrado de ficheros por otros con acceso de escritura. Usado en /tmp
d---s--s-- No tiene efecto

Los ficheros de configuración del sistema (normalmente en /etc) es habitual que tengan el modo 640 (-rw-r-----), y que sean propiedad del root. Dependiendo de los requisitos de seguridad del sistema, esto se puede modificar. Nunca deje un fichero del sistema con permiso de escritura para un grupo o para otros. Algunos ficheros de configuración, incluyendo /etc/shadow, sólo deberían tener permiso de lectura por root, y los directorios de /etc no deberían ser accesibles, al menos por otros.

SUID Shell Scripts
Los scripts de shell SUID son un serio riesgo de seguridad, y por esta razón el núcleo no los acepta. Sin importar lo seguro que piense que es su script de shell, puede ser utilizado para que un cracker pueda obtener acceso a una shell de root.

 

Copyright © 1997-1999 Gonzalo Álvarez Marañón y Pedro Pablo Fábrega Martínez. Todos los derechos reservados.

Criptonomicón es un servicio ofrecido libremente desde el Instituto de Física Aplicada del CSIC. Para información sobre privacidad, por favor consulte la declaración de política sobre privacidad. Para sugerencias, comentarios o quejas, acuda al libro de visitas. Para contribuir al Criptonomicón, lea la página de contribuciones.