Usuarios y accesos al sistema

En un sistema Linux es posible controlar ciertos parámetros referentes al acceso de los usuarios a través de telnet o r- $\ast$ mediante el fichero /etc/login.defs; sus directivas no afectan directamente - aunque algunas de ellas sí de una forma indirecta - a las conexiones a través de otros mecanismos como SSH, que poseen sus propios ficheros de configuración. Como siempre, insistimos en la necesidad de sustituir todos los protocolos en claro por equivalentes cifrados, con lo que ni telnet ni r- $\ast$ deberían existir como servicio en una máquina Unix, pero de cualquier forma vamos a comentar algunas directivas del fichero anterior que pueden resultar interesantes para nuestra seguridad, tanto si afectan a las conexiones remotas como si no; para obtener información acerca del resto de directivas - y también de las comentadas aquí - podemos consultar la página del manual de login.defs(5).

La primera de las directivas que encontramos en /etc/login.defs es FAIL/SMALL>_DELAY, que marca el número de segundos (por defecto, 3) que el sistema introduce como retardo desde que se introduce un nombre de usuario o contraseña incorrectos hasta que se vuelve a solicitar el login de entrada al sistema; el número máximo de intentos antes de que se cierre la conexión viene determinado por el valor de LOGIN/SMALL>_RETRIES, por defecto a 5, y el tiempo máximo durante el que se permite la entrada antes de cerrar la conexión se especifica mediante la directiva LOGIN/SMALL>_TIMEOUT (60 segundos por defecto).

Cuando un usuario se equivoca en su nombre de entrada o su clave entran en juego un par de directivas más: FAILLOG/SMALL>_ENAB y LOG/SMALL>_UNKFAIL/SMALL>_ENAB. La primera de ellas, con un valor por defecto a `yes' (el adecuado para nuestra seguridad), se encarga de registrar los intentos fallidos de acceso al sistema en /var/log/faillog, así como de mostrar un mensaje con información acerca del último intento de acceso fallido cuando un usuario accede a la máquina. Por su parte, LOG/SMALL>_UNKFAIL/SMALL>_ENAB habilita o deshabilita el registro del nombre de usuario que ha fallado al tratar de entrar al sistema; es importante que su valor sea `no' (es decir, que ese nombre de usuario no se registre) por una sencilla razón: en muchas ocasiones los usuarios teclean su password en lugar de su login cuando tratan de acceder a la máquina, con lo que si el nombre de usuario incorrecto - la clave - se registra en un fichero en texto plano, y ese fichero tiene unos permisos inadecuados, cualquiera con acceso de lectura sobre el archivo de log podría deducir fácilmente el nombre y la clave del usuario. Adicionalmente, si la directiva FTMP/SMALL>_FILE define un archivo (por defecto, /var/log/btmp), en el mismo se registra cada intento de acceso fallido en formato utmp(5); dicha información se puede consultar mediante la orden lastb.

Si se produce la situación contraria a la que acabamos de comentar (es decir, el usuario teclea correctamente tanto su nombre como su contraseña), la directiva LOG/SMALL>_OK/SMALL>_LOGINS habilita o deshabilita el registro de este hecho en función de si su valor es `yes' o `no'; además, si LASTLOG/SMALL>_ENAB tiene un valor `yes' se registra la entrada en /var/log/lastlog y se muestra al usuario información acerca de su última conexión. En caso de que el usuario no pueda acceder a su directorio $HOME (bien porque no existe, bien por los permisos del mismo) entra en juego DEFAULT/SMALL>_HOME, y en caso de que su valor sea `no' no se permite el acceso; por el contrario, si su valor es `yes', el usuario entra al directorio raiz de la máquina.

En /etc/login.defs también se pueden definir líneas para las que no es necesaria ninguna contraseña, mediante la directiva NO/SMALL>_PASSWORD/SMALL>_CONSOLE: si alguien trata de conectar al sistema a través de ellas, se le solicitará su nombre de usuario pero no su clave; esto es aplicable para todos los usuarios de la máquina excepto para el administrador, al que siempre se le pide su password. Evidentemente, para incrementar la seguridad de nuestro sistema la directiva correspondiente ha de estar comentada.

