El Superusuario

1.1 Conceptos básicos para administradores

El administrador de una máquina Unix se conoce habitualmente como root (este es su nombre de entrada al sistema o login), y la principal característica distintiva respecto al resto de usuarios de una máquina es su UID, igual a 0 (el GID también es 0 en ciertos Unices). Este hecho le va a permitir evitar todos los controles del sistema operativo en cuanto a permisos de ficheros, acceso al hardware, protección de memoria, etc. Por tanto, el root o superusuario es (o ha de ser) la única entidad del sistema con acceso total a los recursos del entorno. Aunque en principio cualquier usuario con UID 0 en el archivo de contraseñas tendra privilegios de administrador, en la mayoría de los casos es conveniente por seguridad y estabilidad de la máquina que este tipo de usuario sea único y con login ‘root’.

El root ha de suministrar al resto de usuarios un entorno fiable, seguro y estable en el cual puedan desarrollar sus trabajos de forma efectiva. Aunque a muchas máquinas Unix se les asigna un administrador elegido entre todos los usuarios, esto no suele ser una buena opción a la larga: el superusuario ha de ser una persona técnicamente preparada para desarrollar todas las actividades propias de esta tarea (que veremos más adelante), y por supuesto ha de tener unos conocimientos del sistema muy superiores al del resto de usuarios. Aparte de poseer conocimientos técnicos, ha
de tener una gran responsabilidad, ya que su papel suele ser también normativo: tiene que definir unas reglas de convivencia y aprovechamiento del sistema para regular su uso.

Suele ser una regla habitual y recomendable entre administradores el crear para sí mismos un usuario común, sin ningún privilegio especial, para trabajar de forma normal en el sistema. Así, las entradas a la máquina como superusuario se minimizan, y solo se realizan para efectuar tareas privilegiadas, como copias de seguridad, actualización de software o creación de nuevos usuarios.

Es importante recordar que solo debemos utilizar un acceso privilegiado para las tareas que lo requieran, no para el resto: no hay más que pensar en que, si tenemos un peque~no error como usuario ‘root’, podemos destruir por completo el sistema.

1.2 El entorno del superusuario

El shell o interprete de ordenes del sistema Unix proporciona para el administrador un valor especial de la variable de entorno $PS1, ‘#’, en lugar de los habituales ‘$’, ‘%’ o ‘>’, proporcionados al resto de usuarios. Esto no da ningún privilegio especial al administrador (recordemos que todos sus privilegios provienen del UID 0), y cualquier usuario puede modificar el valor de su $PS1 para igualarlo a ‘#’; sin embargo es útil para recordar a la persona encargada del sistema que esta trabajando sin ningun tipo de restriccion, por lo que un error en sus acciones puede ser fatal para
la máquina.

Otras variables de entorno que suelen diferir del resto de usuarios son el directorio $HOME, que para el root es / o /root/ generalmente, y también el $PATH, que incluirá ciertos directorios como /sbin/ o /usr/sbin/, donde se encuentran mandatos para la administración del sistema que no son necesarios para un usuario sin privilegios.

En la práctica totalidad de sistemas Unix, las conexiones a la máquina como root mediante telnet u otro tipo de acceso remoto están limitadas a una serie de terminales denominadas ‘seguras’, terminales que generalmente son la propia consola del equipo y sus terminales virtuales (es decir, restringimos las conexiones root al monitor físico del ordenador); con esto se evita que el root pueda conectar desde cualquier lugar de la red, y su password sea capturado por un potencial intruso.

La forma de definir que terminales son las autorizadas para el administrador varia entre diferentes Unices; por ejemplo, en SunOS se definen en el archivo /etc/ttytab, en Solaris e IRIX en /etc/default/login, en OSF/1 en /etc/securettys, etc. En el caso de HP-UX y Linux, la lista de terminales seguras se encuentra en el fichero /etc/securetty; como hemos dicho, es conveniente que solo se permite una conexión root desde el monitor físico del ordenador, para evitar así el movimiento de una contraseña de superusuario por la red. Sin embargo, también se permite la administración remota: en casos de urgencia, es posible para el root entrar al sistema como un usuario normal, y obtener privilegios de superusuario mediante la orden su:
rosita:~$ id
uid=1000(toni) gid=100(users) groups=100(users)
rosita:~$ su
Password:
rosita:/home/toni# id
uid=0(root) gid=0(root) groups=0(root)
rosita:/home/toni# exit
exit
rosita:~$ id
uid=1000(toni) gid=100(users) groups=100(users)
rosita:~$

