09 - Listas de control de acceso (ACL)

Cómo hemos visto hasta ahora los permisos nativos, o permisos UGO son muy estrictos en el sentido de que permiten configurar permisos de lectura, escritura o ejecución solamente a tres entidades: el usuario propietario, el grupo propietario, el resto de usuarios.

¿Qué es una acl?

Es una funcionalidad que va a permitir configurar permisos no solo a las tres entidades UGO predeterminadas sino también a cualquier otro usuario o grupo específico.

A nivel práctico esto se traduce en una lista que contiene entradas, una para cada entidad UGO y una para cada usuario o grupo específico que el dueño del archivo o root desee añadir. Las entradas de la lista reflejaran los permisos efectivos de cada una de las entidades. 

ACL del fichero ejemplo1

Si analizamos la imagen podemos observar:

• Con el comando habitual para ver lo permisos [ls] nos damos cuenta que el fichero ejemplo1 tiene permisos extendidos en su ACL porque al final de las ternas de permisos le acompaña el signo +
• Al consultar la ACL vemos todas las entidades con sus permisos, por una parte las entidades UGO y por otra entidades específicas como el usuario smr o los grupos alumnos y profesores
• Aparece una entrada "extraña" mask que no se corresponde con ninguna entidad y que también tiene permisos asociados.

¿Qué es la máscara en una ACL?

Antes de explicar que es la máscara, comentar algo importante:

Cuando un fichero tiene permisos extendidos en su ACL (+), la terna de grupo propietario que hasta ahora representaba los permisos del grupo propietario deja de hacer su función habitual y pasa a representar un concepto más amplio, la máscara. Las otras dos ternas de usuario y otros permanecen intactas.

La máscara es el límite o valor máximo al que pueden optar tanto los permisos de grupo propietario como los de todos aquellos usuarios o grupos específicos que aparezcan en la ACL. Afecta a cualquier entidad que no sea el usuario propietario o el grupo otros.

Sobre el ejemplo inicial, al eliminar el permiso de escribir de la máscara todas las entidades que no sean el usuario propietario o el grupo otros se ven afectadas por el nuevo limite que representa la máscara. Como el nuevo limite marcado por la máscara es el permiso de lectura, en aquellas entidades que lo superaban el sistema refleja los nuevos permisos efectivos. 

Efectos de modificar la máscara de la ACL de ejemplo1

De igual forma si lo que hacemos es modificar los permisos de la entidad grupo o cualquier otra entidad específica la máscara se recalcula automáticamente para dar soporte al nuevo permiso que se está solicitando afectando de nuevo a las demás entidades (usuario y otros NO)

Efectos de modificar los permisos G

Es decir que si modifico la máscara se recalculan los permisos de G y las entidades específicas y si modifico los permisos de G o las entidades especificas se recalcula la máscara

Requisitos de uso de ACL               

• los módulos de sistemas de archivos tienen que tener soporte para ACL en el kernel Linux.
• la opción acl en la línea de montaje del sistema de ficheros debe activarse. Si son sistemas de ficheros permanentes esto estaría en /etc/fstab
• utilidades para gestionar las ACL’s.

Default ACL

Las ACL se pueden aplicar a ficheros y directorios. En el caso de los directorios nos puede interesar propagar de forma automática la ACL de un directorio a los ficheros y subdirectorios que se creen (con posterioridad) dentro de él. Este tipo especial de ACL disponible para directorios se conoce como ACL predeterminada (default ACL) 

Funcionamiento de las ACL predeterminadas

Cuando se crea un fichero o un subdirectorio dentro de un directorio que tiene definida una ACL predeterminada hay que tener en cuenta las siguientes consideraciones:

• Los subdirectorios heredan la ACL predeterminada del directorio padre y se refleja de nuevo  como ACL predeterminada y también como ACL normal
• Los ficheros heredan la ACL predeterminada y se refleja solo como ACL normal
• Los permisos resultantes serían la intersección entre los permisos predeterminados (777 directorios y 666 ficheros) y los de la ACL predeterminada

Transmisión de ACL predeterminada a un fichero

