Inicio/parada del sistema. Montar y desmontar.

Inicio del sistema

Para ser un administrador del sistema hay que saber algo sobre el inicio de los sistemas que ejecutan UNIX. Cuando un ordenador que ejecuta UNIX se enciende, ejecuta un código de arranque almacenado en ROM (en SPARC se llamaba eeprom) que se encarga de que comience la siguiente secuencia.

- carga e inicialización del kernel
- detección y configuración de dispositivos
- creación de threads del kernel
- intervención del operador en modo monousuario
- ejecución de scripts de arranque
- operación multiusuario

Lo primero que ocurre, por tanto, en cualquier sistema UNIX, es que el kernel se carga, realiza un reconocimiento de dispositivos, y ejecuta el proceso init, que es el número 1 (o madre de todos los procesos, aunque en algunos sistemas es visible un proceso 0 que es el sched).

El proceso init a continuación lleva al sistema al nivel que se le indique.

Los niveles por defecto en UNIX (se definen en /etc/inittab) son:

0 parado, 1/s single user, 2 multiuser no network, 3 multiuser con red, 5 multiuser con red y X-Windows, 6 reiniciar.

El modo 1/s o "modo monousuario" es como el "modo a prueba de fallos" de Windows. nos abre una shell en la que no tenemos servicios de red ni los filesystems montados (sólo el root filesystem) para que podamos hacer cosas como reparar el sistema operativo restaurando un backup, o arreglar algún problema de red. El init arranca un número mínimo de procesos adicionales (en Linux por ejemplo son unos kernel daemons cuyo nombre empieza por k y termina por d). El login sólo lo podremos hacer en un puertos serie (e.g. en la consola del sistema) gracias a alguna variante del proceso getty.

Lo que define cada uno de estos niveles, son los llamados scripts de inicio del sistema, que se van ejecutando uno tras otro, hasta llegar al punto en el que los usuarios pueden conectarse.

Scripts de inicio

Los scripts de inicio en cada sistema operativo UNIX tienen una pinta diferente.

El procedimiento tradicional en Solaris era tener un script en /etc/init.d y enlaces a los niveles en que se ejecuta. Ahora en Solaris 10 se supone que han creado lo que se conoce como SMF (proceso svc.statd que tiene su configuración propia)

La forma tradicional de poner en funcionamiento en Solaris un proceso al inicio y a la parada era la siguiente. Sea un ejecutable nuestro interesantísimo que queremos que se esté ejecutando siempre, al que le podemos pasar los argumentos start y stop. Queremos que se inicie a la vez que la máquina y que se pare cuando se detiene el sistema. Para eso creamos el script /etc/init.d/programita

#!/bin/ksh # # @(#)FileDescription: Startup Script of Programita # @(#)FileName: /etc/init.d/programita # @(#)Language: Korn Shell # @(#)Version: 1.0 if [ ! -d /usr/bin ] then # /usr not mounted exit fi # # Startup Script # case "$1" in 'start') echo "--- Starting ---" su – luciag -c "cd /opt/programita/bin;./programita.ksh start" ;; 'stop') echo "--- Stopping ---" su – luciag -c "cd /opt/programita/bin;./programita.ksh stop" ;; *) echo "Usage: $0 { start | stop }" ;; esac

Para que se ejecute programita start cuando arrancamos la máquina y se ejecute programita stop cuando la apagamos tenemos que hacer links duros desde el nivel por defecto.

Si en la máquina Solaris el nivel por defecto es 3, tendrias que ln /etc/init.d/programita /etc/rc3.d/S85programita para que arrancase, y si tuvieras parada, entonces ln /etc/init.d/arpas /etc/rc0.d/K85programita.

El 85 es un numero que tiene que ser:

a) para el arranque, mayor que el que tenga el script que se use para hacer esto con cualquier comando relacionado (por ejemplo si arrancamos la base de datos con un script en el número 84)

b) para la parada menor que el que tenga el script que se use para hacer esto con cualquier comando relacionado.

Parada del sistema

Hay muchas formas de parar el sistema.

