INGENIERIA EN SISTEMAS COMPUTACIONALES

6º “B”

Sistemas Operativos

Nombre del trabajo:

Actividad 3 - “Seguridad en sistemas de archivos”

Facilitador:

FACILITADOR: L.I. JORGE EDGAR ROJAS MAGDALENO

Presentan:
Maldonado Cortes Juan Manuel
Eduardo Manzo Hernández
Héctor Alejandro Vega Méndez
Felipe Altamirano Garibay
Marco Antonio Silva Aguilar
Gerardo Torres Espinoza
Juan Carlos Pérez Salazar
Jorge Alberto García Martínez

Zamora de Hidalgo, Mich. Mayo del 2011

 Actividad 3 - “Seguridad en sistemas de archivos”

Índice

Listas de control de acceso: ACLs .............................................................................................. 2

Representación de los permisos sobre los ficheros .................................................................. 3
Fuentes ...................................................................................................................................... 4

Listas de control de acceso: ACLs

Las listas de control de acceso (ACLs, Access Control Lists) proveen de un nivel adicional de seguridad a
los ficheros extendiendo el clásico esquema de permisos en Unix: mientras que con estos últimos sólo
podemos especificar permisos para los tres grupos de usuarios habituales (propietario, grupo y resto),
las ACLs van a permitir asignar permisos a usuarios o grupos concretos; por ejemplo, se pueden otorgar
ciertos permisos a dos usuarios sobre unos ficheros sin necesidad de incluirlos en el mismo grupo. Este
mecanismo está disponible en la mayoría de Unices (Solaris, AIX, HP-UX...), mientras que en otros que
no lo proporcionan por defecto, como Linux, puede instalarse como un software adicional. A pesar de
las agresivas campañas de marketing de alguna empresa, que justamente presumía de ofrecer este
modelo de protección en sus sistemas operativos frente al `arcaico' esquema utilizado en Unix, las listas
de control de acceso existen en Unix desde hace más de diez años.

Los ejemplos que vamos a utilizar aquí (órdenes, resultados...) se han realizado sobre Solaris; la idea es
la misma en el resto de Unices, aunque pueden cambiar las estructuras de las listas.

Si habitualmente queremos saber si a un usuario se le permite cierto tipo de acceso sobre un fichero (en
este caso, sshd) no tenemos más que hacer un listado largo:

anita:~# ls -l /usr/local/sbin/sshd
-rwx------ 1 root bin 2616160 Apr 28 1997 /usr/local/sbin/sshd
anita:~#

Viendo el resultado, directamente sabemos que el fichero sshd puede ser ejecutado, modificado y leído
por el administrador, pero por nadie más; sin embargo, no conocemos el estado de la lista de control de
acceso asociada al archivo. Para ver esta lista, en Solaris se ha de utilizar la orden getfacl:

anita:/# getfacl /usr/local/sbin/sshd

# file: /usr/local/sbin/sshd ------------------archivo: dirección/nombre

# owner: root ------------------Propietario: origen
# group: bin
user::rwx ------------------Usuario: r (read) w (write) x (executable)
group::--- #effective:---
mask:---
other:---
anita:/#

Acabamos de visualizar una lista de control de acceso de Solaris; en primer lugar se nos indica el nombre
del fichero, su propietario y su grupo, todos precedidos por `#'. Lo que vemos a continuación es la
propia lista de control: los campos user, group y other son básicamente la interpretación que getfacl
hace de los permisos del fichero (si nos fijamos, coincide con el resultado del ls -l). El campo mask es
muy similar al umask clásico: define los permisos máximos que un usuario (a excepción del propietario)
o grupo puede tener sobre el fichero. Finalmente, el campo effective nos dice, para cada usuario
(excepto el propietario) o grupo el efecto que la máscara tiene sobre los permisos: es justamente el

2
 Actividad 3 - “Seguridad en sistemas de archivos”

campo que tenemos que analizar si queremos ver quién puede acceder al archivo y de qué forma.

Sin embargo, hasta ahora no hemos observado nada nuevo; podemos fijarnos que la estructura de la
lista de control de acceso otorga los mismos permisos que las ternas clásicas. Esto es algo normal en
todos los Unix: si no indicamos lo contrario, al crear un fichero se le asocia una ACL que coincide con los
permisos que ese archivo tiene en el sistema (cada archivo tendrá una lista asociada, igual que tiene
unos permisos); de esta forma, el resultado anterior no es más que la visión que getfacl tiene de los bits
rwx del fichero.

Lo interesante de cara a la protección de ficheros es extender los permisos clásicos del archivo,
modificando su lista asociada. Esto lo podemos conseguir con la orden setfacl

anita:~# setfacl -m user:toni:r-x /usr/local/sbin/sshd

anita:~# getfacl /usr/local/sbin/sshd