Observación: Recuerda que si el directorio padre NO tiene ninguna ACL predeterminada, los permisos resultantes son los habituales calculados a través de la máscara definida con umask (002 habíamos dicho en U20.04)

08 - Permisos especiales

t (sticky bit) - directorios 

Cuando se lo asignamos a un directorio que tiene todos los permisos, conseguimos que los elementos que haya dentro (ficheros o subdirectorios), sólo puedan ser modificados o borrados por el propietario del elemento, el propietario del directorio o el root. El resto de usuarios aunque tenga permisos sobre dichos elementos solo podrá leerlos.

El sistema lo tiene configurado en algunos directorios públicos como por ejemplo /tmp ó /var/tmp. El bit t se activa o desactiva con el comando chmod empleando notación simbólica u octal (sumando 1000 a los permisos).

Activación sticky bit

Antiguamente se usaba también para mantener la imagen de un binario en memoria después de finalizar la ejecución del mismo pero con los avances en el hardware ya no se usa para esta función.

s nivel usuario (SUID)

Cuando el propietario de un binario asigna el atributo s a a la terna de usuario, el resto de usuarios podrá ejecutar el binario con los mismos privilegios que el propietario del binario

Dicho de otra forma, el sistema operativo cree que el que está ejecutando el binario es el propietario del binario en vez del usuario que lo está ejecutando realmente. Se produce lo que se denomina un cambio de dominio temporal a nivel de usuario durante la ejecución del binario.

Pero, ¿a que nos referimos con "los mismos privilegios que el propietario del binario?

Veamos un ejemplo, el binario passwd

Es un binario del sistema, /usr/bin/passwd, que cualquier usuario puede ejecutar para cambiar su contraseña personal. Este binario, como se puede observar, viene con el bit s activado a nivel de usuario.

Si recordamos un poco el tema de las contraseñas, el sistema las gestiona a través de dos ficheros, /etc/passwd y /etc/shadow que solo puede modificar su propietario, el root. No es difícil imaginar que el binario passwd lo que hace es modificar las líneas de dichos ficheros para conseguir su objetivo que es cambiar la contraseña.

¿Cómo es posible entonces, que un usuario normal, pueda modificar ficheros propiedad del root y sobre los que no tiene permisos de escritura?

La explicación es que el binario passwd que intenta la modificación de dichos ficheros tiene activado el SUID y el sistema se cree que el que lo está ejecutando es el propietario del binario que es el root y precisamente el root si tiene permisos para modificar dichos ficheros

Ejemplo de suid en el sistema 

El suid se puede activar con chmod usando notación simbólica u octal (sumando 4000) 

s nivel grupo (SGID)

Cuando el propietario de un binario asigna el atributo s a a la terna de grupo, el resto de usuarios podrá ejecutar el binario con los mismos privilegios que el grupo propietario del binario

Dicho de otra manera, el sistema cree que el usuario que ejecuta el binario tiene como grupo propietario el grupo propietario del binario en vez de el suyo, adquiriendo los privilegios del grupo propietario del binario. Se produce un cambio de dominio temporal a nivel de grupo durante la ejecución del binario.

Se activa o desactiva este bit empleando la notación simbólica de la siguiente manera: chmod g+s binario ó chmod g-s binario. También de forma octal se puede expresar sumando 2000 a los permisos del archivo. Busca un ejemplo en el sistema y razónalo.

 

SGID directorios

En el caso particular de aplicar el bit s a nivel de grupo sobre un directorio, los efectos son que a la hora de crear ficheros en ese directorio, el grupo propietario con el que salen por defecto dichos ficheros no será el grupo propietario del usuario que los crea, como debería ocurrir en situación normal, sino que será el grupo propietario del directorio que los contiene.

07 - Estructura de un archivo. Enlaces

Estructura de un archivo

Los archivos (ficheros o directorios) están formados básicamente por tres elementos:

datos

Es la información propiamente dicha que contiene el fichero o directorio.

i-nodo

Es una estructura de datos que almacena información sobre el archivo y que se identifica por un número entero único (i-nodo). Almacena metadatos como el tamaño, UID, GID, número de enlaces, etc.

nombre de archivo

Es un nombre de archivo asociado al i-nodo.