El acceso a la cuenta del superusuario también viene determinado por ciertas directivas del archivo /etc/login.defs. En primer lugar, sólo se permiten accesos directos como root desde las líneas definidas en la entrada CONSOLE, que puede ser bien un archivo que contiene los nombres de dispositivos desde los que permitimos la entrada del administrador, o bien una relación de esos dispositivos separados por el carácter `:'; por defecto, en un sistema Linux esta entrada referencia al archivo /etc/securetty, que es un listado de terminales de la forma siguiente:

luisa:~# cat /etc/securetty
console
tty1
tty2
tty3
tty4
tty5
tty6
luisa:~#

Como hemos dicho, la función del anterior archivo es muy similar a la de la directiva `CONSOLE' en el fichero /etc/default/login de Solaris; si no existe, el administrador puede conectar en remoto desde cualquier lugar, mientras que si existe pero está vacío sólo se pueden alcanzar privilegios de root a través de la ejecución de `su'. En cualquier caso, el fichero no evita ni controla las conexiones remotas como superusuario a través de mecanismos como SSH o X Window, que poseen sus propios ficheros de configuración.

El contenido o la existencia de /etc/securetty tampoco evita de ninguna forma la ejecución de `su'; para ello existen otras directivas que controlan el acceso y el comportamiento de esta orden en el sistema. La primera de ellas es SU/SMALL>_WHEEL/SMALL>_ONLY, que si posee un valor `yes' indica que sólo los usuarios miembros del grupo `root'^11.1 van a ser capaces de cambiar su identidad mediante `su' a un usuario con privilegios de administrador (UID 0); si este grupo no existe o está vacio, nadie podrá ejecutar `su' para convertirse en superusuario.

En el archivo /etc/suauth (completamente independiente de /etc/login.defs) se puede realizar un control más minucioso de la ejecución de `su', no sólo para acceder a cuentas con privilegios de administración, sino también para permitir o denegar cambios de identidad entre dos usuarios cualesquiera del sistema. Se trata de un fichero en el que cada línea es de la forma

                             to-id:from-id:ACCION

donde ACCION puede ser DENY (se deniega el cambio de identidad), NOPASS (se permite el cambio sin necesidad de ninguna clave) u OWNPASS (se solicita el password del usuario que ejecuta la orden en lugar del correspondiente al usuario al que se quiere acceder); se puede consultar la página del manual suauth(5) para conocer la sintaxis exacta del archivo. Por ejemplo, si queremos que el usuario `toni' no pueda ejecutar `su' para cambiar su identidad a `root', pero que para convertirse en `prova' sólo tenga que teclear su propia contraseña, tendremos un fichero similar al siguiente:

luisa:~# cat /etc/suauth 
root:toni:DENY
prova:toni:OWNPASS
luisa:~#

Cuando toni trate de hacer `su' a las cuentas anteriores, verá algo similar a:

luisa:~$ id
uid=1000(toni) gid=100(users) groups=100(users)
luisa:~$ su 
Access to su to that account DENIED.
You are not authorized to su root
luisa:~$ luisa:~$ su prova
Please enter your OWN password as authentication.
(Enter your own password.)
Password: 
luisa:/home/toni$ id
uid=1006(prova) gid=100(users) groups=100(users)
luisa:/home/toni$

Es importante destacar que el contenido del fichero /etc/suauth sólo afecta a usuarios regulares, no al root: no podemos definir reglas que eviten que el administrador de un sistema cambie su identidad a cualquier usuario del mismo. Esto es algo evidente, ya que si no se permitiera al root cambiar su identidad, este no tendría más que modificar el fichero para eliminar la regla que se lo impide.

Volviendo a /etc/login.defs, el registro de las ejecuciones de `su' también se controla desde este fichero; la directiva SULOG/SMALL>_FILE define el archivo donde se registran las ejecuciones de esta orden, tanto si son exitosas como si no. Además, si el valor de SYSLOG/SMALL>_SU/SMALL>_ENAB es `yes' se guarda un registro adicional a través de syslogd en el archivo correspondiente; existe una directiva análoga a esta última denominada SYSLOG/SMALL>_SG/SMALL>_ENAB, que registra también a través de syslogd los cambios de grupo que se producen en el sistema (por ejemplo, mediante la ejecución de la orden newgrp).