Acabamos de comentar que las conexiones como root se van a producir sobre todo desde la consola del sistema. Por defecto, algunos Unices como Linux, FreeBSD o SCO1 nos van a ofrecer en modo texto varias terminales (por norma general 6, de tty1 a tty6); podremos conmutar entre ellas pulsando Alt-F[1..6]. Si pulsamos Alt-F7 llegamos a la salida de los sistemas de ventanas (para conmutar entre estos y el modo texto). Este conjunto de terminales virtuales en la consola del sistema es muy útil para máquinas sin entorno gráfico, en los que si solo tuviéramos una terminal y esta se inutilizara por cualquier motivo, no podríamos trabajar en modo local. Aunque con seis terminales suele ser más que suficiente para la correcta administración del sistema, si en algún momento necesitamos más podemos conseguirlas mediante ordenes como agetty, mingetty o ttymon (dependiendo del Unix en que trabajamos), con las opciones adecuadas.

1.3 El papel del administrador

Las tareas de un administrador dependen habitualmente del tipo de sistema del cual se ocupe, y por tanto vienen marcadas por la organización de la maquina y de su entorno (empresa, usuarios, etc. . . ). Aunque varían entre sistemas, ya que obviamente no es lo mismo administrar una máquina con mil usuarios que una con cincuenta, o proteger un sistema dedicado a las prácticas de alumnos que otro dedicado a trabajos militares, existen ciertas tareas comunes a todos los administradores, ya lo sean de un PC o de una CONVEX. Las más frecuentes son:
– Apagar y encender el sistema. Se ha de realizar de una forma ordenada para evitar inconsistencias en el kernel o en el sistema de ficheros.
– Gestión de los usuarios. A~nadir usuarios, eliminarlos, modificar sus privilegios, controlar sus actividades… e incluso aconsejarles en el manejo del sistema para que puedan trabajar de forma cómoda y eficiente.
– Gestión de software. El administrador es el encargado de actualizar o retirar programas del sistema, y por supuesto también de controlar su correcto funcionamiento (por ejemplo mediante patches).
– Gestión de perifericos. Puesta a punto de terminales, impresoras, modems. . .
– Gestión de sistemas de ficheros. Montar o desmontar unidades de disco (discos duros, disquetes, unidades de CDROM. . . ), unidades de cinta, sistemas de ficheros remotos. . . y controlar su uso por parte de los usuarios. También es responsable de la creacion y actualizacion de las copias de seguridad del sistema.
– Gestión del sistema de red. Como administradores, hemos de configurar los diferentes dispositivos de red de nuestra máquina, así como el rutado correcto de los paquetes, los servicios ofrecidos, los servidores de nombres. . .
– Seguridad de la máquina. Sobre el root recae la mayor responsabilidad en cuanto a integridad, fiabilidad y privacidad de la máquina y la información contenida en ella. Aparte de posibles ataques externos, también se ha de controlar que los usuarios no realicen actividades a las que no están autorizados, creando unas normas que todos han de cumplir en el sistema.

Todas estas tareas van encaminadas a conseguir el perfecto funcionamiento del sistema durante el máximo tiempo posible, y también a poder aprovechar todos los recursos y servicios que un sistema Unix correctamente administrado puede ofrecer.

1.4 Comunicación con los usuarios.

No siempre es posible para un administrador poder hablar en persona con todos y cada uno de sus usuarios, ya sea por falta de tiempo o por la imposibilidad física de hablar con una persona que potencialmente puede estar trabajando en nuestro sistema desde cualquier punto del mundo. Por tanto, el sistema operativo Unix nos ofrece, como administradores, una serie de herramientas que nos van a permitir comunicarnos con las personas que trabajan en la máquina.

Aparte de los ya conocidos write o talk (que obviamente podemos utilizar como administradores, aunque no es lo común, ya que frecuentemente nos interesa contactar con un grupo mas o menos amplio de usuarios, y no con uno solo), disponemos de otros mecanismos de comunicación, algunos de ellos permitidos únicamente al root de la máquina, y que van a hacer llegar nuestro mensaje a un grupo determinado de usuarios.

La primera forma de comunicación con los usuarios que vamos a estudiar es el archivo /etc/motd (Message Of The Day). Es un archivo común de texto, que podemos editar y modificar a nuestra voluntad, y en el que se suele indicar un mensaje dirigido a todos los usuarios del sistema. Cuando un usuario conecte a la máquina, y una vez se haya identificado con su login y password, le aparecerá en pantalla un volcado de este fichero.