Metadatos de un i-nodo

Es importante entender que aunque un i-nodo es único y apunta a unos datos determinados puede tener diferentes nombres.

Enlace duro (hard link)

Es cada uno de los diferentes nombres asociados a un mismo i-nodo que como hemos dicho apunta a un único contenido. En términos prácticos son distintos nombres que se le pueden dar a un mismo fichero.

Esquema enlace duro

 

Características enlaces duros

• El i-nodo y la zona de datos asociada estarán disponibles mientras estén referenciados por algún nombre. Ejemplo, si borras fich_original sigues pudiendo acceder a través de hlink1 y hlink2
• El tamaño de un enlace duro es mínimo porque no es realmente un fichero nuevo sino un puntero sobre el i-nodo
• Los permisos y propiedad de todos los enlaces duros son idénticos que los del original
• Se puede mover un enlace duro pero solo dentro de la misma partición donde se creó
• No es posible crear enlaces duros a carpetas

Las ventajas de uso de los enlaces duros se basan en la capacidad de tener copias de un fichero en diferentes ubicaciones sin que ocupen espacio en el disco y algunas aplicaciones se aprovechan de esta funcionalidad, copias de seguridad incremental, clasificación de información, etc.

Enlace blando (soft link)

Un enlace simbólico es un fichero independiente cuyo contenido (zona de datos) apunta a la ruta del fichero con el que está vinculado. En términos prácticos se trata de un tipo de fichero "especial" que apunta a otro fichero cuyo contenido es diferente al suyo.

Esquema enlace blando (o simbólico)

Características enlaces blandos

• Cómo la zona de datos del enlace blando apunta la ruta de un fichero, si el fichero se elimina o se mueve a otra ubicación el enlace se rompe.
• El tamaño de un enlace blando ocupa lo que necesita para almacenar la ruta del fichero al que apunta.
• En GNU/Linux los permisos de los enlaces blandos no tienen efecto y están todos activados
• Se puede hacer enlaces blandos a ficheros de cualquier partición o ubicación
• Se permite enlaces blandos a directorios 
• Son mas lentos que los enlaces duros

Las ventajas de uso de los enlaces blandos se basan en la capacidad de abreviar rutas y enlazar ficheros y directorios desde cualquier parte, lo que permite por ejemplo a los servicios del sistema referenciar ficheros alejados, expandir el sistema de archivos a otras ubicaciones, sincronizar ficheros etc.

06 - Usuarios y Grupos

Usuarios

A diferencia de Windows los sistemas Linux son multiusuario, esto es que varios usuarios diferentes  pueden trabajar simultáneamente en el mismo sistema.

/etc/passwd

Contiene información de las cuentas de usuarios y sus características.

• UID [User ID]

Número de identificación único de usuario. Los usuarios pueden cambiar muchos parámetros, incluso su name, pero el UID no lo deben cambiar nunca. El UID del root es 0. Las cuentas de servicios y demonios tienen los UID más bajos, mientras que las de usuarios finales comienzan en el valor definido en UID_MIN en el fichero /etc/login.defs.

• GID [Group ID]

Número de identificador único de grupo. Varios usuarios pueden tener el mismo grupo, aunque al crear un usuario se crea un grupo con ese mismo nombre por defecto salvo que se indique lo contrario. Los datos del grupo aparecen en /etc/group.

• GECOS

Campo de comentarios que incluye información extra sobre el usuario (nombre real, dirección…) Informalmente se le llama información finger.

• Home directory

Directorio de inicio del usuario. Los usuarios finales se suelen situar bajo /home.

• Shell

La shell que utiliza por defecto el usuario (en muchos casos es /bin/bash). Si el usuario tiene /sbin/nologin o /usr/bin/false, significa que no tiene permiso para loguearse en el sistema, lo cual es común en daemons como medida de seguridad.

/etc/shadow

Contiene información sobre contraseñas de los usuarios de /etc/passwd, que almacena de manera cifrada.

Comandos de gestión de usuarios

Grupos

Todos los usuarios pertenecen a un único grupo principal o primario, es el que consta como su GID en /etc/passwd y opcionalmente pueden pertenecer a otros grupos secundarios o suplementarios que se gestionarían desde /etc/groups