Antes de dejar de lado los aspectos relacionados con `su' vamos a comentar una directiva muy interesante: se trata de SU/SMALL>_NAME, que define el nombre de programa que un `ps' muestra cuando alguien ejecuta la orden `su -' (un cambio de identidad emulando un proceso de login directo) en el sistema. Su valor por defecto es `su', lo que indica que si alguien cambia su identidad de la forma que acabamos de ver, un listado de procesos mostrará algo similar a lo siguiente:

luisa:~$ su - prova
Password: 

Famous, adj.:
        Conspicuously miserable.
                -- Ambrose Bierce

luisa:~$ ps xuw
prova    19990  0.8  0.3  1708  984 pts/8    S    07:04   0:00 -su
prova    20001  0.0  0.2  2548  908 pts/8    R    07:04   0:00 ps xuw
luisa:~$

Como vemos, en lugar del shell que el usuario esté utilizando, aparece el nombre de programa `-su' en la última columna del listado; si la directiva no estuviera definida sí que aparecería el nombre del shell correspondiente. Puede resultar interesante redefinir la directiva SU/SMALL>_NAME para asignarle un valor que pueda resaltar más en el listado, de forma que el administrador pueda ver quien ha ejecutado la orden `su -' de una forma más directa:

luisa:~# grep ^SU_NAME /etc/login.defs 
SU_NAME         ***SU***
luisa:~# su - prova

f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

luisa:~$ ps xuw
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
prova    20083  7.0  0.3  1712  988 pts/8    S    07:11   0:00 -***SU***
prova    20094  0.0  0.2  2548  912 pts/8    R    07:11   0:00 ps xuw
luisa:~$

A la hora de definir nuevos usuarios en el sistema también entran en juego ciertas directivas del archivo /etc/login.defs. Por ejemplo, el UID y GID máximo y mínimo para los usuarios regulares viene determinado por UID/SMALL>_MAX, GID/SMALL>_MAX, UID/SMALL>_MIN y GID/SMALL>_MIN. También existen entradas para especificar ciertas características relacionadas con las claves de los nuevos usuarios del sistema: se trata de PASS/SMALL>_MAX/SMALL>_DAYS, PASS/SMALL>_MIN/SMALL>_DAYS, PASS/SMALL>_MIN/SMALL>_LEN y PASS/SMALL>_WARN/SMALL>_AGE. Como sus nombres indican, estas directivas marcan los números máximo y mínimo de días que una contraseña puede ser usada, la longitud mínima que todo password ha de tener, y el número de días de antelación con que se avisará a los usuarios antes de que sus claves caduquen, respectivamente. Cada vez que se crea a un usuario nuevo en el sistema, se toman estos valores por defecto, aunque después es habitual particularizar para cada caso concreto.

