Next: Recuperación de datos Up: El sistema de ficheros Previous: Atributos de un archivo Índice General
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 # owner: root # group: bin user::rwx 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 campo que tenemos que analizar si queremos ver quién puede acceder al archivo y de qué forma.
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:~#Como vemos, acabamos de modificar la lista de control de acceso del archivo para asignarle a toni permiso de ejecución y lectura sobre el mismo. La orden setfacl se utiliza principalmente de tres formas: o bien añadimos entradas a la ACL, mediante la opción -m seguida de las entradas que deseemos añadir separadas por comas (lo que hemos hecho en este caso, aunque no se han utilizado comas porque sólo hemos añadido una entrada), o bien utilizamos el parámetro -s para reemplazar la ACL completa (hemos de indicar todas las entradas, separadas también por comas), o bien borramos entradas de la lista con la opción -d (de sintaxis similar a -m). Cada entrada de la ACL tiene el siguiente formato:
anita:/usr/local/sbin$ id uid=100(toni) gid=10(staff) anita:/usr/local/sbin$ ./sshd bash: ./sshd: Permission denied anita:/usr/local/sbin$>Qué ha sucedido? Nada anormal, simplemente está actuando la máscara sobre sus permisos (antes hemos dicho que debemos fijarnos en el campo effective, y aquí podemos comprobar que no se ha modificado). Para solucionar esto hemos de modificar el campo mask:
anita:~# setfacl -m mask:r-x /usr/local/sbin/sshd anita:~#Si ahora toni intenta acceder al fichero para leerlo o ejecutarlo, ya se le va a permitir:
anita:/usr/local/sbin$ id uid=100(toni) gid=10(staff) anita:/usr/local/sbin$ ./sshd /etc/sshd_config: No such file or directory ...Aunque obtenga un error, este error ya no depende de la protección de los ficheros sino de la configuración del programa: el administrador obtendría el mismo error. No obstante, sí que hay diferencias entre una ejecución de toni y otra del root, pero también son impuestas por el resto del sistema operativo Unix: toni no podría utilizar recursos a los que no le está permitido el acceso, como puertos bien conocidos, otros ficheros, o procesos que no le pertenezcan. Hay que recordar que aunque un usuario ejecute un archivo perteneciente al root, si el fichero no está setuidado los privilegios del usuario no cambian. Sucede lo mismo que pasaría si el usuario tuviera permiso de ejecución normal sobre el fichero, pero éste realizara tareas privilegiadas: podría ejecutarlo, pero obtendría error al intentar violar la protección del sistema operativo.
anita:~# ls -l /usr/local/sbin/sshd -rwx------+ 1 root bin 2616160 Apr 28 1997 /usr/local/sbin/sshd 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:
anita:~# getfacl /usr/local/sbin/sshd >/tmp/fichero anita:~# setfacl -f /tmp/fichero /usr/local/sbin/demonio anita:~# getfacl /usr/local/sbin/demonio # file: /usr/local/sbin/demonio # owner: root # group: other user::rwx user:toni:r-x #effective:r-x group::--- #effective:--- mask:r-x other:--- anita:~#Esto es equivalente a utilizar una tubería entre las dos órdenes, lo que produciría el mismo resultado:
anita:~# getfacl /usr/local/sbin/sshd | setfacl -f - /usr/local/sbin/demonioAntes de finalizar este apartado dedicado a las listas de control de acceso, quizás sea conveniente comentar el principal problema de estos mecanismos. Está claro que las ACLs son de gran ayuda para el administrador de sistemas Unix, tanto para incrementar la seguridad como para facilitar ciertas tareas; sin embargo, es fácil darse cuenta de que se pueden convertir en algo también de gran ayuda, pero para un atacante que desee situar puertas traseras en las máquinas. Imaginemos simplemente que un usuario autorizado de nuestro sistema aprovecha el último bug de sendmail (realmente nunca hay un `último') para conseguir privilegios de administrador en una máquina; cuando se ha convertido en root modifica la lista de control de acceso asociada a /etc/shadow y crea una nueva entrada que le da un permiso total a su login sobre este archivo. Una vez hecho esto, borra todo el rastro y corre a avisarnos del nuevo problema de sendmail, problema que rápidamente solucionamos, le damos las gracias y nos olvidamos del asunto. >Nos olvidamos del asunto? Tenemos un usuario que, aunque los bits rwx no lo indiquen, puede modificar a su gusto un archivo crucial para nuestra seguridad. Contra esto, poco podemos hacer; simplemente comprobar frecuentemente los listados de todos los ficheros importantes (ahora entendemos por qué aparece el símbolo `+' junto a las ternas de permisos), y si encontramos que un fichero tiene una lista de control que otorga permisos no reflejados en los bits rwx, analizar dicha lista mediante getfacl y verificar que todo es correcto. Es muy recomendable programar un par de shellscripts simples, que automaticen estos procesos y nos informen en caso de que algo sospechoso se detecte.