Los grupos permiten conceder permisos a un conjunto de usuarios simultáneamente.

/etc/group

Contiene información sobre los grupos del sistema.

Campo 1: Nombre del grupo

Campo 2: Password que permite a un usuario cambiar de grupo. Si está vacío no requiere contraseña, y una x significa que se gestiona mediante el archivo /etc/gshadow.

Campo 3: GID del grupo.

Campo 4 : usuarios miembros del grupo

De forma similar, al fichero /etc/shadow, existe el fichero /etc/gshadow, que almacena los passwords de los grupos encriptados con un hash y también trabaja con los símbolos asterisco * y exclamación !.

Comandos de gestión de grupos

05 - Sudo, Su y Sudo su

Superusuario o root

Los sistemas operativos GNU/Linux se caracterizan por tener un usuario con permisos totales sobre el sistema y tradicionalmente se le llama root ó superusuario. Su carpeta personal se encuentra en /root

En Ubuntu, la cuenta del superusuario o root viene desactivada por defecto, por seguridad. Es una protección por defecto contra posibles destrozos accidentales.

Sudo

Sudo permite a los usuarios ejecutar comandos como si fuera el root, pero solo a ciertos usuarios "especiales". Estos usuarios se denominan sudoers (los que pueden hacer sudo). Como es de imaginar, el usuario que instala el sistema es un sudoer.

/etc/sudoers

Es el fichero que contiene los usuarios que pueden realizar sudo, en particular el usuario que instala el SO pertenece al grupo sudo y este a su vez está incluido en el fichero con privilegios para ejecutar cualquier comando. El fichero es propiedad del root y solo él puede modificarlo por seguridad

Cuando se precede una orden de carácter administrativo del comando sudo, el sistema pide por defecto la contraseña cada cierto tiempo al usuario sudoer para confirmar que se trata de él. Aunque se puede desactivar dicho comportamiento, no es recomendable (timestamp_timeout)

Su

Su significa super usuario y también switch user y es precisamente para lo que sirve, para cambiar de usuario sin necesidad de cerrar la sesión del usuario actual, por supuesto tenemos que conocer su contraseña. También se puede usar para cambiar de usuario al root (siempre que la cuenta no esté deshabilitada)

A diferencia de sudo, su puede ser utilizado por cualquier usuario, no es necesario que sea un sudoer.

Sudo su

Para complicar un poco más, está la combinación de ambos comandos, ampliamente usada por comodidad. Permite a usuario sudoer cambiar al root (incluso si la cuenta del root está deshabilitada). No será necesario introducir sudo para ejecutar comandos de índole administrativo mientras se esté en este modo

En el ejemplo que sigue:

• intento de cambiar al root pero la cuenta está deshabilitada o fallo en la contraseña
• cambio al usuario pepe
• intento fallido de pepe de hacer sudo (no es un sudoer)
• intento satisfactorio de asir de hacer sudo (si es un sudoer) 

Observación: Puedes teclear sudo su - y además de cambiar al root te dejaría posicionado en el home del root 

Activar la cuenta del root

Si a pesar de la recomendación se desea trabajar con la cuenta del root directamente, el proceso es tan simple como asignarle una contraseña a dicho usuario a través del comando passwd.

En el ejemplo que sigue:

• activación de la cuenta root (asignarle contraseña)
• cambio de usuario al root con comando su
• desactivación de la cuenta root
• intento fallido de cambio de usuario al root con comando su

Si la cuenta del root permanece desactivada, ningún usuario normal (los que no son sudoers), podrá dedicarse a intentar usar el comando su root para tratar de averiguar la contraseña del superusuario.

Conclusiones

• Por defecto y por seguridad, Ubuntu viene con la cuenta de root desactivada.
• Un sudoer puede ejecutar ordenes como si fuera el root.
• Un sudoer puede cambiar al root esté o no activada la cuenta del root.
• Cualquiera puede usar su para cambiar a otro usuario si sabe su login y password
• Cualquier puede usar su para cambiar al root si sabe su login y password por eso es conveniente que la cuenta del root permanezca desactivada