Cuando un usuario ejecuta la orden passwd para cambiar su contraseña en el sistema entra en juego la directiva OBSCURE/SMALL>_CHECKS/SMALL>_ENAB (cuyo valor ha de ser `yes') para impedir que se elijan claves débiles (por ejemplo, las formadas únicamente por letras minúsculas); adicionalmente, si la orden está enlazada a cracklib (esto se realiza en tiempo de compilación) y la directiva CRACKLIB/SMALL>_DICTPATH está definida y tiene como valor la ruta de un directorio, se buscan en el mismo ficheros de diccionario contra los que comparar la nueva contraseña, rechazándola si se encuentra en alguno de ellos. En cualquier caso, se permiten tantos intentos de cambio como indica PASS/SMALL>_CHANGE/SMALL>_TRIES, y si se supera este número se devuelve al usuario a su shell y la clave permanece inalterada; si el usuario que trata de cambiar el password es el root - tanto la propia clave como la de cualquier usuario - se le permite elegir cualquier contraseña, sin importar su robustez, pero se le advierte de que la clave elegida es débil si el valor de directiva PASS/SMALL>_ALWAYS/SMALL>_WARN es `yes'.

Al ejecutar passwd para modificar valores del campo GECOS o para cambiar el shell de entrada al sistema (o equivalentemente, al ejecutar chfn o chsh) se solicita al usuario su clave si el valor de la directiva chfn_auth es `yes'. Además, la entrada CHFN/SMALL>_RESTRICT define los campos concretos que un usuario puede modificar: Full Name, Room Number, Work Phone y Home Phone (`frwh' si permitimos que modifique todos ellos); si la directiva no está definida, no se permite ningún tipo de cambio.

Relacionada también con las contraseñas de los usuarios, la directiva PASS/SMALL>_MAX/SMALL>_LEN marca el número de caracteres significativos en una clave (8 por defecto); no obstante, esta entrada es ignorada si el valor de MD5/SMALL>_CRYPT/SMALL>_ENAB es `yes', lo que indica que el sistema acepta passwords basados en MD5, que proporcionan una longitud para las claves ilimitada y salts más largos que el esquema clásico de Unix. La única razón para asignarle a esta última directiva un valor `no' en los Linux modernos es por razones de compatibilidad, ya que la seguridad que proporciona este tipo de claves es mucho mayor que la proporcionada por los mecanismos habituales de Unix.

Dejando ya de lado el archivo /etc/login.defs, pero siguiendo con la gestión de las contraseñas de usuario, para consultar el estado de las mismas en un sistema Linux hemos de ejecutar la orden `passwd -S' seguida del nombre del usuario correspondiente; por desgracia, en Linux no existe un parámetro `-a' similar al de Solaris, que muestre información de todos los usuarios, por lo que hemos de hacer la consulta uno a uno:

luisa:~# for i in `awk -F: '{print $1}' /etc/passwd`
> do
> passwd -S $i
> done
root P 12/28/2000 0 -1 -1 -1
bin L 10/28/1996 0 -1 -1 -1
daemon L 10/28/1996 0 -1 -1 -1
adm L 10/28/1996 0 -1 -1 -1
lp L 10/28/1996 0 -1 -1 -1
sync L 10/28/1996 0 -1 -1 -1
shutdown L 10/28/1996 0 -1 -1 -1
halt L 10/28/1996 0 -1 -1 -1
mail L 10/28/1996 0 -1 -1 -1
news L 10/28/1996 0 -1 -1 -1
uucp L 10/28/1996 0 -1 -1 -1
operator L 10/28/1996 0 -1 -1 -1
games L 10/28/1996 0 -1 -1 -1
ftp L 10/28/1996 0 -1 -1 -1
gdm L 10/28/1996 0 -1 -1 -1
nobody L 10/28/1996 0 -1 -1 -1
toni P 12/29/2000 0 99999 7 -1
prova NP 10/23/2001 0 99999 7 -1
luisa:~#

El segundo campo de cada línea del listado anterior proporciona el estado de la clave correspondiente: `P' si el usuario tiene contraseña, `L' si la cuenta está bloqueada, y `NP' si el usuario no tiene clave asignada; en este último caso es muy importante poner un password al usuario o bien bloquear su acceso:

luisa:~# passwd -S prova
prova NP 10/23/2001 0 99999 7 -1
luisa:~# passwd -l prova
Password changed.
luisa:~# passwd -S prova
prova L 10/23/2001 0 99999 7 -1
luisa:~#

El resto de campos del listado hacen referencia propiedades de envejecimiento de las claves: cuando se cambió la contraseña de cada usuario por última vez, cuales son sus periodos de validez máximo y mínimo, el periodo de aviso y el periodo de inactividad antes de bloquear el acceso de forma automática; también mediante passwd (o equivalentemente mediante chage) podemos - como root - modificar esta información para cada uno de nuestros usuarios. Por ejemplo, si queremos que la clave del usuario `prova' tenga un periodo de validez máximo de un mes y mínimo de 10 días, que se avise al usuario de que su clave va a caducar con una antelación de una semana, y que si una vez la clave ha caducado el usuario no entra al sistema en cinco días se bloquee su cuenta podemos conseguirlo con la siguiente orden:

luisa:~# passwd -S prova
prova L 10/23/2001 0 99999 7 -1
luisa:~# passwd -x 30 -n 10 -w 7 -i 5 prova
Password changed.
luisa:~# passwd -S prova
prova L 10/23/2001 10 30 7 5
luisa:~#

Como en este caso la cuenta está bloqueada, los cambios tendrán efecto cuando esta se desbloquee (o directamente se le asigne una nueva clave) y comience a ser utilizada; a diferencia de otros sistemas Unix, el desbloqueo de un acceso en Linux guarda una especie de estado: conserva la contraseña que el usuario tenía antes de que su cuenta fuera bloqueada.