Los mensajes más comunes que suelen aparecer en /etc/motd son del tipo \El día 15, de 12:00 a 16:00, la maquina permanecerá cerrada por actualización de software. Disculpen las molestias.”

\Se recuerda a los usuarios del grupo usr1 que no pueden sobrepasar los 3 MB. de disco utilizado por cada cuenta. Se borraran los directorios que sobrepasen los 3’5 MB.” Podemos ver, que los mensajes contenidos en /etc/motd son aquellos que potencialmente interesan a todos los usuarios, o al menos a los que conecten al sistema.

Teniendo definido un fichero /etc/motd en el sistema, cuando un usuario conecte, verá algo parecido a lo siguiente:
rosita login: toni
Password:
Last login: Fri Oct 3 18:36:37 from localhost
El dia 15, de 12:00 a 16:00, la máquina permanecerá cerrada por actualización de software. Disculpen las molestias.
rosita:~$

No debemos confundir el fichero /etc/motd con archivos como /etc/issue o /etc/issue.net; estos archivos se muestran antes de conectar al sistema, es decir, antes de que la máquina nos pregunte un nombre de usuario y una contraseña, por lo que no es recomendable poner en ellos mensajes para los usuarios. El contenido de estos ficheros es también un texto plano (podemos editar los archivos igual que /etc/motd) que se mostrará cuando alguien haga un telnet a nuestro sistema:
rosita:~# cat /etc/issue.net
Bienvenidos a ROSITA
rosita:~# telnet rosita
Trying 192.168.0.1…
Connected to rosita.
Escape character is ‘^]’.
Bienvenidos a ROSITA
rosita login:

El segundo mecanismo que tiene el administrador para comunicarse con sus usuarios es la orden wall (Write ALL), que trabaja en tiempo real. Utilizando un mecanismo similar al de write, interrumpe la pantalla de todos los usuarios conectados y les envía un mensaje especificado en un fichero que wall recibe como argumento. Si este fichero no se especifica, wall recibe datos del teclado y los envía al pulsar Ctrl-D. Un ejemplo sería:
rosita:~# cat aviso.1
Vamos a apagar la máquina dentro de media hora.
rosita:~# wall aviso.1
Broadcast Message from root@rosita
(/dev/tty1) at 04:35 …
Vamos a apagar la máquina dentro de media hora.
rosita:~#
Equivalente a:
rosita:~# wall
Vamos a apagar la máquina dentro de media hora.
<ctrl-d>
Broadcast Message from root@rosita
(/dev/tty1) at 04:35 …
Vamos a apagar la máquina dentro de media hora.
rosita:~#

Como vemos, el mecanismo de wall interrumpe la pantalla de todos los usuarios conectados, incluido el propio root. Por tanto, los mensajes enviados con este mecanismo son aquellos que pueden interesar a los usuarios conectados en ese momento al sistema, pero no al resto: por ejemplo, a un usuario que no esté conectado, seguramente le importará poco que reiniciemos el sistema en un momento dado, y en caso de que le importe (puede tener procesos activos en la máquina) poco podrá hacer.

De los métodos que el sistema ofrece al administrador para comunicarse con sus usuarios, el tercero que queremos comentar es el envío de correo a varios usuarios al mismo tiempo. Obviamente esto lo utilizaremos para difundir un mensaje interesante para ciertos usuarios (por ejemplo, los pertenecientes a un grupo), que no necesariamente han de estar conectados al sistema en el momento en que enviamos el correo.

Para enviar correo a varios usuarios, en cualquier gestor (como elm, mailx, mail o pine) debemos separar los nombres de los usuarios con comas (o espacios, si invocamos desde el prompt), en el campo reservado al destinatario de un mensaje. Utilizando mail, por ejemplo, lo haríamos de la siguiente manera:
rosita:~# mail toni sergio monica
Subject: Cita para renovacion
El próximo lunes pasad por el despacho de 1400 a 1600 para renovar vuestros datos en la máquina.
Saludos
.
EOT
rosita:~#

Asi, hariamos llegar el mismo mensaje a los usuarios toni, mónica y sergio de nuestro sistema, sin necesidad de escribir un correo para cada uno de ellos.

 

Fuente:

ADMINISTRACION DE SISTEMAS UNIX
Antonio Villalon Huerta <toni@aiind.upv.es>
Sergio Bayarri Gausi <sergio@aiind.upv.es>