• La peor y más desaconsejada es pegarle un botonazo o desenchufar la máquina. Los búferes de los sistemas de ficheros cambian en memoria y escriben a disco esporádicamente. Este esquema hace que la escritura a disco sea más rápida pero también que el sistema se pueda quedar inconsistente si lo apagamos de repente.
• La más habitual es utilizar un comando. El comando shutdown envía mensajes a los usuarios para que se vayan desconectando. Puede usarse para especificar una hora a la que se hará la parada o el reinicio.

Parar el sistema

# shutdown -h now

Parar el sistema a las 21:30

# shutdown -h 21:30 "Este sistema se va a apagar por cambio de moqueta en sala de servidores"

Parar el sistema en 15 minutos:

# shutdown -h +15 "Este sistema se va a apagar porque le vamos a cambiar un disco"

• Hay otras formas de parar, el comando halt, que sin avisar a nadie, lo mata todo, ejecuta el comando sync y adios muy buenas. Recuerdo un técnico de sistemas en la época en que halt no hacía sync que paraba las máquinas con el mantra "sync; sync; halt" en plan militar.
• Para reiniciar tenemos reboot, que es lo mismo que shutdown -r now. Este comando fuerza a hacer un chequeo de filesystems (también conocido como fsck) en el siguiente reinicio.
• Hay una manera de indicar que no se haga el filesystem check, y es shutdown -rf now. Que reinicie pero no haga chequeos.

Montar y desmontar

Hemos mencionado el tema de montar y desmontar los sistemas de ficheros de los discos de los sistemas UNIX, vamos a explicarlo con más detenimiento.

Para que un filesystem o partición esté disponible, debe de ser montado utilizando el comando mount. La acción de montar un sistema de ficheros simplemente "conecta" esa partición al árbol de directorios disponible.

Los sistemas de ficheros disponibles cuando el sistema arranca están indicados en la tabla /etc/fstab o /etc/vfstab en Solaris. En AIX que son muy particulares /etc/filesystems.

Cuando hacemos df podemos ver el disco disponible en el sistema, y este uso nos viene desglosado por filesystems. Normalmente hacemos df -k para ver el resultado en KBs.

sun (ksh) % df -k

Filesystem            kbytes    used   avail capacity  Mounted on /dev/dsk/c0t3d0s0      47975   17711   25467    42%    / /dev/dsk/c0t3d0s3     721230  590285   73247    89%    /usr /dev/dsk/c0t3d0s4      96455   29279   57531    34%    /var swap                  128408     312  128096     1%    /tmp /dev/dsk/c0t1d0s5    2100583 1200588  836978    59%    /export/home /dev/dsk/c0t1d0s6     668423  334350  273915    55%    /opt

La primera columna muestra el dispositivo de bloque asociado al filesystem, la última el "punto de montaje". Un punto de montaje empieza siendo un directorio normal creado con mkdir, y cuando se ha ejecutado el mount muestra los contenidos de la partición. 

Por ejemplo, si queremos montar el /opt de este ejemplo: 

mount /dev/dsk/c0t1d0s6 /opt

Y si queremos desmontarlo

umount /opt

En Solaris hay un curioso directorio llamado lost+found en cada mount point, no borrarlo que es para los inodos dereferenciados.

Si no sabes en qué filesystem está el espacio que necesitas para determinar si tienes sitio, siempre está el df -k . (directorio actual). Otro comando para sacar cuánto disco estamos usando es du -ks . (para saber el tamaño del directorio actual). 

No sólo se montan y desmontan los filesystem, también los directorios de red (usando lo que se conoce como NFS) y los CDs (aunque en los sistemas modernos no es necesario porque hay un servicio que los detecta y monta solos en un mount point cuyo nombre suele ser /cdrom). 

Para distinguir filesystem locales de NFS se suele utilizar df -kl (la opción l es solo locales). 

Bibliografía
http://my.safaribooksonline.com/9780132117371/app02#X2ludGVybmFsX0ZsYXNoUmVhZGVyP3htbGlkPTk3ODAxMzIxMTczNzEvODc=

http://www.argray.org/unixfaq/filesystem.shtml#inode_table

Usuarios y seguridad: El administrador del sistema

Usuarios y grupos en UNIX

Un usuario UNIX dispone de una cuenta con un nombre de usuario (identificación) y una contraseña secreta asociada (autenticación).