# file: /usr/local/sbin/sshd
# owner: root
# group: bin
user::rwx
user:toni:r-x #effective:---
group::--- #effective:---
mask:---
other:---
anita:~#

Otra característica que tiene Solaris es la capacidad de leer las entradas de una lista de control de acceso
desde un fichero en lugar de indicarlas en la línea de órdenes, mediante la opción -f de setfacl; el
formato de este fichero es justamente el resultado de getfacl, lo que nos permite copiar ACLs entre
archivos de una forma muy cómoda.

Representación de los permisos sobre los ficheros

Imaginemos que tenemos un fichero con unos determinados permisos de los que queremos calcular su
equivalente octal, o que conocemos los permisos a asignar pero no su equivalente numérico; por
ejemplo, necesitamos asignar a un fichero la terna rw-r--wx, que en la práctica no tiene mucho sentido
pero que a nosotros nos sirve de ejemplo. Lo primero que debemos hacer a partir de estos bits rwx es
calcular su equivalente binario, para lo que asignamos el valor `1' si un determinado permiso está activo
(es decir, si aparece una r, w o x en él) y un `0' si no lo está (aparece un `-'); así, el equivalente binario de
la terna propuesta es 110100011. Ahora simplemente hemos de pasar el número del sistema binario al
octal: lo dividimos en grupos de tres elementos (110 100 011) y de cada uno de ellos calculamos su
equivalente octal

Ya tenemos los tres números de nuestra terna de permisos, o lo que es lo mismo, la representación
octal de los bits iniciales: 643. Por tanto, si necesitamos asignar esta terna a un cierto fichero,
simplemente hemos de ejecutar la orden chmod indicándole este número y el nombre del archivo:

anita:~# chmod 643 /tmp/fichero

anita:~# ls -l /tmp/fichero

-rw-r---wx 1 root root 799 Feb 8 19:47 /tmp/fichero*

anita:~#

La forma de trabajar de chmod comentada requiere que se indique explícitamente el valor octal de los
bits rwx que queremos otorgar a un fichero; sin importar el valor de las ternas que poseía antes de
ejecutar la orden, estamos asignando a los permisos del archivo el nuevo valor valor indicado en la línea
de comandos. Existe otra forma de trabajo de chmod denominada `simbólica' en la que no necesitamos
indicar el valor octal de todos los bits, sino que especificamos únicamente parámetros para los valores

3
 Actividad 3 - “Seguridad en sistemas de archivos”

de los permisos que el archivo posee y deseamos modificar. En lugar de utilizar el equivalente octal,
utilizamos símbolos (de ahí el nombre de esta forma de trabajo) que representan la activación o
desactivación de ciertos bits en cada una de las tres ternas; la sintaxis básica de chmod en este caso es
la siguiente:

chmod ugoa{+,-}{rwxst} fichero

Podemos ver que el valor simbólico comienza por cero o más letras que indican sobre que terna de los
permisos se van a realizar los cambios (u para propietario del fichero, g para grupo, o para resto de
usuarios y a para las tres ternas; si no se especifica ninguna letra, se asume a). A ellas les sigue un signo
`+' o `-' en función de si deseamos activar o resetar el bit sobre el que trabajamos, parámetro indicado
por el último conjunto formado por una o más letras, r para el permiso de lectura, w para escritura, x
para ejecución, s para SUID o SGID y t para bit de permanencia (el significado de estos dos últimos se
explicará en el punto siguiente). Entre los tres campos del valor simbólico no se insertan espacios:

anita:~# ls -l /tmp/fichero

-r-------- 1 root other 902 Feb 9 05:05 /tmp/fichero

anita:~# chmod +x /tmp/fichero

anita:~# ls -l /tmp/fichero

-r-x--x--x 1 root other 902 Feb 9 05:05 /tmp/fichero

anita:~# chmod og-x /tmp/fichero

anita:~# ls -l /tmp/fichero

-r-x------ 1 root other 902 Feb 9 05:05 /tmp/fichero

anita:~# chmod ug+rwx /tmp/fichero

anita:~# ls -l /tmp/fichero

-rwxrwx--- 1 root other 902 Feb 9 05:05 /tmp/fichero

anita:~#

Esta forma de trabajo simbólica es menos utilizada en la práctica que la forma octal, pero en ciertas
situaciones es muy útil, por ejemplo si deseamos activar todos los permisos de ejecución de un archivo o
si queremos setuidarlo: un simple chmod +x o chmod u+s es suficiente en estos casos, y evitamos
preocuparnos por si modificamos el resto de permisos.

Fuentes

http://www.rediris.es/cert/doc/unixsec/node10.html#perm

http://es.wikipedia.org/wiki/Lista_de_control_de_acceso

http://www.escomposlinux.org/iarenaza/articulo-acls/acls-linux-samba.html

http://www.wikilearning.com/tutorial/seguridad_en_unix_y_redes-
listas_de_control_de_acceso_acls/9777-17