En UNIX, los procesos y archivos tienen asociado un usuario como dueño. El dueño de un archivo es el usuario que lo crea. Un proceso es un programa en ejecución; el dueño del proceso es el usuario que lo arranca. Tanto para archivos como para procesos existe también un grupo al que ese proceso o archivo pertenece. Un grupo es un conjunto de usuarios; un usuario puede pertenecer a varios grupos. Un archivo o proceso pertenece al grupo primario o grupo principal del usuario que crea el archivo o arranca el proceso.

El usuario administrador: root

Entre todos los usuarios del sistema existe uno especial cuyo identificador o UID es 0, asociado a una cuenta con nombre "root". El nombre puede ser cualquiera, lo importante es el UID 0.

El usuario administrador, conocido como superusuario puede realizar cualquier operación posible sobre archivos y procesos; muchas llamadas al sistema sólo pueden ser realizadas por el superusuario o tienen opciones especiales para el superusuario no disponibles para los usuarios comunes, como por ejemplo:

- Cambiar la hora del sistema

- Apagar el sistema

- Cambiar el nombre de la máquina

- Cambiar los atributos a un fichero ajeno (con chmod)

- Cambiar la propiedad de un fichero (con chown)

- Cambiar la prioridad a un proceso ajeno

- Cambiar la propiedad de un proceso ajeno

¿Cuándo ocurre el cambio de dueño de un proceso? Por ejemplo, el programa "login" corre como superusuario, una vez que el usuario introduce su usuario y contraseña, cambia el UID y GID a los del usuario y arranca el intérprete de comandos del usuario.

root es todopoderoso y por tanto en su contraseña reside la seguridad del sistema. Una buena contraseña debe combinar caracteres de todos los tipos y no venir en el diccionario. La contraseña de root debe cambiarse con cierta periodicidad, cada vez que se vaya alguien que la conoce, o cuando existan sospechas de que un sistema se ha visto comprometido.

¿Qué ocurre si se nos olvida la contraseña de root? Pues estamos en un problema.

Afortunadamente no seríamos los primeros a los que nos pasa. Se tiene que acceder físicamente a la consola del sistema, iniciar desde CD o cinta, e iniciar el procedimiento de recuperación.

Hacerse root

Como la contraseña de root es un secreto importante, muchos administradores de sistemas jamás harán telnet o rlogin como root (puesto que las contraseñas transmitidas por estos medios no van encriptadas). Lo normal es hacer telnet o rlogin como otro usuario ordinario y después utilizar el comando su (switch user). No hace falta indicar "su root" o "su - root", simplemente "su -" o "su".

luciag@pluton:~> su -

Password:

Sun Microsystems Inc. SunOS 5.8 Generic Patch December 2002

#

Hacerse root sin saber la contraseña
Existe un software que se llama "sudo" que nos sirve para que, sin conocer la contraseña de superusuario, podamos definir ciertas operaciones privilegiadas que pueden ser realizadas por ciertos usuarios no administradores, con el fin de no tener que "repartir" la password de root a usuarios sin conocimientos para ellos (por ejemplo, si tenemos usuarios que quieren insertar un CD: para "montar" dispositivos se requiere superusuario).

Pseudo-usuarios

Existe una serie de usuarios que vienen definidos con el sistema. No hay que borrarlos ni tampoco cambiarles la contraseña porque no la sabe nadie y además no suelen tener una shell "real" (para que no puedan entrar).

Por ejemplo:

• bin: El propietario "histórico" de los comandos del sistema
• daemon: Usuario sin privilegios que ejecuta cierto software del sistema
• nobody: Usuario NFS

El fichero /etc/passwd

El fichero /etc/password es el fichero donde se encuentran las identidades de los usuarios. Este fichero contiene los siguientes campos.

ID usuario: Contraseña: UID: GID: Descripción (GCOS): Directorio Home: Shell de inicio

Los ID usuario deberían ser cortos (los más largos de 8 caracteres pueden causar incompatibilidades con sistemas más antiguos) y fáciles de recordar.

Un ejemplo

luciag:Urklk2.alLmrU:20073:200:Lucia Gonzalez, R&D Tech,x5145,91555555:/export/share/home/luciag:/usr/local/bin/tcsh

La contraseña está encriptada mediante el algoritmo crypt. Se toma la contraseña para encriptar un bloque de 64 bits de ceros. Se realizan 25 rondas y del resultado se toma de una cadena de 11 caracteres.

El usuario luciag tiene UID 20073 y GID 200, correspondiendo con un grupo definido en /etc/group como

imasd::200:intserv

Los UIDs tienen que ser únicos en la organización cuando se comparten recursos entre sistemas, hacerlo de otra forma contribuiría al caos. Los UIDs son enteros de 32 bits, aunque se recomienda no crear usuarios a partir del 32.767 si se tienen sistemas antiguos cerca (entero con signo de 16-bit)

El campo descripción, que en algunos libros llaman GECOS por motivos históricos, contiene información sobre el usuario. El comando finger normalmente interpreta los campos separados por comas como

- Nombre completo

- Centro de trabajo

- Extensión

- Teléfono de casa

En cuanto a la contraseña, muchos sistemas (como Solaris), no almacenan el valor encriptado, sino una x (nunca dejar la x en blanco porque se estaría dejando el usuario sin password). El valor encriptado se almacena en un fichero adjunto llamado /etc/shadow que los usuarios ordinarios no tienen permisos para ver y por tanto se dejan menos opciones para el crackeo por fuerza bruta.

Por ejemplo:

tbd:x:11102:110:Database Administrator:/opt/tbd:/bin/ksh

Tiene su correspondencia en /etc/shadow (la he alterado, no penséis que corresponde a una contraseña de mi sistema)

tbd:62yqgtwd35PJQ:13865::::::

En un sistema UNIX es preocupante que varios usuarios compartan la cuenta, que los usuarios dejen su contraseña escrita, que las contraseñas sean fáciles de adivinar... como en todos los sistemas operativos la seguridad empieza por las contraseñas.

Por cierto, en AIX que es muy original, el fichero de password está en /etc/security/passwd

Crear un usuario

Podemos hacerlo editando el fichero /etc/passwd. No debemos olvidar el comando pwconv en los sistemas con /etc/shadow.

Muchos sistemas tienen herramientas de ayuda para crear usuarios.

Ejercicio: Creación de un usuario en Fedora12.

Trabajar como superusuario

En la mayoría de las situaciones el superusuario trabaja con la shell. El entorno de un superusuario suele estar bastante pelado. Es tradicional que la shell de root sea Bourne Shell (bastante arcaica y con menos facilidades de trabajo que Korn Shell o Tenex C-Shell), por motivos de compatibilidad con sistemas antiguos. Esto suele ser incómodo para muchos y algunos tenemos la manía de crearnos un superusuario alternativo customizado (otros odian esta manía). Duplicamos la entrada del fichero de passwords y nos ponemos nuestras cositas

root:x:0:1:Super-User:/:/sbin/sh

roottcsh:x:0:1:Super-User Customized Account:/root:/usr/local/bin/tcsh

Anécdotas

El rol de superusuario a muchas personas les encanta. Eso de "convertirse en superusuario" tiene un halo que por mucho que le expliques a alguien en una máquina Windows no lo puede entender.

Asociado al rol de superusuario no sólo hay destrezas sino también anécdotas y desastres.

Cualquier persona que haya pasado tiempo administrando un sistema UNIX, sabrá que lo peor que puede hacer es "rm -rf /" (esto borra todos los ficheros hasta que te has pulido el sistema, o hasta que haya desaparecido algo importantísimo como la libc.so). Una de las primeras cosas que debes recibir con la contraseña de superusuario es el título de saber hacer backups y de saber instalar el sistema, para que no sea otro el que tenga que arreglar tus desastres.

En sistemas "reales", el poseedor de la contraseña de root es una persona con poder: puede leer el correo de otros, borrar sus archivos... por tanto un superusuario tiene que tener ciertas convicciones "éticas".

Bibliografía
Capitulo 7 del libro de Nemeth

http://iie.fing.edu.uy/ense/asign/admunix/superusu.htm

http://www.dsi.uclm.es/asignaturas/42602/seguridad.pdf