INTRODUCCIÓN
 
El sistema operativo UNIX surgió en los laboratorios de la AT&T Bell como un proyecto de
algunos programadores que querían hacer un SO para ellos mismos.
Aunque nunca hayamos usado UNIX, casi todos los sistemas de la actualidad tienen conceptos
tomados de él incluyendo al DOS, OS/2, NT, etc.
UNIX es algo así como el latín de los sistemas operativos. Uno de los factores que motivan el
que hoy se escuche más acerca de este sistema operativo es la aparición del LINUX ,un clon de
UNIX freeware.
La palabra UNIX es una marca registrada ,que fue pasando de manos con el tiempo y
actualmente esta en poder de Novell. Sin embargo ,muchas empresas diseñaron sistemas UNIX
compatibles. Cuando se habla de compatibilidad entre UNIX , generalmente se habla de
compatibilidad nivel código fuente.
O sea que se puede tomar un programa escrito en C para una plataforma, compilarlo y usarlo en
otra. Los sistemas operativos ”a lo UNIX” son: SCO UNIX,BSD UNIX ,AIX DE IBM,
UnixWare de Novell Linux. UNIX es un muy buen SO y se puede usar para casi todo, pero el
ámbito en donde se destaca es en redes. Y esto incluye Internet .Como Internet en sus comienzos
estuvo lejos del publico en general, y mas cerca de los investigadores, fue natural que la
plataforma de elección fuera UNIX.Y es así como todos los conceptos que giran en torno a
Internet, sus protocolos, sus servicios, tienen alguna relación con UNIX.
La interfase gráfica que se usa en el ambiente UNIX se llama Xwindows, y es muy
poderosa .Esta diseñada para trabajar en cualquier sistema operativo y cualquier computadora ,y
para funcionar sobre una red con las aplicaciones corriendo en una maquina remota.
La forma de moverse dentro de UNIX es parecida a DOS .Los comando mas comunes son:
 
Pwd..........para averiguar cual es el directorio actual
Is..............para pedir un listado del directorio actual
cd.............para cambiar el directorio
mkdir.......para crear un directorio
cat............para ver un archivo
echo.........imprime una cadena de caracteres
cp.............copia un archivo
mv............mueve o renombra un archivo

SISTEMAS DE ARCHIVOS
 
El sistema de archivos de Unix; esta basado en un modelo arborescente y recursivo, en el cual
los nodos pueden ser tanto archivos como directorios, y estos últimos pueden contener a su vez
directorios o subdirectorios. Debido a esta filosofía, se maneja al sistema con muy pocas
órdenes, que permiten una gran gama de posibilidades. Todo archivo de Unix está controlado por
múltiples niveles de protección, que especifican los permisos de acceso al mismo. La diferencia
que existe entre un archivo de datos, un programa, un manejador de entrada/salida o una
instrucción ejecutable se refleja en estos parámetros, de modo que el sistema operativo adquiere
características de coherencia y elegancia que lo distinguen.
 
La gestión de archivos
 
La gestión de archivos viene implementada por mecanismos propios de UNIX. Esta
aproximación tiene consecuencias directas sobre la seguridad del sistema.
 
Convenciones
 
UNIX comporta un sistema de gestión de ficheros ( SGF ) que permite al usuario guardar sus
datos en disco. Par gestionar la información en forma estructurada, el SGF debe organizar el
disco de determinada manera y crear un sistema de ficheros ( SGF ) en el momento de realizar
una operación de formateo lógico ( diferente del formateo físico del disco realizado por su
controlado.
El SGF designa el mecanismo que permite acceder a los objetos de la entidad SF. Un SGF
complejo puede gestionar varios tipos de SF diferentes a la manera de VFS (Virtual File
System ) de SVR4.
 
Dispositivos
 
Los sistemas de ficheros se gestionan como dispositivos en modo bloque, se encuentran en el
directorio /dev/dsk (Disk). Los Sf pueden ocupar físicamente todo o parte de un disco, sus
nombres se refieren pues al disco físico.
 
Según los sistemas, se encuentran:
 
         Bien c0d2s1 de Controler 0 Drive 2 Slice ( slice=partición)
         Bien 0s1 de Controler 0 Slice 1.
 
En el directorio /dev/rdsk (Raw Disk) se encuentran los mismos nombres. Estos dispositivos
designan los mismos SF del directorio /dev/dsk pero en modo carácter. Se puede verificar que
los menores y los mayores corresponden. Al escribir y leer sobre estos dispositivos, se accede
directamente a la partición, aunque ésta no sea UNIX y ello ignorado toda estructura propia de
un sistema de gestión de ficheros.
Generalmente el dispositivo 0s0 (o c0d0s0) se refiere a todo el disco físico independientemente
de su particionamiento. Por razones de seguridad, es pues muy importante prohibir los derechos
de lectura-escritura-ejecución para group y other ( el propietario debe ser el superusuario )
 
Estructura de un sistema de ficheros
 
Un SF ( sistema de archivos ) esta dividido en bloques lógicos cuyo tamaño varia según su tipo:
512. 1024 o 2048 octetos.
El superbloque describe todas las características del Sf. Ocupa el bloque numérico 1, pero ciertos
SF hacen una copia en el segundo. Los bloques 0 y 3 no se utilizan.
 
 
 
 
 

x
x

Superbloque Tabla de inodos Bloque de datos

 
 
 
Un inodo describe las características de un objeto del SGF ( fichero normal, conexión con
nombre directorio, dispositivo ) Se encuentra por ejemplo su tipo, su fecha de creación, y
punteros a las tablas que describen los sectores ocupados por el fichero. En SVR3.2, el tamaño
máximo de un fichero es de 16 gigaoctetos.
 
Estructura de directorios
 
 
Un bloque lógico asignado a la descripción de un directorio tiene la estructura siguiente:

Inodo
Nombre 14 octetos
2 octetos
100
105
358

205 205                                                                                                             titi

 
 
 
 
 
 
< inodo > es el número de inodos ( identificador interno de un fichero ) que es en realidad un
índice en la tabla de
inodos.
< Nombre > es el identificador externo.
 
Integración
 
Un sistema de ficheros puede crearse tanto en disco duro como disquete si el sistema integra los
dispositivos de modo bloque correspondiente.
 
Un sistema de ficheros esta vinculado al sistema de ficheros raíz mediante una operación de
montaje. El punto de montaje esta constituido por un directorio vacío al que se engancha un
volumen lógico gestionado por SGF. Cuando el usuario se refiere a este directorio ( o a un
archivo de este directorio ), UNIX hace referencia al dispositivo en modo bloque asociado tal
como se describe en la VTOC.
 
Derechos de acceso
 
UNIX gestiona los acceso a los ficheros ( directorio, dispositivo, ficheros normales ) por medio
del triplete lectura-escritura-ejecución que se repite en tres ocasiones, una primera para el
propietario, la segunda para el grupo y la tercera para los demás.
 
Para los ficheros ( normales, dispositivos, conexiones con nombre ) los derechos de acceso son :
 
r lectura
w escritura
x ejecución
 
La verdadera seguridad en UNIX se encuentra a nivel de directorios. Así, los derechos de acceso
significan:
 
r lee el contenido del directorio, es decir él numero de inodo y su nombre. Por ejemplo, el
usuario no puede ejecutar en el mandatos ls –l, sino solamente ls.
w escribe en el directorio, es decir crea y suprime objetos ( ficheros, directorios)
x proporciona el derecho a recorrer el directorio ( recorrer los subdirectorios ) y utilizar
informaciones de los objetos del directorio, es decir, acceder a los inodos.
 
El ejemplo siguiente ilustra la importancia de los derechos de acceso sobre los directorios.
 
 
/toto
 
 

 
user1 user2
 
 
 
 
 
 

f11 f12 f13

f21 f22 f23
 
 
 
 
Con los derechos de acceso posicionados como en el ejemplo anterior, los archivos accesibles a
user1 para lectura son :
 
         f11, f12, f13.
 
No tiene acceso a ninguno de los archivos de user2 porque no tiene derecho en ejecución sobre el
directorio /toto/user2 para group.
 
Los archivos accesibles en modo lectura para user2 son:
 
         f21, f22, f23.
         f11 y f13 ( el archivo f12 requiere el derecho de lectura para el grupo )
 
Los archivos que puede suprimir user2 son:
 
         f21, f22, f23.
         f11, f12, f13 ( el directorio /toto/user1 tiene el derecho en ejecución para el grupo )
 
Par ejecutar un programa en un directorio, solamente es necesario el derecho en ejecución sobre
este ultimo. Si el derecho en lectura no esta autorizado para este directorio, el usuario no podrá
ejecutar todo programa que se encuentre en el ( con los derechos de lectura-ejecución )
 
EL SISTEMA DE ARCHIVOS
 
Todo en el sistema UNIX son archivos. El sistema de archivos es indispensable para el
éxito y utilidad del sistema UNIX.
 
Conceptos básicos sobre archivos.
 
Un archivo es una secuencia de bytes. (Un byte es un pequeño trozo de información,
normalmente compuesto por 8 bits. Para nuestro propósito, un byte es equivalente a un carácter.)
El sistema no impone estructura alguna a los archivos, ni asigna significado a su contenido ; el
significado de los byte depende únicamente de los programas que interpretan el archivo.
Además, esto es cierto no solo para archivos en disco sino también para dispositivos periféricos.
Cintas magnéticas, mensajes de correo, caracteres de teclados, salidas de impresoras, datos que
fluyen en interconexiones, cada uno de estos archivos no es mas que un secuencia de bytes desde
el punto de vista del sistema y sus programas.
Cada byte de un archivo contiene un numero de tamaño suficiente para representar un carácter.
El código empleado en la mayoría de los sistemas UNIX es ASCII (“Código Norteamericano
Estándar para Intercambio de Información”), Pero algunas computadoras, entre las que
sobresalen las IBM, usan un código llamado EBCDIC (“Código Extendido de Intercambio
Decimal Codificado en Binario”).
Los programas obtienen los datos de un archivo por medio de una llamada al sistema (una rutina
del núcleo) llamada read . Cada vez que se invoca a read , esta regresa la siguiente porción de
un archivo, la siguiente línea de texto tecleada en la terminal , por ej. read también indica
cuantos bytes trae el archivo, por lo que al final del archivo es identificado en el momento en que
read dice “ se traen cero bytes”. Si se hubieran quedado algunos bytes en el archivó, read los
hubiera leído. En realidad , tiene sentido no representar el final de un archivo con algún valor en
especial, ya que, como se menciono anteriormente , el significado de los bytes depende de como
se vaya a interpretar el archivo. Pero todos los archivos tienen un final, y como todos los
archivos deben accesarse por medio de read , regresar un cero es una manera de representar el
final de un archivo ( independientemente de cualquier representación ) sin introducir ningún
carácter especial.
Cuando un programa lee de la terminal el núcleo envía al programa cada una de las líneas de
entrada solo cuando se teclea su carácter de nueva-linea (es decir, cuando se oprime RETURN ).
Por lo tanto si se comete un error mecanografico, uno puede corregirlo si es que se lo detecta
antes de teclear el carácter de nueva-linea. Si no es así la línea ya ha sido leída por el sistema y
no podrá corregirse.
 
¿ Que hay en un archivo ?
 
El formato de un archivo depende de los programas que lo usen ; existe gran variedad de estos de
archivos, debido a que también existen muchos programas. Sin embargo, puesto que los tipos de
archivos no son determinados por el sistema de archivos, el núcleo no puede decirnos cual es el
tipo de un archivo : no lo conoce.
 
$ file /bin /bin/de /usr/ src/ cmd/ de.c/ usr/ man/ man1/ de.1
/bin : directory
/bin/ de : pure executable
/usr/ src/ cmd/ de.c : c program text
/usr/ man /,an.1/ de.1 : roff, nroff, or eqn input text
 
Estos son cuatro archivos típicos, relacionados todos con el editor : el directorio en el cual este se
encuentra (/ bin), el programa mismo en su forma ejecutable o binaria (/ bin/ ed) , el o conjunto
de instrucciones en C que definen el programa (/ usr/ src/ cmd/ de.c) y el manual (/ usr/ man/
man1/ de.1).
Para determinar los tipos, File no puso atención a los nombres (aunque podría hacerlo), ya que
las convenciones con los nombres, por el echo mismo de no ser mas que convenciones, no son
confiables. Por ejemplo, los archivos con subfijo .c son programas fuentes en C, pero nada
impide al usuario crear un archivo .c con un contenido arbitrario. En vez de eso, el comando file
lee unos cuantos cientos de bytes al principio del archivo y busca indicios que indiquen el tipo de
archivo en cuestión.
Algunas veces los indicios para identificar un archivos son obvios. Un programa ejecutable se
marca con un “numero mágico” binario al principio. El comando od sin ninguna opción vacía el
archivo en palabras de 16 bits (o dos bytes) y hacen visible el numero mágico :
 
$ od /bin /de
0000000 000410 025000 000462 011444 000000 000000 000000 000001
0000020 170011 016600 000002 005060 177776 010600 162706 000004
0000040 016616 000004 005720 010066 000002 005720 001376 020076
 
El valor octal 410 “marca” un programa ejecutable puro, un programa cuyo código puede ser
compartido por varios procesos. (los números mágicos específicos son dependientes del sistema).
El patrón de bits representado por 410 no es un texto en ASCII, por lo que este valor no podría
ser generado inadvertidamente por un programa tal como un editor. Sin embargo, el lector puede
crear un archivo así ejecutando un programa propio, y el sistema entenderá la convención de que
tales archivo son programas en binario.
Para archivos de texto, los indicios que indicar el tipo de archivo en cuestión pueden encontrarse
mas escondidos en el. Por ejemplo, el comando file buscará palabras como #include para
identificar programas fuente en C, o líneas que comiencen con un punto para identificar entradas
para nroffo o troff.
 

 
PERMISOS
 
Cada archivo tiene un conjunto de permisos asociados con él, los cuales determinen que hacerse
con el archivo y quien puede hacerlo.
Existe un usuario especial en cada sistema UNIX, llamado superusuario, quien puede leer o
modificar cualquier archivo en el sistema. La clase de acceso especial root posee privilegios de
superusuario: esta la emplean los administradores del sistema cuando llevan a cabo el
mantenimiento del mismo. Existe también un comando llamado su que otorga un status de
superusuario si se conoce la contraseña de root. Por eso no es recomendable guarda ningún
material confidencial en el sistema de archivos.
Si el usuario requiere mayor seguridad, puede cambiar los datos en un archivo de manera que ni
aun el superusuario puede leerla ( o al menos entenderla ) usando el comando crypt.
Cuando un usuario entra en sesión, teclea un nombre y después confirma que efectivamente es
esa persona tecleando una contraseña ( password ) El nombre es la identificación para iniciar la
sesión del usuario, o login-id. Pero el sistema en realidad reconoce al usuario por medio de un
número, llamado su “ identificación ( o identificación ) de usuario ” o uid.
El sistema de archivos y por tanto el sistema UNIX en general determinan lo que el usuario hacer
mediante los permisos otorgados a su uid y a su group-id.
 
 
El archivo es texto ordinario, pero las definiciones de los campos y los separadores son una
convención reconocida por los programas que usan la información del archivo.
Existen tres tipos de permisos para cada archivo: leer ( es decir, examinar su contenido ),
escribir ( es decir, cambiar su contenido ) y ejecución ( es decir, ejecutarlo como un programa ).
Además, se puede aplicar un permiso diferente a cada persona. Como dueño de un archivo, el
lector posee un conjunto de permisos de lectura, escritura y ejecución. Su grupo tiene otro
conjunto. Los demás tienen un tercer conjunto.
El bit de set-uid es una idea simple pero elegante que resuelve varios problemas de seguridad.
Es particularmente serio para un programa con atributo set-uid ya que root tiene permisos de
acceso a cualquier archivo en el sistema. ( Algunos sistemas UNIX apagan el bit-uid cuando un
archivo se modifica, para reducir el peligro de una falla de seguridad )
Existen llamadas al sistema que crean y borran archivos, y solo a través de ellas es posible
cambiar el contenido de un directorio. Sin embargo, la idea de los permisos aun se aplica.
Los permisos para borrar archivos son independientes del archivo mismo. Si el usuario tiene
permiso de escritura en un directorio, puede borrar archivos de el, aun los que estén protegidos
contra escritura.
 
NODO-I
 
Un archivo posee varios componentes : un nombre, contenido e información administración
como permiso y fechas de modificación. La información administrativa esta almacenada en el “
nodo-i ”( en ingles muchas veces se usa inodo ( sin guión ) en vez de i-nodo ), junto con datos
esenciales para el sistema tales como su longitud, la región del disco en la que se encuentra
almacenado el contenido del archivo y otros elementos.
Existen tres fechas en un i-nodo: la fecha en la que se hizo la ultima modificación ( escrita ) al
contenido del archivo, la fecha en la que dicho contenido fue usado ( leído o ejecutado ) por
ultima vez y la fecha en la que el i-nodo fue alterado por ultima vez, por ejemplo, para definir los
permisos.
El nombre de archivo en un directorio se llama liga ( link ) ya que une un nombre en la jerarquía
de directorio al nodo-i y, en consecuencia, a los datos. El mismo numero-i puede aparecer en
mas de un directorio.
Por lo tanto el nodo-i es un registro que almacena información sobre el archivo determinado y
contiene:
 
1) 1)      Identificación de usuario y de grupos de archivos.
2) 2)      Instantes del ultimo acceso y de la ultima modificación.
3) 3)      Contador con él numero de HORD-LINK al archivo.
4) 4)      El tipo de archivo.
5) 5)      15 apuntadores a bloques de disco.
Los primeros 12 bloques apuntan a bloques directos, o sea que se puede referenciar
inmediatamente a 12 directorios de bloques de datos de archivos ( ya que existe una copia del
nodo-i en memoria principal, mientras el archivo esta abierto ).
Los siguientes tres apuntan a bloques indirectos ( del tamaño del bloque grande ):
- -         El primero es la dirección de un bloque indirecto simple ( bloques de direcciones de
bloques de datos )
- -         El segundo apunta a un bloque indirecto doble ( bloque de direcciones de bloques que
apuntan a bloques de datos )
- -         El tercero apunta a un bloque indirecto triple ( no se lo necesita )
 
Acceso
 
Si el primer carácter del nombre del camino es “/ ” ( slash ) es el directorio raiz, sino el directorio
de partida es el proceso actual. El final es el nombre de un archivo, se realiza el proceso en busca
de este nombre y si no se lo encuentra, se emite un mensaje de error.
Par los archivos no en disco se designan controladores apropiados para manejar su
entrada/salida.
 
Mapeado
 
Se utiliza para indexar en una tabla de archivos abiertos el proceso actual. Cada entrada en la
tabla contiene unos apuntados a una estructura de archivos, que a su vez apunta al nodo-i.
La estructura del nodo-i es un copia en memoria que hay en disco, con campos extras.
 
JERARQUIA DE DIRECTORIOS
 
El UNIX al estar estructurado en árbol se forma una jerarquía de directorios que para un sistema
seria:
 
/ Raíz del sistema de archivo.
/bin Programas esenciales en forma ejecutable
/dev Archivos de dispositivos.
/etc Sistemas diversos.
/etc/motd Mensaje del dia al inicio de sesión.
/etc/passwd Archivos de contraseñas.
/lib Bibliotecas esenciales, etc.
/tmp Archivos temporales, desaparecen cuando se reanuda el sistema.
/unix Forma ejecutable del sistema operativo.
/usr Sistemas de archivos del usuario.
/usr/adm Administración del sistema, información contable, etc.
/usr/bin Binarios del usuario.
/usr/dict Diccionario ( words ) y soporte de spell ( 1 ) etc.
 
Los directorios se crean mediante la llamada al sistema mkdir y se pueden eliminar mediante
rmdir. El directorio actual se cambia mediante chdir.
DISPOSITIVOS
 
Como lo indica su nombre, /dev contiene archivos de dispositivos.
Una de las mejores ideas del sistema UNIX es la manera en que trata los periféricos ( discos,
unidades de cinta, impresoras, terminales, etc. ).Por ejemplo, en lugar de tener rutinas del
sistema especiales para leer cintas magnéticas, existe u archivo llamado /dev/mt0 ( dependiendo
esto también de las costumbres locales )
Dentro del núcleo, las referencias a ese archivo se convierten en comandos de hardware para
acceder la cinta, así, si un programa lee /dev/mt0. Obtiene el contenido de una cinta montada en
una unidad de cinta.
 
Creación de un sistema de un sistema de archivos
 
La creación de un SF puede hacerse en 6 etapas:
 
1- 1-     Dar fromateo al soporte físico con el mandato iv o format.
2- 2-     Crear al SF con mkfs.
3- 3-     Montar el SF con el mandato mount.
4- 4-     Crear al directorio /lost+found.
5- 5-     Dar nombre al SF con el mandato labelit.
6- 6-     Dar formato a un volumen.
 
 
MANEJO DE ENTRADA/SALIDA
 
El sistema de entrada/salida se divide en dos sistemas complementarios: el estructurado por
bloques y el estructurado por caracteres. El primero se usa para manejar cintas y discos
magnéticos, y emplea bloques de tamaño fijo (512 o 1024 bytes) para leer o escribir. El segundo
se utiliza para atender a las terminales, líneas de comunicación e impresoras, y funciona byte por
byte.
En general, el sistema Unix emplea programas especiales (escritos en C) conocidos como
manejadores (drivers) para atender a cada familia de dispositivos de E/S. Los procesos se
comunican con los dispositivos mediante llamadas a su manejador. Además, desde el punto de
vista de los procesos, los manejadores aparecen como si fueran archivos en los que se lee o
escribe; con esto se logra gran homogeneidad y elegancia en el diseño.
Cada dispositivo se estructura internamente mediante descriptores llamados número mayor,
número menor y clase (de bloque o de caracteres). Para cada clase hay un conjunto de entradas,
en una tabla, que aporta a los manejadores de los dispositivos. El número mayor se usa para
asignar manejador, correspondiente a una familia de dispositivos; el menor pasa al manejador
como un argumento, y éste lo emplea para tener acceso a uno de varios dispositivos físicos
semejantes.
Las rutinas que el sistema emplea para ejecutar operaciones de E/S están diseñadas para eliminar
las diferencias entre los dispositivos y los tipos de acceso. No existe distinción entre acceso
aleatorio y secuencial, ni hay un tamaño de registro lógico impuesto por el sistema. El tamaño de
un archivo ordinario está determinado por el número de bytes escritos en él; no es necesario
predeterminar el tamaño de un archivo.
El sistema mantiene una lista de áreas de almacenamiento temporal (buffers), asignadas a los
dispositivos de bloques. El Kernel usa estos buffers con el objeto de reducir el tráfico de E/S.
Cuando un programa solicita una transferencia, se busca primero en los buffers internos para ver
si el bloque que se requiere ya se encuentra en la memoria principal (como resultado de una
operación de lectura anterior). Si es así, entonces no será necesario realizar la operación física de
entrada o salida.
Existe todo un mecanismo de manipulación interna de buffers (y otro de manejo de listas de
bytes), necesario para controlar el flujo de datos entre los dispositivos de bloques (y de
caracteres) y los programas que los requieren.
Por último, y debido a que los manejadores de los dispositivos son programas escritos en
lenguaje C, es relativamente fácil reconfigurar el sistema para ampliar o eliminar dispositivos de
E/S en la computadora, así como para incluir tipos nuevos.
 
 
ENTRADA Y SALIDA DEL SISTEMA UNIX.

 
Las rutinas más sencillas de entrada y salida se llaman getchar y putchar. Cada llamada getchar
extrae el siguiente carácter de la entrada estándar, que puede ser un archivo, una interconexión o
la terminal: el programa no sabe cual. De modo analogo, putchar pone el carácter c en la salida
estándar, que también es la terminal por default.
La función printf realiza la conversión del formato de salida. Las llamadas a printf y putchar
pueden intercalarse en cualquier orden; la salida aparecera en el orden de las llamadas. Se da una
funcion correspondiente scanf para la conversión del dato de entrada; leera la entrada estandar y
la dividira en cadenas, en numeros,etc.
Getchar devuelve el siguiente byte de la entrada, o el valor EOF cuando encuentra el fin de
archivo (o un error). EOF no es un byte del archivo.

 
Acceso a archivos:
 
Antes de leer o escribir un archivo, hay que abrirlo con la función estándar fopen. Esta función
toma un nombre de archivo, hace unos manejos internos y ajustes con el núcleo y devuelve un
nombre interno que se empleara en las siguientes operaciones con el archivo.
Este nombre interno es en realidad un apuntador, denominado apuntador a archivo, a una
estructura que contiene información sobre el archivo; por ejemplo, la localización de un buffer,
la posición actual del carácter en el buffer, si el archivo esta siendo elido o escrito y cosas
parecidas. Una de las definiciones que se consiguen al incluir <studio.h> es la estructura llamada
FILE. La declaración de un apuntador a archivo es:
FILE *fp; (Esta declaración indica que fp es un apuntador a FILE).
La funcion fopen devuelve un apuntador a FILE; la llamada a fopen en un programa es:
 
Char * name, * mode;
fp = fopen(name, mode);
 
El primer argumento de fopen es el nombre del archivo, en forma de una cadena de [Link]
segundo argumento indica el uso que se pretende dar al archivo; los modos son leer("r"),
escribir("w") y anexar("a").
Si un archivo que se abre para escribirlo o anexarlo, pero no existe ,se crea este en caso de ser
posible, será un error intentar leer este archivo inexistente, lo mismo que intentar leer o escribir
un archivo cuando no se tiene acceso. Si existe un error fopen devolverá el valor del apuntador
invalido NULL(suele definirse como (char*) 0, en <studio.h>).
Para poder leer o escribir el archivo una vez abierto, se dispone n de varias posibilidades, siendo
getc y putc las mas sencillas.
Getc extrae el siguiente carácter de un archivo.
 
C=getc(fp)
 
Coloca en c el siguiente carácter del archivo al cual se refiere fp; devuelve EOF al llegar al fin
del archivo. Putc es analogo a getc.
Putc pone el carácter c en el archivo fp.
Putc(c,fp)
Getc y putc devuelven EOF cuando ocurre un error.
Al iniciar un programa, ya están abiertos tres archivos con sus apuntadores a archivo, estos
archivos son entrada estándar, salida estándar y salida de error estándar; los apuntadores
correspondientes son stdin, stdout, y [Link] apuntadores se declaran en <studio.h> , pueden
usarse en cualquier lugar donde se encuentre un objeto FILE*. Como no son variables sino
constantes no podemos asignarles valores.

Algunas definiciones de <studio.h>

Stdin (entrada estandar)

Stdout (salida estándar)
Stderr (error estándar)
EOF (fin del archivo, generalmente -1)
NULL (apuntador invalido; generalmente 0)
FILE (se usa para declarar apuntadores a archivos)
BUFSIZ (indica tamaño del buffer de E/S a menudo 512 o 1024)
Getc (fp) (regresa un carácter del flujo de datos fp)
Getchar () getc(stdin)
Putc (c, fp) (pone el carácter c en el flujo de datos fp)
Putchar (c) putc(c,stdout)
Feof (fp) (no cero cuando hay fin de archivo en el flujo de datos fp)
Ferror (fp) (no cero cuando hay un error en el flujo de datos fp descriptor de archivo para el
flujo de datos fp.
 
 
Despliegue por pantallas
 
Cuando un archivo es largo y el usuario esta ligado a su sistema por medio de una conexión de
alta velocidad, cat produce la salida demasiado rapida para leerla .
Sea un programa p que muestre el contenido de un archivo una pantalla por vez, espere una
respuesta del usuario después de cada una y luego pase a la siguiente, (p es una abreviatura de un
programa utilizado con frecuencia), p lee los archivos nombrados como argumentos o su entrada
estándar:
$ p vis.c
...
$ grep ' # define ' *.[ch] {p}
...
$
El diseño consiste en imprimir la entrada en pequeños [Link] tamaño adecuado es 22
líneas , una manera sencilla en que p indica al usuario que esta listo consiste en no imprimir la
ultima nueva-linea de cada bloque de 22 líneas. El cursor hará una pausa en el extremo derecho
del renglón y no en el margen izquierdo. Cuando el usuario oprima la tecla RETURN, se
proporcionara la nueva-linea faltante y entonces el siguiente renglón aparecerá en el lugar
adecuado. Si el usuario teclea ctl-d o q al final de la pantalla, p terminara.
 
La rutina efopen encierra una operación muy común; trata de abrir un archivo; sino es posible,
imprime un mensaje de error y termina.
 
A BUFSIZ se lo definió como el tamaño del buffer de entrada. Fgets(buf, size, fp) extrae la
siguiente línea de entrada de fp, hasta incluir una nueva-linea, la coloca en el buffer y agrega un \
0 terminador.
La función strlen regresa la longitud de una cadena ; la usamos para sacar la nueva-linea
rezagada del ultimo renglón de entrada. Fputs(buf, fp) escribe la cadena buf en el archivo fp. La
llamada a fflush al final de la pagina obliga a vaciar el buffer de salida.
La tarea de leer la respuesta del usuario despues de desplegar cada pagina se delega a una rutina
llamada ttyin. Esta rutina no puede leer de la entrada estándar ya que debe funcionar aun cuando
su entrada provenga de una archivo o interconexión.
 
Sobre errores y depuración.
 
La única manera de escribir código sin errores consiste en procurarproducir un diseño limpio y
sencillo, programarlo cuidadosamente y mantenerlo claro al irlo modificando.
Hay varias herramientas del UNIX que sirven para encontrar errores.
Para ejemplificar como funcionan examinemos las función pica que contiene un error:
 
Pick(s) / ofrecer opcion de s */
Char * s;
{
fprint ("%s?",s);
if (ttuin ( ) == ' y ' )
printf ("%s\ n " , s);
}
 
Si la compilamos y ejecutamos, que ocurre?
 
$ cc pick.c - o pick
$ pick * . c intentelo
memory fault - core dumped desastre!!!
 
$
"Error de Memoria" (memory fault) significa que el programa intento referenciar a un área de
memoria a la que no tiene permiso.
"Error en el bus " (bus error) es otro diagnostico de significado similar, provocado a menudo
al examinar una cadena no terminada correctamente.
"Vaciado de memoria" (Core dumped) significa que el núcleo guardo el estado de la ejecución
del programa en un archivo llamado core dentro del directorio actual.
Hay dos programas que permiten examinar los restos del programa adb y sdb. Como la mayoria
de los depuradores de errores, son crípticos, complicados e indispensables adb viene en la
séptima edición; sdb esta disponible en versiones mas recientes del sistema.
 
 
Funciones de uso común de E/S estándar
 
fp = fopen abrir archivo, "r": leer ; "w": escribir ; "a": anexar
c = getc ( fp ) extraer carácter
putc ( c, fp ) introducir carácter
ungetc (c, fp ) introducir un nuevo carácter en el archivo de entrada fp; al
máximo 1 char puede introducirse nuevamente a la vez.
Scanf introducir caracteres . Retorna EOF o numero de campos
convertidos
Fscanf lee de archivo fp
Sscanf lee de cadena
Printf da formato
Fprintf imprime en archivo
Sprintf imprime en cadena
Fgets introduce al máximo n caracteres en s a partir de fp.
Fputs imprime una cadena en un archivo
Fflush pone en el archivo cualquier salida manejada por buffer
Fclose cierra el archivo
Fp = popen abre una interconexión con el comando
Pclose cierra la interconexión
System ejecuta un comando y espera la terminación
 
 
Redireccionamiento de E/ S
 
El error estandar1 se invento para que los mensajes de error aparecieran siempre en la terminal.
Todo archivo tiene 3 archivos estándar, creados cuando este comienza a ejecutarse y numerados
conenteros pequeños llamados descriptores de archivos. La entrada estándar 0 (cero), y la salida
estándar 1 (uno), que son frecuentemente redirigidos de archivos e interconexiones y hacia ellos.
El ultimo con nro. 2, es la salida de error estándar y normalmente se dirige a la terminal.
Algunas veces los programas producen salida en el error estándar aun cuando funcionan
correctamente.
 
Tabla de redireccionamiento de E/ S de Shell.
 
> file dirige salida estándar o archivo
>> file anexa salida estándar o archivo
< file toma salida estándar o archivo
p1 / p2 conecta salida estándar dl programa p1 con la entrada p2
^ sinónimo obsoleto de "/"
n > file dirige la entrada del descriptor de archivo n a archivo
n >> file anexa salida del descriptor de archivo n a archivo
n>& mezclar la entrada del descriptor de archivo n con el descriptor de archivo n
<< s documento presente : tomar la entrada estándar hasta el siguiente s al inicio
de una linea.
<<\ s documento presente sin sustitución
<< 's' documento presente sin sustitución
 
 
E/S de bajo nivel
 
El nivel mas bajo de E/S es una entrada directa al SO. Un archivo lee o escribe archivos en
porciones de tamaño adecuado. El núcleo mete los datos en buffers en porciones que concuerdan
con los dispositivos periféricos y optimiza el uso de los periféricos entre los usuarios.
 
 
Descriptores de archivos.
 
Toda la E/S se efectúa leyendo a escribiendo archivos, ya que todos los periféricos, incluyendo la
terminal, son archivos en el sistema de archivos. Esto significa que una sola interfaz maneja
todas las comunicaciones entre el programa y los dispositivos periféricos.
En el caso más general, antes de leer o escribir un archivo, es necesario comunicar al sistema del
intento; este proceso se conoce como abrir un archivo. Si se va a escribir en un archivo, puede
ser necesario crearlo. El sistema revisa el permiso para hacerlo (existe el archivo) Tiene permiso
de acceso?) , y si todo va bien regresa un entero no negativo llamado descriptor de archivo.
Siempre que se haga E/S en el archivo, se utiliza el descriptor de archivo para identificarlo y, no
el nombre.
 
 
Filtros.
 
Los filtros comparten un diseño común. Cada uno escribe sobre su salida estándar el resultado de
procesar los archivos dados como argumentos o bien la entrada estándar si no se dan los
argumentos. Estos especifican la entrada pero nunca la salida de modo que la salida de un
comando siempre puede introducirse en una interconexión.
Los mensajes de error se escriben sobre el error estándar y, en consecuencia, no desaparecen a lo
largo de una interconexión.-
 
UNIX es un sistema operativo multitarea y multiusuario, lo cual significa que puede
ejecutar varios programas simultáneamente, y que puede gestionar a varios usuarios
simultáneamente. Se desarrolló en los laboratorios Bell (por Kernighan & Thompson), y
aunque al principio se diseñó para el PDP-11, una máquina de Digital, ahora se ejecuta en
gran cantidad de plataformas con muchos tipos de microprocesadores diferentes,
haciéndolo un sistema multiplataforma, y provocando por tanto que un programa en
código máquina ejecutable en una plataforma en UNIX no tenga por qué ser ejecutable en
otra. Sin embargo, todos los UNIX son compatibles a dos niveles.
 
Comandos del sistema operativo, y grupos de ellos, es decir, scripts. Programas en C
en código fuente, siempre que se utilicen las librerías estándar. Una librería es un conjunto
de funciones que el usuario puede utilizar, que vienen aparte del compilador.
 
Esta multiplicidad de plataformas hace que UNIX venga en diferentes sabores, casi
uno por cada fabricante y para cada tipo de máquina. Además, hay dos grupos (bueno,
quizás 3) de desarrollo diferentes:
 
     System V: liderado por AT&T, y acompañado por Sun y otra serie de
fabricantes, va por la versión 4.

     BSD, el más utilizado en las universidades.

 
 Aparte, hay una serie de intentos de llegar a un UNIX totalmente estándar, pero al
haber varios, estos intentos son en vano. En concreto, son los siguientes:

     UNIX International, de AT&T y Sun. Open Software Foundation, que ha

hecho ya un sistema operativo, OSF/1, y un IGU (interfaz gráfica de usuario),
OSF Motif, liderado por IBM y su peña.
Hay otros intentos independientes, como GNU (Gnu's not UNIX), de hacer un
sistema operativo gratuito e independiente del fabricante, y POSIX, un intento estándar del
IEEE. Por supuesto, el más celebre y utilizado hoy en día es el Linux, del cual acaba de
salir la versión 2.2. En realidad, casi todos los UNIX ofrecen compatibilidad POSIX, e
incluso algunos no- UNIX, como el Windows NT, sobre todo si quieren ganar contratos del
gobierno americano, que exige compatibilidad POSIX (especificación GOSIP) para los
sistemas operativos instalados en ordenadores gubernamentales. Y, por supuesto, el
sistema operativo gratuito de más éxito en la actualidad, LINUX, creado inicialmente por
Linus Torvalds con ayuda de mucha otra gente en la Internet. Pero no es único sistema
operativo unixoide gratuito: también está MachTen (para el Macintosh) y NetBSD.
En fin, el estándar de facto es SunOs, o Solaris 2.5, de las estaciones de trabajo Sun
y compatibles, ya que es el utilizado por la mayoría de los ordenadores instalados.
UNIX es un sistema operativo de red y tiene algunas características de sistema
distribuido, ya que existe un nombre único para todos los ficheros disponibles en la red, y
que es independiente de la máquina, o más específicamente, en ese nombre no se incluye el
nombre de la máquina en el que el fichero está almacenado. Esto se denomina
transparencia de localización, y se logra, por ejemplo, con el NFS de Sun.
 
Hay cienes de interfaces para usuario basados en UNIX, pero la mayoría utilizan
como rutinas básicas para dibujo y gestión de ventanas X-Windows, también llamado X11,
por ser la última versión. X-Windows no es la interfaz para el usuario, pero son utilizadas
por diversas interfaces para el usuario como conjunto básico de primitivas gráficas o
sistema de imaginería. Es, además, un sistema de presentación de gráficos en una red.
Algunas versiones: AIX de IBM, A/UX de Apple, HP-UX de Hewlett Packard,
DG/UX de Data General, SunOS de Sun, IRIX para las estaciones de trabajo Silicon
Graphics; y, en general, casi todo entorno operativo que lleve una X por algún lado.

PROCESOS.
 Un programa ejecutándose es para UNIX un proceso; cada programa recibe del
sistema operativo un número de proceso o pid. Cada proceso tiene una determinada
prioridad de ejecución, y en función de la misma, recibirá la atención de la CPU durante
más o menos tiempo.
Cada usuario puede controlar sus propios procesos, pero no los de los demás. Solo el
superusuario puede controlar todos, y de hecho lo hace muchas veces. Los procesos se
controlan enviándoles señales, que les indican por ejemplo, que deben terminar de
ejecutarse, pero también que deben rearrancar o que que paren para seguir luego más
adelante.
Algunas órdenes relacionadas con los procesos son las siguientes:

     lista de los procesos propios, en la consola actual: (kal-el) ~> ps

PID TTY TIME COMMAND
1270 ttyq1 0:00 ps
553 ttyq1 0:01 tcsh
indica el numero de proceso, en que terminal o teletype se está conectado, el tiempo que se
ha estado ejecutando y el nombre del comando. En Solaris aparecería de la siguiente
forma: turing% ps
PID TTY TIME COMD
13122 pts/44 0:00 ps
11115 pts/44 0:02 tcsh
 
1. 1.    kill <señal> <número de proceso hace que un proceso se deje de ejecutar;
por ejemplo, puede usarse si se hay un proceso “colgado”. En realidad, kill
manda una señal al proceso, a la que ese proceso, normalmente, debe de
responder. Si el proceso no responde, hay que mandarle una señal más fuerte.
Por defecto, kill envía la señal SIGTERM, o “terminar”, pero si el proceso está
especialmente colgado, hay que mandarle la SIGKILL, “asesinar”, escribiendo
kill -KILL <pid> o kill -9 <pid>: a cada señal le corresponde un código
numérico, y a veces una combinación de teclas. Otras señales tienen
equivalencias también en pulsaciones de tecla, como SIGSTOP, “parar”, que
equivale a pulsar Ctrl-Z mientras un programa se está ejecutando, para
pararlo; el programa puede continuar ejecutándose mandándole (curiosamente
también con kill la señal SIGCONT (“continuar”). Otras señales, como
SIGSEGV, o “violación de segmentación”, son enviadas al programa por el
sistema operativo cuando aquel trata de escribir en una posición de memoria
que no debe. Por otro lado, en algunos sistemas existe la orden killall, que hace
lo mismo usando nombres de procesos, en vez de PIDs. En otros sistemas
diferentes, killall manda una señal a todos los procesos.

2. 2.    nice <orden>, renice <numero de proceso> hace que una orden se
ejecute con baja prioridad; y renice altera la prioridad de un proceso una vez
que ya se está ejecutando.
Un proceso, además, se puede ejecutar en background o segundo plano sin que
bloquee un terminal, incluyendo el símbolo de and, &, o ampersand, al final. Control-Z
pasa al background un proceso que se este ejecutando en primer plano; también se puede
hacer con bg <número de proceso>; fg <número de proceso>, sin embargo, lo trae al
primer plano.
Un programa ejecutándose es para UNIX un proceso; cada programa recibe del
sistema operativo un número de proceso o pid. Cada proceso tiene una determinada
prioridad de ejecución, y en función de la misma, recibirá la atención de la CPU durante
más o menos tiempo.
 Cada usuario puede controlar sus propios procesos, pero no los de los demás. Solo el
superusuario puede controlar todos, y de hecho lo hace muchas veces. Los procesos se
controlan enviándoles señales, que les indican por ejemplo, que deben terminar de
ejecutarse, pero también que deben rearrancar o que que paren para seguir luego más
adelante.
Algunas órdenes relacionadas con los procesos son las siguientes:

     lista de los procesos propios, en la consola actual: (kal-el) ~> ps

PID TTY TIME COMMAND
1270 ttyq1 0:00 ps
553 ttyq1 0:01 tcsh
indica el numero de proceso, en que terminal o teletype se está conectado, el tiempo que se
ha estado ejecutando y el nombre del comando. En Solaris aparecería de la siguiente
forma: turing% ps
PID TTY TIME COMD
13122 pts/44 0:00 ps
11115 pts/44 0:02 tcsh
 

1. 1.    kill <señal> <número de proceso hace que un proceso se deje de ejecutar;
por ejemplo, puede usarse si se hay un proceso “colgado”. En realidad, kill
manda una señal al proceso, a la que ese proceso, normalmente, debe de
responder. Si el proceso no responde, hay que mandarle una señal más fuerte.
Por defecto, kill envía la señal SIGTERM, o “terminar”, pero si el proceso está
especialmente colgado, hay que mandarle la SIGKILL, “asesinar”, escribiendo
kill -KILL <pid> o kill -9 <pid>: a cada señal le corresponde un código
numérico, y a veces una combinación de teclas. Otras señales tienen
equivalencias también en pulsaciones de tecla, como SIGSTOP, “parar”, que
equivale a pulsar Ctrl-Z mientras un programa se está ejecutando, para
pararlo; el programa puede continuar ejecutándose mandándole (curiosamente
también con kill la señal).

COMUNICACIONES.
 
 
En los años 70, Brian Kernighan y Ken Thompson, empleados de AT&T, decidieron escribir un
sistema operativo nuevo para una maquina digital muy conocida en ese entonces PDP-7. Dicho sistema
operativo debió ser multiusuario y multitarea. Llamaron a dicho sistema operativo UNIX que, aunque
parezca raro, no son las iniciales de nada, sino que es un derivado de un nombre del sistema operativo
MINIX, el cual evoluciona.

La primera versión de UNIX fue escrito en Assembler, pero en

posteriores versiones se utilizó un lenguaje de alto nivel, él “C”. La idea de
utilizar un lenguaje de alto nivel fue asegurar que el sistema sea portable, es
decir, que pudiera correrse en otras computadoras. En este sentido, UNIX fue el
primer sistema operativo escrito con este objeto en mente.

Un sistema UNIX posee una estructura de capas. En el centro encontramos

el hardware y redondeándolo el corazón o “kernel” del sistema. La función

del kernel es la administración del hardware (memoria, periféricos), y de los

procesos. Por afuera de los mismos encontramos los “shells” o interfaces a

de comando. Los shells son programables mediante scripts, como los

archivos BAT del DOS, pero en un lenguaje mucho mas poderoso. Por afuera

de los shell encontramos los comandos y las aplicaciones. Estos pueden

comunicarse con el shell o con el kernel directamente. En general, las

aplicaciones no interactuan con el hardware como suele suceder con el DOS,

pues de esa manera son portables mas fácilmente entre distintas

plataformas, metas muy buscada en el mundo UNIX y no tanto en el mundo

DOS.

Entre las ventajas que posee encontramos:

      Gran configurabilidad. Muchos parámetros del sistema operativo pueden
ser modificados. De hecho si se licencia el código fuente, puede modificarse
el kernel.
      Diversidad de plataforma.
      A partir del System V Release 4 existen una cierta estandarización.
 
Entre sus fallas se detectaron:
      A pesar de los esfuerzos de todos los desarroladores, aun existen
diferencias entre los distintos UNIX.
      Es un sistema operativo muy poco amigable con el usuario. Así, puede
hablarse de un “temor de UNIX” entre la gente de sistemas que no lo
conocen. Se han desarrollado interfaces gráficas que facilitan en gran parte
su administración y manejo.
 
UNIX fue diseñado desde el principio para facilitar al máximo las
comunicaciones, tanto de los usuarios del sistema como entre los distintos
operadores (computadoras); no solo entre ordenadores con UNIX, sino
también entre ordenadores con UNIX y a ordenadores con otros sistemas
operativos.

 
 
SISTEMAS DISTRIBUIDOS.
 
 
Una meta de largo alcance en las comunicaciones entre las computadoras es proveer
conectividad mundial entre computadoras y usuarios. Para se aceptable el amplio rango de intereses
involucrados, las técnicas de comunicación deben ser decididas por consenso; para tal fin a sido
desarrollado el estándar OSI (Open System Interconnection). Esta es una arquitectura de red de especial
importancia, por que ha sido aceptada en el ámbito mundial.
 
 
ARQUITECTURA OSI.
 
El modelo de referencia OSI es una descomposición arbitraria de
funciones de comunicación de computaras en siete niveles de abstracción
denominados capas. Cada capa tiene ciertas funciones conceptuales asociadas
con ella, las cuales se implementan de varias formas por medios de diferentes
servicios y protocolos.
 
Existe una amplia variedad de estándares que no han tenido acepción mundial.
Algunos de estos son IBM’S System Network Architecture (y a su
implementación DECnet), y el conjunto de protocolos del Departamento de
Defensa de [Link]. (DoD).
 
Los protocolos DoD son ampliamente usados en los Estados Unidos
especialmente en la comunidad de sistemas UNIX.
 
 
 
CAPAS
 
 
Las capas individuales de una arquitectura de red se realizan con
definiciones de servicios y protocolos. En termino de la arquitectura OSI, la
implementación de la capa n es una entidad n. La capa llamada sobre la
entidad n es una entidad (n+1) y es el usuario de servicio n. La capa
inferior a la capa n desde la cual la entidad n requiere servicios, es la entidad
(n-1). Un servicio n, de acuerdo a la modelo referencia OSI, es una capacidad
de la capa n y las capas inferiores a ella, la cual es provista por la (n+1)
entidades en él limite entre la capa n y la capa (n+1).
 
La implementación de interfaces de servicios (por ejemplo, las reglas mediante
las cuales el usuario n requiere (n-1) servicios dentro del sistema abierto), no esta
estandarizado por OSI. Las interfaces de servicios son realizadas típicamente como
llamadas al sistema operativo. La sintaxis y la semántica de las interfaces de protocolos
están rígidamente estandarizadas; estas definen las reglas usadas entre las
comunicaciones de n entidades.
 
 
UNIDADES DE DATOS DE PROTOCOLOS Y DE DATOS DE SERVICIO.
 

Varios tipos de datos conceptuales se han involucrado en la realización de servicios OSI. El

principio básico de movimiento de datos en OSI es que n entidades se comuniquen con cualquier otra
usando una (n-1) conexión entre (n-1) entidades. Las n entidades intercambian n información de
control de protocolo para manejar sus operaciones cooperativas, e intercambian n datos de usuarios. La
combinación de información de control de protocolo y datos de usuario es una unidad de datos de
protocolo (PDU); la semántica y la sintaxis de la PDU están totalmente especificadas en los estándares
de protocolo OSI. Las PDU pueden clasificarse por el nombre de capas (ejemplo: Unidad de Datos de
Protocolos de Red o NPDU).

 
Cuando una entidad n envía n datos de interfaces a una entidad (n-
1), estos datos forman una (n-1) Unidad de Datos de Servicios (SDU). Las
SDU se clasifican usualmente por el servicio que esta siendo usada, tal como
Unidad de Datos de Servicios de Transporte (TSDU) para el servicio de
transporte.
 
Cuando se usa una entidad (n-1) para enviar n SDUs a través de la red,
una entidad (n-1) construye normalmente una PDU en respuesta de servicio
requerido colocando sus propios cabezales y pistas de protocolos alrededor de
una representación de la SDU n. La entidad (n-1) envía entonces las SDU n
encapsuladas como una SDU (n-2) a la capa (n-2) debajo de la entidad (n-
1). La recepción es a la inversa: cada capa saca su propia información de
control de protocolo desde las unidades de datos, y coloca el contenido de los
campos de datos de la PDU n en la entidad (n+1).
 
No se necesita una correspondencia uno a uno entre n SDUs y la (n-1) PDUs
usadas para transferirlas, o entre n conexiones y las (n-1) conexiones sobre las cuales
fluyen las PDUs. Una conexión (n-1) puede soportar mas de una conexión n.
 
 
 
LA CAPA DE APLICACIÓN.
 
 
La capa de aplicación OSI no incluye aplicaciones en el sentido
convencional tales como planilla de pago, inventario, etc. Mas bien, la capa de
aplicación es una interfaces para distribuir funciones del sistema operativo,
tales como la capacidad para abrir un fichero o llamar aun procedimiento
remoto. Esta inteface esta descripta abstractamente, la interface especifica
entre un sistema operativo real y una implementación real de la capa de
aplicación no esta sujeta a la estandarización OSI, ya que estas interfaces están
estandarizadas por diversos grupos tales como X/OPEN, the Open Software
Foundation, UNIX international, y otros.
 
La capa de aplicación tienen componente que proveen servicios a los
elementos de servicios de aplicación especifica (SASE) de software que
no es de OSI, y otros servicios, los cuales proveen servicios dentro de la capa
de aplicación (por ejemplo, a SASE). Los SASEs más comunes son Sistemas
de Manejos de Mensajes (MHS) y Transferencia; Acceso y Manejo de
Ficheros (FTAM). Otros SASEs incluyen Protocolo de Terminal Virtual
(VTP), Servicios de Mensajes Confeccionados (MMS), Servicios de
Directorios (DS), y Proceso de Transacción (TP). El Manejo de Red es
un SASE especial.
 
MHS provee mecanismo para la transferencia de correo electrónico entre
computadoras y entre redes de trabajo; éste no establece la interface humana
para los sistemas de correos.
 
 

PROTOCOLO DE TRANSMISION / PROTOCOLO DE INTERNET.

 

El departamento de Defensa de los [Link]. Ha desarrollado un juego de protocolos ampliamente

aceptado, parte del cual es el protocolo de control de transmisión (TCP) y el protocolo de Internet (IP),
o simplemente TCP/IP.

 
Otros protocolos en este juego incluyen el protocolo de transferencia de
correo simple (SMTP) y protocolo de transferencia de ficheros (FTP). En el
juego de protocolo DoD, los protocolos de “aplicación” tales como SMTP y FTP
incluyen la funcionalidad de las capas cinco a siete de OSI. Los servicios SMTP
son considerados un subconjunto de FTAM. TCP provee servicios generalmente
comparables al transporte de OSI. Un desarrollo considerable ha sido realizado
con el ampliamente distribuido en torno de desarrollo ISO (isode), el cual
provee capas superiores de OSI al principio de TCP/IP; ISODE está migrando a
los sistemas Berkeley`s UNIX.
 
El modelo arquitectónico para los protocolos DoD está informalmente
descripto por Padlipsky, y está dado por cuatro capas: aplicación/proceso,
host-host, red de trabajo y procesador de sub-red de comunicaciones (CSNP)
para CSNP. La capa de aplicación/proceso combina la funcionalidad de las tres
capas superiores de OSI. Los protocolos host-host corresponden
aproximadamente a la capa de transporte OSI, los protocolos de red de trabajo
corresponden a la capa de red OSI, y los protocolos CSNP-CSNP son específicos
para tipos individuales de redes de transmisión.
 
TCP/IP es importante para estudiante de sistema operativo por que es
ampliamente usado. Su éxito está mayormente limitado a los [Link].; No ha
sido aceptado como un estándar en el ámbito mundial. La migración de redes
basadas en OSI es un hecho durante los noventas.
 
 
 
COMUNICACIÓN ENTRE PROCESOS.
 

Muchos recursos separados son provistos para permitir a procesos

concurrentes comunicarse con otros. Los conductores son caminos
unidireccionales sobre los cuales los procesos pueden enviar corrientes de datos
a otros procesos. Los Conductores Etiquetados (del UNIX System V) son
caminos permanentes. Los Mensajes (también de UNIX System V) transfieren
elementos de datos pequeños.
 
SunOs incluye el mecanismo de socket a partir de BSD 4.2. Los sokets
son puntos finales de caminos de comunicación de dos vías. Ellos son
especialmente usados para implementar protocolos de red. Un proceso cliente
en una maquina en la red comienza la comunicación desde u socket; un
proceso servidor en otra máquina escucha al socket para recibir la
comunicación.
 
SunOs provee capacidad de memoria compartida del Sistema V. Los
procesos comparten una porción de memoria; cuando un proceso completa la
escritura a esta área de memoria, otro proceso puede leer los datos. SunOs
provee también semáforos del UNIX System V para controlar el acceso a
recursos compartidos. Un semáforo se usa para bloquear una prioridad de
recurso compartido para su uso; el proceso usa el recurso y luego usa una
operación de semáforo para liberar el recurso.
 

 
CONDUCTOS Y FILTROS.
 

Un conducto es un camino de comunicación, consiste en una cola FIFO

de bytes, entre dos procesos; permite que la salida de un proceso sea la
entrada de otro proceso. La información escrita en un extremo del conducto
puede ser leída desde el conducto en el otro extremo. La sincronización,
planificación y el buffer son manejados automáticamente por el sistema. Un
usuario puede crear una línea de conductos conectando diversos procesos a
través de conductos de modo lineal. El usuario especifica una línea de
conductos al shell mediante una serie de nombres de ficheros separados por
barras verticales. La salida estándar de un fichero ejecutable nombrado a la
izquierda de una barra es la entrada estándar del fichero ubicado a la derecha
de la barra.
 
El llamado al conductor retorna un descriptor para el extremo de
escritura del conducto y otro descriptor para el extremo de lectura. El llamado
al sistema de escritura especifica al descriptor, el área de datos contiene los
bytes que serán escritos, y el número de bytes correspondiente. Si ocurre un
error, retorna el valor -1.
 
 La escritura termina con la llamada al sistema de cierre. La llamada al
sistema de lectura retorna un valor 0 cuando el conductor está vacío y no
hay escritores.
 
Debido a que los procesos asincrónicos pueden leer y escribir en el conducto, el
sistema operativo se realiza las operaciones concurrentes en el conducto. Una escritura
a un conducto lleno bloquea al escritor hasta que haya espacio disponible. Una lectura
desde un conductor vacío bloquea al lector hasta que los datos estén en el conducto.
 
Los conductos son entidades locales; un proceso que desea leer o
escribir en un conducto, debe poseer el descriptor de conductos. Un proceso
que crea un conducto puede utilizarlo, y un proceso hijo de éste también puede
utilizarlo. Los procesos no relacionados necesitan, de cualquier modo,
comunicarse. Para resolver estos problemas, UNIX System III introduce
conductos etiquetados, UNIX System V introducen colas de mensaje, y
Berkeley`s BSD System introduce socket.
 
Un filtro es un programa que procesa una corriente simple de entrada
para generar una corriente simple de salida. Los filtros y conductos pueden
usarse para generar múltiples salidas interesantes.
 
Algunos ejemplos de filtros UNIX son tr (carácter de traducción), cut
(copia solo la porción de una línea), pg (visualiza una página de salida a la
vez), tail (escribe las últimas diez líneas de un fichero), dd (realiza una copia
exacta de un disquete).
 SISTEMAS UNIX DISTRIBUIDOS.

Los sistemas UNIX han desarrollado una posición especial de predominancia en los
sistemaas distribuidos, especialmente por que ellos necesitan interconectar equipos de
muchos fabricantes que utilizan diferentes arquitectura. Teniendo un sistema operativo
común, así como también son comunes los tipos de protocolos de comunicación, facilita la
tarea de los sistemas distribuidos desarrollados.
A continuación se discutirán las cuatros mayores contribuciones que han hecho que
UNIX incremente su viabilidad como una base para los sistemas distribuidos.
 
BERKELEY`S SOCKETS.
El sistema Berkeley`s 4.2 BSD introduce Socket para establecer las
comunicaciones entre procesos en un sistema distribuido. Los Sockets también
establecen comunicaciones entre procesos no relacionados en la misma máquina.
En UNIX 4.3 BSD, el Socket es la unidad fundamental para comunicaciones. Los
Sockets son puntos finales de comunicación. Pueden ser vinculados con nombres. Cada
socket está asociado con uno o más procesos. UNIX 4.3 BSD soporta tres dominios de
comunicación, y los sockets normalmente se comunican con otros sockets en el mismo
dominio. Los tipos de dominio de comunicación son:

     El dominio de sistema UNIX (para comunicaciones “on-

system”).

     El dominio Internet (para comunicación usando protocolos

estándar DARPA).

DARPA es la agencia de Proyectos de Investigación Avanzados

de Defensa del Departamento de Defensa de los [Link].
     El dominio NS para comunicaciones que usan los protocolos
de comunicación estándar XEROX.
 
 
AT&T`s STREAMS.
 
 
 El mecanismo AT&T`s Streams provee un número de características para
transmisiones de alta velocidad. Streams facilita la implementación de
protocolos de red en capas tales como OSI, SNA, TCP/IP y XNS.

Un Streams es un camino bidireccional entre un proceso en el espacio de usuario y un manejador

de dispositivo en el espacio kernel. Los módulos de procesos pueden ser configurados dinámicamente en
un stream de manera tal que los programas pueden agregar servicios a los naturalmente previstos por
los dispositivos.

Con manejadores de dispositivos, las llamadas al sistema son

conmutadas a los manejadores; con streams, las llamadas al sistema crean
mensajes para comunicarse con los manejadores. Un stream asocia un par de
colas (una para lectura y otra para escritura) con el usuario y otro par con el
dispositivo. Las colas son enlazadas para formar un stream entre el manejador
de dispositivo y el usuario. Para cada cola hay cuatros rutinas:
     Open es llamada cuando el dispositivo es abierto.
     Close es llamada cuando el dispositivo está cerrado.
     Put coloca datos en la cola.
     Service sirve la cola y los datos de salida en un dispositivo o en la
siguiente cola.
 

NETWORK FILE SYSTEM (NFS).

 

NFS le da a los sistemas de archivos remotos la apariencia de estar

montados localmente, haciendo la operación de la red transparente a la
ubicación de los archivos.
La computadora de una red es referida como nodos, cada uno con un
nombre único. Un nodo puede ser un servidor, un cliente, o ambos.
Un servidor provee servicios a los procesos o usuarios de uno o más
clientes. Un nodo distribuye las llamadas al sistema y/o los comandos para
conveniencia de un servido o un cliente.
NFS y otros servicios de red de Sun se basan en los estándares Llamado
a procedimiento remoto (RPC) y Representación de Datos Externos (XDR)
desarrollados Sun Microsystem. RPC permite que los programas que se
ejecutan en diferentes sistemas operativos se llamen entre sí y reciban valores
de retorno. El RPC del cliente traduce cada llamada a un formulario estándar y
lo transmite al servidor. El RPC del servidor acepta el llamado, lo traduce al
formato del servidor, e inicia el procedimiento llamado, transfiriendo los
parámetros apropiados. XDR es un formato estándar de representar datos
transferidos entre diferentes máquinas.

AT&T REMOT FILE SYSTEM (RFS).

El sistema de archivos remotos fue desarrollado por AT&T para facilitar la
computación distribuida con el UNIX System V. Es un protocolo independiente; a
medida que protocolos de red nuevos comienzan a emerger (tal como OSI), pueden ser
fácilmente instalados en sistemas basados en RFS.
Los requerimientos son realizados por el cliente, pasando un mensaje al servidor,
este último realiza el requerimiento y devuelve un mensaje en respuesta. RFS usa un
modelo de montado remoto; los nodos individuales comparten en la red sólo aquellos
archivos y directorios que desean; otros archivos permanecen como privados.
Los diseñadores de RFS optaron por usar servidores de estado completo antes
que los accesos a servidores de estado parcial usados en NFS. Una debilidad de los
accesos de estados parcial es que limitan las semánticas de las operaciones remotas.
AT&T optó por usar acceso a servidores de estado completos debido a que desea que
NFS soporte todas las semánticas del sistema UNIX, inclusive las capacidades de estado
completo tales como bloqueo de registros y archivos, y varias operaciones de
dispositivos periféricos.
 
 
CORREO ELECTRONICO Y COMUNICACIONES EN UNIX.
 
COMUNICACIONES ENTRE USUARIOS DEL MISNO SISTEMA.
 
 
Existen dos medios principales de comunicación entre los usuarios de un mismo sistema UNIX:
estos son los ordenadores WRITE y MAIL.
 La orden write fue diseñada para un diálogo inmediato entre dos
usuarios de UNIX. La orden mail sirve para comunicaciones en las cuales en
contenido de las mismas será almacenado en un archivo.
UNIX ofrece también un servicio de agenda de uso transparente
mediante la orden CALENDAR.
 
 

DIALOGO ENTRE USUARIOS CON WRITE.

 
 
Para establecer esta forma de comunicación el usuario debe asegurarse
de que el receptor esté presente en el sistema. Esto se logra ejecutando la
orden WHO. Esta orden nos mostrará el nombre del usuario conectado, el
terminal al que está conectado, la fecha y la hora del comienzo de la sesión.
Los mensajes enviados por write aparecen súbitamente en la pantalla del
usuario receptor. Esto es un inconveniente porque el mensaje puede aparecer
en medio de la creación de un texto importante. Para solucionar esto el usuario
puede denegar el permiso de acceso a la orden write mediante:
$ mesg n: Deniega el permiso de acceso a la orden write.
 
De esta manera, cualquier usuario que desee comunicarse con ese
usuario recibirá el mensaje “Permission denied”.
La orden $ mesg y: otorga nuevamente permiso de acceso a la terminal
para orden write.
 

MENSAJE A TODOS LOS USUARIOS CON WALL.

 

Esta orden está almacenada en el directorio /etc/wall, el cual contiene

varias ordenes que son usadas especialmente por el superusuario. Es
conveniente que este directorio esté incluido en la variable PATH del archivo
profile de todos los usuarios que deseen utilizarlas.
 
 
 
CONFIGURANDO EL CORREO ELECTRONICO

Para mandar y recibir correo electrónico, hay programas específicos, tales como
el Eudora, el P-mail o el Pine; pero en muchos casos es mejor utilizar el cliente de
correo incluido en el navegador de Internet, tal como el Netscape o el Explorer. En el
caso del netscape, para configurarlo hay que seguir los siguientes pasos:

     Depende de las versiones, pero en general hay que ir al menú

Edit<Imagen: $\rightarrow$>Preferences.

     Ahí hay que escoger Mail & Groups, y desplegar el menú pulsando sobre
el triángulo que tiene la punta hacia la derecha.

     Se escoge el submenu Mail Server, para definir el ordenador desde el

cual se va a recoger el correo (Turing en el caso de la ETSII.

     Hay que definir quien es uno (username), que ordenador va a recibir el
correo saliente (outgoing) y de donde se recoge el correo entrante
(incoming). El nombre de usuario será el habitual, el que nos haya asignado
el administrador, y en el caso de la ETSII tanto el servidor saliente como el
entrante son [Link].

     Una vez echo esto, se pueden definir también los grupos de noticias o
newgroup. Se hará lo mismo en el submenú Groups server. En Granada, el
servidor es [Link].

CORREO ELECTRONICO CON MAIL.

 
UNIX mantiene una oficina de correos para todos los usuarios del sistema en el directorio
/usr/spool/mail.

 
 
 
COMUNICACIONES ENTRE ORDENADORES.
 
 UNIX fue diseñado en principio como un S.O. que hace relativamente fácil la comunicación entre
ordenadores, no sólo entre ordenadores con UNIX sino también entre ordenadores con UNIX y
ordenadores con otros S.O.

Aunque las comunicaciones entre ordenadores separados por grandes

distancias a través de líneas telefónicas no son un concepto nuevo, los que
utilizan UNIX poseen la ventaja de que los programas de utilidad necesarios
para establecer las comunicaciones forman parte del S.O. y son directamente
accesibles al usuario final.
 
 
 
CONCLUSION.
 
UNIX es un sistema operativo muy versátil y hoy en día despliega sus potencialidades en
entornos muy disímiles. Entre otros se encuentran los siguientes:
     Mainframes y microcomputadoras de distintos tamaños.
     Estaciones de trabajos.
     Supercomputadors.
     Sistemas tolerantes a fallas (en este caso el sistema corre un derivado de UNIX que
soporta la operación de este tipo de máquinas).
     Sistema de control en tiempo real (en este caso, UNIX fue modificado para dar soporte
a operaciones en tiempo real, es decir, ejecutables en un lapso predecible). Un sistema
comercial UNIX de tiempo real es el QNX.
     LINUX es la variante más popular que posee varias característica que lo hacen único, es
la versión de UNIX para PCs. Fue escrito por el finlandés Linus Thorvald, por ese motivo se
distribuye gratuitamente.
 
1_ Integrantes.
2_ Indice.
3_ Introducción.
4_ Seguridad en UNIX.
5_ Una política de seguridad. Protección de los datos frente a los otros usuarios.
6_ Permisos implícitos para la creación de ficheros.
7_ Cifrado de ficheros. Ids de presentación y contraseñas.
8_ Historial de presentaciones. El superusuario.
9_ El fichero de contraseñas. Un fichero /etc/passwd.
10_ Ingreso y retirada de usuario.
11_ Envejecimiento de contraseña.
12_ Retirada de usuario.
13_ Adición de grupos. El shell restringido.
14_ Protección del sistema y los ficheros de UNIX.
15_ Seguridad física. Redes de área local.
16_ Seguridad uucp. Fichero de permisos de uucp.
17_ Permisos implícitos. Adaptación del fichero Permissions. Control de llamadas de
entrada con la línea Logname.
18_ Control de llamadas de salida con la línea Machine. La orden uucheck.
19_ Máquinas remotas desconocidas y sondeos. Ataques al sistema.
20_ Comportamiento del defensor. Detección de un ataque.
21 y 22_ Caballo de Troya, virus y gusanos, Los UNIX seguros.
23_ Conclusión.
24_ Bibliografía
 
 
INTEGRANTES
1- Alfonso Javier
2- Arce, Benjamin
3- Barrenechea, Ricardo
4- Castro, Maria de los Angeles
5- Catan, Alejandro
6- Deniz, Isabel
7- Harfuch, Fernando Javier
9- Rosales, Mirna Elisa
10- Sosa Jost, Eliana 
 
 
 INTRODUCCIÓN
Unix dispone de muchos modos para que los usuarios accedan al sistema y muchas
herramientas para comunicación entre usuarios y máquinas diferentes. Sin embargo en el mundo
actual hay razones para que personas no autorizadas irrumpan en el sistema computador (ej. El
robo comercial de datos y programas, etc.). Es por esto que hay que equilibrar la facilidad de
acceso para los "amigos" con la prevención de acceso a "enemigos".
El sistema Unix fue originalmente creado para servir a pequeños grupos que
compartían la máquina totalmente. No existían rígidas limitaciones al acceso de un
usuario, a los ficheros y ordenes, de otros usuarios, incluso ni a los datos más sensibles
destinado a mantener en operación el sistema Unix. Cualquier usuario podía fácilmente
eliminar o modificar ficheros, o incluso suspender el sistema.
Lo que se detalla a continuación son algunas de las herramientas y ordenes
relacionadas con la seguridad.
Se pueden adoptar pasos para impedir accesos no autorizados, pero la tendencia
natural de un sistema operativo complejo es hacia la disminución de su seguridad por el
espacio del tiempo: hay que estar constantemente alerta para detectar agujeros en la
seguridad y defender rápidamente el sistema tapando los mismos.
 SEGURIDAD EN UNIX
 
         Introducción.
         Una política de seguridad.
         Permisos implícitos para la creación de ficheros.
         Protección de los datos frente a los otros usuarios.
         Cifrado de ficheros.
         Ids de presentación y contraseñas.
         Historial de presentaciones.
         El superusuario.
         El fichero de contraseñas.
         Ingreso y retirada de usuario.
         Envejecimiento de contraseña.
         Retirada de un usuario.
         Adición de grupos.
         El shell restringido.
         Protección de los sistemas y ficheros de Unix.
         Seguridad física.
         Redes de área local.
         Seguridad uucp.
         Ficheros de permisos uucp.
         Permisos implícitos.
         Adaptación del fichero Permissions.
         Control de llamadas de entrada con la línea LOGNAME.
         Control de la línea de salida con la línea MACHINE.
         La Orden uucheck.
         Máquinas remotas desconocidas y sondeos.
         Ataques al sistema.
         Comportamiento del defensor.
         Detección de un ataque.
         Caballos de Troya, virus y gusanos.
 
 
UNA POLÍTICA DE SEGURIDAD
 
         Dentro de una máquina o red de máquinas:
& El administrador o grupo de usuarios en conjunto, debería establecer una política
de seguridad para:
_ Regular la asignación de nuevos ids de usuario,
_ La cuantía de protección por contraseña requerida dentro del sistema y,
_ La cantidad de conectividad que la máquina permite a las LANs y el mundo
externo.
         La política de seguridad puede ser relativamente simple si:
& El sistema esta relativamente aislado y
& Tiene un pequeño grupo de usuario con la misma comunidad de intereses.
         La política de seguridad puede ser más restrictiva si:
& El sistema es grande y
& tiene varios grupos de usuarios
 & tiene un elevado perfil público, o
& contiene datos especialmente sensibles o
& contiene datos especialmente positivos
         La responsabilidad principal del cumplimiento de las normas de seguridad
corresponde a cada usuario individual,
& Los administradores del sistema pueden desarrollar un procedimiento de
auditorías regulares con realimentación a la comunidad de usuario.
& La regla más importante es conocer el sistema.
         Si el administrador y los usuarios del sistema utilizan:
& Las ordenes ps. Who. Is y
& Otras ordenes de información del sistema.
_ Se familiarizaran con la actividad normal día a día de la máquina y
_ Estarán alertas al estado del sistema en todo momento.
         Las desviaciones de las normas serán rápidamente advertidas.
& El administrador del sistema podrá tomar acciones para taponar los escapes.
         Categorías generales de seguridad:
& Protección de los ficheros y datos privados de un usuario respecto del resto de
los usuarios.
& Protección de los ficheros claves del sistema operativo contra daños accidentales
o intencionales.
& Seguridad física de la máquina.
& Protección del sistema contra determinados ataques por parte de piratas
(hackers).

PROTECCIÓN DE LOS DATOS FRENTE A LOS OTROS USUARIOS

 
Los ficheros del sistema de ficheros tienen tres niveles de permiso:
         Los usuarios individuales.
         Los del grupo al que el usuario pertenece.
         Los de todos los demás usuarios de la máquina.
En una máquina pequeña donde los usuarios comparten una fuerte comunidad de
interés, el administrador del sistema establecerá un único grupo para todos los usuarios,
de modo que todos los usuarios puedan compartir ficheros para sus usos propios. En
instalaciones mayores donde existen varias comunidades no relacionadas, pueden haber
muchos grupos diferentes.
El fichero tiene tres grupos de permisos para cada uno de los tres niveles de
seguridad, es decir, tiene acceso de lectura, escritura y ejecución para el propietario,
para el grupo y para todos los usuarios. Cada fichero es propiedad de un id de
presentación y pertenece a un grupo.
Cuando se crea un nuevo fichero el usuario que lo crea es el propietario del
fichero, y su grupo se asigna como un id de grupo.
Se puede ceder la propiedad del fichero con la orden CHOWN.
Se puede cambiar el grupo del fichero con la orden CHGRP, pero solo si es
propietario del fichero.

 
PERMISOS IMPLÍCITOS PARA LA CREACIÓN DE FICHEROS

El usuario debe preguntarse ¿ Es aceptable que todos los usuarios pertenecientes

al grupo tengan acceso a los datos? ¿ Debería alguien más tener permitido la lectura o
escritura de los ficheros?, y se debe establecer los permisos para cada fichero que fue
creado.
El sistema Unix proporciona automáticamente al creador de un fichero la
propiedad del mismo, y asigna al fichero el grupo de su creador. Se puede declarar una
variable del sistema asociada con el id de presentación que establecerá los permisos de
un fichero sin acción explícita por parte del usuario. Esta variable del sistema se
denomina UMASK (máscara de usuario para creación de fichero), a la cual se accede
con su denominación.
Se puede determinar el valor actual de UMASK ejecutando la orden sin
argumento, el resultado son tres dígitos octales que se refieren a los permisos del
propietario, el grupo y los otros, de izquierda a derecha. A este número se denomina
máscara ya que cada dígito se resta de un permiso implícito global del sistema que todos
los nuevos ficheros obtienen.
Este permiso global es -rw-rw-rw- pero sistemas y programas individuales
pueden diferir de este valor. La UMASK del usuario se resta de este valor implícito, no
se pueden activar permisos con UMASK que estén normalmente desactivados, pero se
pueden desactivar permisos que están normalmente activados.
Se pueden activar explícitamente los permisos con CHMOD si el usuario tiene la
propiedad del fichero.
Cada dígito octal de la UMASK contiene un bit binario que borra un permiso:
 
         Borrará el permiso de ejecución.
         Borrará el permiso de escritura.
         Borrará el permiso de lectura.
 
Si un dígito es cero, se utiliza el permiso implícito por ejemplo:
UMASK 000 significa que no se alteran ninguno de los valores implícitos, o sea, crea
los ficheros con los permisos implícitos.
UMASK 002 crea fichero sin permiso de escritura para el resto de los usuarios.
UMASK 777 desactiva todos los permisos para todos los usuarios.
Para declarar UMASK se utiliza la orden UMASK con el código octal como
argumento. Si se desea modificar permanentemente la UMASK, hay que colocar la
orden UMASK en el fichero, de este modo no se necesita considerar los permisos que se
crean para cada fichero.
 CIFRADO DE FICHEROS

Se puede proteger adicionalmente los ficheros cifrándolos. La mayoría de los

sistemas UNIX disponen de herramientas para hacerlo de acuerdo con una clave que el
usuario proporciona, solo reintroduciendo la clave correcta.
Editores como [Link] y EMACS proporcionan la capacidad de crear y editar
ficheros cifrados. Se puede permitir al editor que descifre un fichero cuando lo cargue y
cifre de nuevo cuando lo escriba al disco.
Cualquier contraseña es aceptable cuando se cifra un fichero, si se introduce la
contraseña correctamente ( la misma ) el fichero será descifrado y aparecerá en el editor.
Cuando se escriba el fichero de vuelta durante o después de la sesión de edición será de
nuevo cifrado. Se puede utilizar este procedimiento para crear un nuevo fichero o para
editar un fichero existente.
La orden CRYPT lee la entrada estandar y escribe la salida estandar. Si la
entrada está cifrada la salida será descifrada.
Desventaja:
El algoritmo por el cual los ficheros son cifrados en el sistema UNIX es poco
conocido y hay programas disponibles que puede reventar el algoritmo descifrado. No
es seguro disponer demasiada confianza en los ficheros cifrados, especialmente en un
entorno hostil. Los programas transgresores descifrados funcionan analizando las
frecuencias de los caracteres en los ficheros cifrados y comparándolos con las
frecuencias de caracteres en el texto ingles normal.
Para vencerlos se puede modificar la secuencia de caracteres del texto normal
antes del cifrado con otro filtro tal como PACK o COMPRESS. El fichero comprimido
no puede ser analizado por ningún transgresor de CRYPT conocido. Cuando se descifre
el fichero hay que recordar desempaquetarlo.
El esquema de protección de ficheros de más éxito es el que implica escribir el
fichero en un disco flexible o cinta magnética, suprimir el fichero de la máquina y poner
en un recaudo el medio magnético.

 
IDS DE PRESENTACIÓN Y CONTRASEÑA
 
El corazón del esquema de seguridad del sistema UNIX es el id de presentación
y la contraseña del usuario individual. Si los atacantes potenciales pueden ser
mantenidos completamente fuera del sistema, no podrán causar daños.
Desgraciadamente en muchas máquinas la seguridad de la contraseña es tan pobre
incluso un infractor sin experiencia puede obtener un SHELL. Es responsabilidad del
usuario defender su propia contraseña y cambiarla regularmente.
Muchos ids de usuario de un sistema pequeño típico no tiene contraseña en
absoluto, o sus contraseñas son tan similares al id de presentación que es ineficaz como
seguridad. Desgraciadamente, la mayoría de los usuarios no desean recordar el tipo de
contraseña secreta que realmente requiere la seguridad, que con el tiempo las mismas
pasan a ser detectables. Todo usuario debería ser forzado a tener una contraseña, la cual
debería ser "envejecida" de modo que el usuario estuviese forzado a cambiarla con
regularidad. Puesto que la contraseña se almacena en forma cifrada, ni siquiera el
administrador del sistema puede determinar cual es.
El ataque por frecuencias de letras no es posible con una muestra de texto tan breve
como una contraseña.
 La herramienta que permite modificar la contraseña es la orden PASSWD. Esta
orden solicita la contraseña actual antes de permitir modificarla. Luego requiere que el
usuario introduzca la nueva contraseña dos veces antes de que tenga efecto.
Existen reglas que describen una contraseña aceptable, incluso si estas reglas no
son forzadas por el software del sistema proporcionan buenas líneas de guía para crear
una contraseña propia.
Una buena contraseña tiene como poco seis caracteres, de los que al menos uno
(preferiblemente dos) es un caracter numérico y otro es no alfabético. Una mezcla de
caracteres mayúsculas y minúsculas es buena y cualquier secuencia inusual o no
intuitiva de caracteres es también útil. Algunos ejemplos de contraseñas triviales no
aceptables son el id de presentación, el nombre del usuario, el nombre de su hijo, su
número de habitación o de teléfono, su signo astrológico, su dirección, etc.

 
HISTORIAL DE PRESENTACIONES

 
Algunas versiones SVR4 muestran la última vez que fue utilizado un id de
presentación, esto aparece cuando el usuario se presenta ante la máquina, de la siguiente
manera:
Login: steve
Password:
Login last: wea occ: 24 15: 11: 02 1990
S
Esto sirve para alertar al usuario cuando alguien más ha estado utilizando su id
de presentación. Si la fecha difiere de la recordada por el usuario de su última sesión su
id de presentación esta siendo mal utilizado y debería inmediatamente tomar medidas
para cambiar la contraseña. Login mantiene en el directorio propio un fichero de
longitud cero denominado lastlogin. La fecha y la hora de la última presentación son las
de modificación de este fichero. Este fichero es de propiedad del sistema no del usuario
individual, y sus permisos lo hacen dificil de modificar. Ejemplo::
S Is-1 shome/. Lastlogin
------------ 1 root sys o oc: 28 15: 11. Lastlogin.
Esta no es una característica de seguridad energética, pero puede avisar al
usuario si su id de presentación ha sido comprometido.
 
 
EL SUPERUSUARIO
 
El id de presentación root se encuentra disponible en todas las máquinas UNIX
para permitir al usuario acceso completo de lectura, escritura y ejecución a todos los
ficheros y directorios. Este usuario es conocido como el superusuario. Para conmutar al
estado de superusuario sin necesidad de despedirse y presentarse de nuevo como root se
utiliza la orden su ( por superusuario ). Ejemplo:
S/soin/su
Password:
=
  
EL FICHERO DE CONTRASEÑAS
 
 En el fichero de base de datos llamado /etc/passwd se encuentra la información
que controla las identificaciones de los usuarios. Ejemplo:
S Is-1/etc/passwd
---------- 1 root 526 aor 10 19: 49 / etc/ passwd
La seguridad del fichero quebraría fácilmente en el caso de que el fichero /etc./
passwd fuera modificable por alguien. Cada usuario tiene una línea en el fichero de
contraseñas, y a su vez cada una de ellas consta de varios campos delimitados por " : ",
también son necesarios varios ids de presentación estandar globales del sistema, siendo
éste el primer campo de la línea y el segundo en un emplazamiento para la contraseña
del usuario " x ", el tercero es la representación numérica del id del usuario y el cuarto
es la representación del grupo, todo esto para su correcto funcionamiento. Estos campos
actúan junto con los permisos del fichero para determinar quien puede acceder a cada
fichero del sistema. Hay un quinto campo que es el de comentario y generalmente
contiene el nombre y la dirección del usuario. El penúltimo campo contiene un
directorio propio del usuario, y el último contiene el nombre de camino completo del
shell de presentación del usuario. Si el último campo falta se señala implícitamente a
/sbin/sh.

UN FICHERO /ETC./ PASSWD TÍPICO

 
Para el correcto funcionamiento de la máquina son necesarios los ids de
presentación los que no pueden suprimirse o modificarse sin provocar daños al sistema.
Los ids de presentación, de usuario y de grupo, el directorio propio y el shell implícito
no deberían ser modificados en ninguna presentación que no pertenezca a un usuario
real.
La identificación root que corresponde al superusuario, es el id usuario cero y su
directorio es el raíz, debería tener siempre una contraseña de lo contrario se convierte en
la peor violación de seguridad en UNIX ya que el usuario tiene acceso completo a todo
el sistema. Los siguientes ids de presentación corresponden a otras herramientas
administrativas en instalaciones grandes son utilizadas por individuos responsables de la
administración de diferentes subsistemas y en una máquina pequeña se pueden
desactivar editando la cadena NONE u otra cadena de texto en el fichero de contraseñas
en /etc./shadow. Al descifrarse la contraseña a partir de la entrada /etc./shadow, una
cadena de texto llano será descifrada en una cadena sin sentido que los usuarios no
podrán adivinar al tratar de abrir una sesión.
Las funciones desactivadas de estos id de presentación las debería efectuar el
usuario root.
Las presentaciones de un sistema pueden diferir dependiendo de la disposición
del hardware de la máquina dado que el software adicional suele añadir presentaciones
administrativas.
La presentación nuucp es utilizada por las máquinas remotas para enviar correos, su shell
es /usr/lib/uucp/uucico. No se necesita una contraseña para la utilización de nuucp pues no se
trata de un shell normal y además el programa uucico es muy seguro.
Todos los id de presentación excepto nuucp deberían tener contraseñas las que
tienen que ser legitimas en clave para los usuarios reales y root.
 
INGRESO Y RETIRADA DE USUARIO
 
Aunque es fácil añadir o suprimir usuarios, solo el superusuario puede hacerlo.
Las herramientas Useradd, Userdel y Usermod están diseñadas para estos trabajos, y su
utilización es preferible a que tener que ingresar manualmente usuarios o utilizar la
orden passmgmt obsoleta. Si se cambian ficheros de control de usuarios tales como
/etc/passwd, manualmente hay que tener la precaución de retener los permisos y
propiedad originales de los ficheros.
Cada usuario tiene un id de presentación, un id de usuario numérico, un
directorio propio, un shell implícito y una contraseña.
Al crear un nuevo usuario se debe especificar los valores de todos estos
componentes. La orden Useradd permitirá dar ingreso a nuevos usuarios en el sistema,
manteniendo valores implícitos, pero es necesario seleccionar los otros cuando se da de
alta a un nuevo usuario. La opción -D(por mostrar display) muestra los valores
implícitos.
Ejemplo:
# userad -D
group=other, 1 baserdir =/home skel =/etc/ skel
shell=/soin/sh inactive=0 expire =
#
Esto muestra los valores implícitos normales asignados a los nuevos usuarios en
el caso de no tomar acción específica. Los nuevos usuarios formarán el grupo other con
id de grupo (gid) 1. Su directorio propio estará bajo el directorio/home y por omisión
obtendrán el shell estandar. Las entradas espire y active se refieren a los parámetros de
envejecimiento de la contraseña. Estos valores implícitos están guardados en el
directorio /etc/stel. Pueden ser modificados con la opción -D con un argumento en la
línea de orden para definir el valor de cada componente implícito. Esto no es
recomendable en los sistemas más pequeños.
Para ingresar un nuevo usuario se especifica el id presentación del usuario tras la
orden useradd:
# useradd # jim
Esto creará la entrada del usuario en /etc/passwd y /etc/shadow utilizando los
valores implícitos y también creará un directorio propio para el usuario. Si todo sigue
bien useradd regresará, si el id de presentación ya existe useradd se quejará:
# useradd jim
UX: useradd: error: jim is already in use. Choose another.
Cada id de presentación debe ser único, pero el directorio propio, el id de
usuario numérico y otra información puede estar compartidos entre 2 usuarios, lo que
no es una buena idea. La contabilidad del sistema se mejora mucho si cada usuario tiene
un entorno individual. La excepción es el id del grupo, que está pensado para ser
compartido entre los usuarios.
Cuando se crea un id de presentación, debería añadirse en comentario que
indique el nombre del usuario, su afiliación y otra información relevante. Este
comentario aparecerá en la entrada /etc/passwd del usuario, y ayudará a seguir la pista
de los usuarios, especialmente en un sistema grande. Para añadir un comentario, utilice
la opción -c en la línea de orden de useradd seguido del comentario entrecomillado del
siguiente modo:
 
# useradd -c "Jim, 555-1234 begin_of_the_skype_highlighting              555-
1234      end_of_the_skype_highlighting, Suite 320" jim.
 
Utilizando argumentos de línea de orden adicionales con useradd se pueden
reemplazar los otros valores implícitos también. Se puede seleccionar un id de usuario
específico(-d) y un shell (-s), además de otros parámetros asociados con la presentación.
Con la opción -e (por expirar) se puede seleccionar una fecha de expiración para la
presentación. Esto permite crear una presentación temporal que queda invalidada luego
de una fecha especificada.
# useradd -e "12/31/90" -c "Presentación temporal para proyecto yabu" jim
 
ENVEJECIMIENTO DE CONTRASEÑA
 
Se crea un id de presentación utilizando useradd, la entrada en /etc/shadow tiene
una contraseña bloqueada [locked] , que el nuevo usuario aún no tiene permitido el
acceso al sistema. Hay que habilitar la presentación seleccionando algunos parámetros
de envejecimiento de contraseña antes de que el usuario pueda utilizar el sistema.
El software de contraseña permite que el administrador del sistema prepare un
procedimiento de envejecimiento de contraseña que fuerce a todos los usuarios a
cambiar su contraseña con regularidad. Cuando se establece una contraseña, se inicia un
reloj, y cuando el intervalo establecido transcurre, la contraseña se descarta y se pide al
usuario que elija una nueva. Cuando se crea una nueva contraseña, el superusuario
permite el envejecimiento de contraseña utilizando la orden passwd. El procedimiento
también borra el estado bloqueado de la contraseña proporcionada al nuevo usuario.
Estas características están limitadas al superusuario, y están soportadas por varias
opciones en línea de orden passwd.
Para definir el máximo número de días que una contraseña puede estar activa
antes de que deba ser modificada, se utilizará la opción -x junto con un número de días:
# passwd -x 120 jim
Para definir el número mínimo de días de una contraseña debe estar activa antes
de que pueda ser modificada, se utiliza la opción -n:
# passwd -n 7 jim
Estas opciones regresarán silenciosamente si no hay error. Debe definirse el
intervalo máximo antes de poder declarar el intervalo mínimo, o se puede colocar ambas
opciones en la misma línea de orden.
La orden passwd también informa del estado de la contraseña del usuario con la
opción -s (por status):
# passwd -s jim
jim LK 00/00/00 7 120
#
Lo primero es el id del usuario, seguido de un status, [lk] significa bloqueado
[locket, ps] significa contraseña correctamente protegida [password y np] significa no
contraseña [no password]. A continuación viene la fecha en que la contraseña fue
modificada la última vez (00/00/00 si la presentación es nueva), seguido de los
intervalos mínimos y máximo.
Después de haber definido los parámetros de envejecimiento de contraseña, se
puede suprimir el estado bloqueado con la opción -d (por suprimir [deleter]),:
# passwd -d jim

La opción -d también puede suprimir la contraseña de un usuario normal. Esta

opción debería ser utilizada con extremo cuidado, ya que una presentación sin
contraseña es un riesgo de seguridad.
Nadie puede crear una nueva contraseña para otro usuario, de modo que cuando
ingresa un nuevo usuario en el sistema el mejor procedimiento es que el administrador
se presente inmediatamente utilizando el nuevo id de presentación y defina una
contraseña inicial manualmente. Luego el administrador puede presentarse de nuevo
como root y ejecutar
# passwd -f jim
que inmediatamente hace expirar la contraseña recién creada. Cuando el usuario se
presente por primera vez, utilizará la contraseña inicial, pero se le pedirá que cambie la
contraseña inmediatamente:
login: jim
Password:
Your password has ezpired. Choose a new one
Old password:
Este mensaje también aparecerá para los usuarios establecidos cuando haya
transcurrido el tiempo máximo permitido para sus contraseñas.
El envejecimiento de contraseñas es útil para el mantenimiento de la seguridad,
ya que las contraseñas de los usuarios tienden a adquirir carácter de públicas después de
que han sido utilizadas durante un tiempo, y el requerir su cambio con regularidad
puede reducir las violaciones de seguridad. El forzar a los usuarios a cambiar su
contraseña 2 o 3 veces al año generalmente es suficiente. Una debilidad del
envejecimiento de las contraseñas es que los usuarios alternan con frecuencia entre 2
contraseñas favoritas que son puras permutaciones triviales la una de la otra. Por lo que
esta práctica debería ser desaconsejada.

RETIRADA DE UN USUARIO
 
Cuando un usuario ha terminado con el sistema, su administrador debería
inmediatamente suprimir el acceso del usuario al sistema, esto puede hacerse de dos
modos: en primer lugar se puede bloquear la contraseña, reteniendo el directorio propio
y la presentación del usuario. Esto impide al usuario entrar al sistema pero
posteriormente puede volver a desbloquearse la presentación sin perder sus datos. Para
ello usa la opción ( por bloquear [ lock ] ) de la orden passwd. Ejemplo:
# passwd- t jim
Se puede retirar completamente al usuario del sistema para ello se usa la orden
USERDEL ( por retirar usuario [ user delete ] ). Ejemplo:
# userdel jim
Esta orden regresará si tiene éxito pero no puede ser usada si el usuario está
presente. La orden USERDEL retendrá el directorio propio del usuario de modo que se
pueda salvar la información que hay en él si se desea. Para suprimir el usuario y el
directorio propio, se debe añadir la opción-r ( por remover ). Ejemplo:
# userdel -r jim
Se pueden cambiar los parámetros asociados con un usuario, sin eliminarlos y
luego restablecerlos con la orden USERMOD.
Se debe ser cuidadoso en mantener actualizada la supresión de usuarios.
Cuando el usuario abandona el sistema el administrador del sistema no desactiva
inmediatamente su id de presentación, habitualmente esto ocurre en sistemas grandes
con cientos de usuarios y presenta un serio riesgo de seguridad, ya que los ex usuarios
pueden guardar rencor y provocar serio daño a la máquina. Se debe tener un cuidado
extremo en examinar regularmente el fichero de contraseñas y retirar a aquellos usuarios
que ya no estén activos.
 
 
ADICIÓN DE GRUPOS
 
Cuando se añade un nuevo usuario a un id de grupo, o se aceptan los valores
implícitos no es necesario desarrollar actividades adicionales después de ejecutar las
ordenes USERADD y PASSWD.
Si se desea crear un nuevo grupo para el usuario o se desea que éste aparezca en
múltiples grupos se debe editar el fichero /etc/group. Se puede usar la orden ADDGRP (
por añadir a grupo) o DELGRP ( por suprimir de grupo ); y para ver que grupo está en
uso /etc/group.
El fichero es una base de datos que tiene campos delimitados por dos puntos.
Los usuarios tienen permitido cambiar de grupo usando la orden NEWGRP (por
nuevo grupo), el segundo campo contendrá una contraseña cifrada que el usuario debe
introducir antes de cambiar de grupo, estos cambios deben estar desactivados.
El último campo en /etc/group contiene una lista separada por comas de los ids
de usuarios que pertenecen a cada grupo. El usuario puede estar en más de un grupo, y
tener acceso a ficheros que pertenecen a diferentes grupos. Para redistribuir los usuarios
en los grupos se debe editar manualmente el fichero /etc/group, limitando los cambios al
último campo. Este fichero debe ser legible por todos pero no modificable ni ejecutable
por nadie.
 
EL SHELL RESTRINGIDO

El shell estandar proporciona facilidades para que el usuario pueda moverse por
el sistema de ficheros, ejecutando muchas ordenes, cambiando el phat, etc. Pero en la
mayoría de los sistemas UNIX existe un shell adicional llamado rsh ( por shell
restringido ) es el mismo programa que el shell normal pero bajo dos nombres en el
sistema: actúa de forma diferente dependiendo del nombre que se utiliza para invocarlo.
En SVR4 el shell restringido está ubicado en el directorio /usr/lib, hay que tener en
cuenta que éste no es el shell remoto utilizado con las LANs que reside en /usr/sbin/rsh.
El shell restringido tiene menos capacidad que el shell normal. Se puede declarar
/usr/lib/rsh como shell de usuario con la orden:
# userad -s /usr/lib/rsh jim
El rsh difiere del shell normal en:
1) El usuario no puede utilizar cd para cambiar de directorio, pues está limitado a su
propio directorio.
2) El usuario no puede cambiar la variable phat solo puede ejecutar las ordenes
residentes en él, preparado por el sistema.
3) El usuario no puede nombrar ordenes o fichero usando un nombre de camino
completo. solamente puede acceder al fichero del directorio propio y sus subdirectorios
4) El usuario no puede redirigir la salida.
Estas restricciones son forzadas luego del profile del usuario. El administrador
del sistema preparará un entorno restringido en el profile del usuario incluyendo un phat
que apunte a un directorio bien limitado, y luego cambiará la propiedad de profile a
root, lo hará legible por todos, pero ejecutable o modificable por ninguno. El usuario
con shell restringido estará limitado al directorio propio y a las ordenes permitidas en el
phat.
El programa rsh evita que usuarios inexpertos se extravíen de sus entornos en los
sistemas de ficheros, normalmente se adjudica a los usuarios que tienen razones
limitadas para presentarse a la máquina.
No es deseable coartar a los usuarios experimentados con rsh pues interferiría
innecesariamente con su trabajo. Rsh no es completamente seguro y cualquier asaltante
experimentado puede fácilmente entrar en el shell normal. No se debe tomar rsh como
herramienta de seguridad para asaltantes pero es útil para que el usuario no
experimentado no se dañe inadvertidamente a si mismo o al sistema.

PROTECCIÓN DEL SISTEMA Y LOS FICHEROS DE UNIX

Incluso los usuarios experimentados pueden dañar al sistema UNIX si tiene

demasiado acceso a ficheros claves, tales como /etc/paswd o a datos de uucp. Hay que
ser cuidadoso al evitar alguna reducción en la seguridad del sistema como resultado de
los cambios normales cuando se instaló el sistema. Normalmente la carga inicial de un
sistema UNIX dispone todo los ficheros y directorios con permisos seguros y correctos,
la excepción pueden ser los ids de presentación del sistema en /etc/passwd que no tienen
contraseñas por omisión.
Inebitablemente, con el tiempo, los permisos se hacen gradualmente menos
seguros debido a que nadie esta perfectamente atento a la seguridad. Los ficheros pasan
a ser más accesibles, las contraseñas desaparecen, las identificaciones de usuarios
inactivos se acumulan, etc.
Generalmente es buena política volver a cargar regularmente la máquina a partir
del software original del sistema lo que se vuelve tedioso para los usuarios y para el
administrador del sistema (que ya a adoptado la máquina a sus necesidades), pero
cuando se sospechan violaciones de seguridad, es el único modo de garantizar un
sistema seguro. Recargar una o dos veces al año es suficiente para la mayoría de las
máquinas.
Cuando se efectúa una recarga hay que asegurarse de que el fichero de
contraseñas este actualizado y borrar todas las ordenes y ficheros no utilizados que
puedan ocupar lugar en los discos. Un buen procedimiento de copia de seguridad de los
datos hace mucho más simple la recarga del sistema.
Una segunda posibilidad es realizar barridas regulares de la máquina y de su
sistema de ficheros, usando un guión automatizado para verificar que los permisos y
propiedades de los ficheros sean seguros. Algunos productos de inoculación
comerciales funcionan con este principio para detectar las formas de corrección de
ficheros. Esta herramienta es dependiente de la instalación especifica, pero un
administrador de sistema inteligente puede crear una herramienta útil.
 SEGURIDAD FÍSICA

Hay que preocuparse por el acceso directo a la máquina por parte de personas
que puedan acercarse a ella en ausencia de usuarios.
La forma primaria de seguridad para un sistema UNIX “es la seguridad física”.
Si se puede impedir el acceso a la máquina, ya sea manteniéndola en una habitación
cerrada con llave o no dejando conexiones externas (modems o redes de ares local) se
puede garantizar que la seguridad no sea asaltada.
Un sistema verdaderamente seguro no tiene conexiones de datos externas,
excepto los terminales conectados dentro de habitaciones cerradas. Si todos los ids de
presentación están correctamente protejidos con contraseñas, no es posible el acceso no
autorizado.
Muchos sistemas UNIX pueden ser accedidos desde un disco flexible o cinta
"maestro".
Muchas máquinas disponen de protección de contraseñas en ROM para retardar
los arranques, pero incluso estas no son completamente seguras.
Un asaltante que sea capaz de llegar a la máquina puede arrancarla y gozar de
privilegios completos a partir de una versión del sistema operativo sobre un disco de
arranque; por lo tanto hay que tener cuidado de que la propia máquina no sea accesible.
Otra clase de ataque sobre la seguridad física se origina cuando se carga el
software y las aplicaciones. Cualquier disco o paquete de aplicación que se cargue en la
máquina puede contener: trampas de seguridad añadidas por su creador o por un
enemigo que pudiera haber tenido el software antes de que usted lo haya recibido.
Una situación típica es que el software se cargue correctamente pero que alguna parte
de él contenga una brecha en la seguridad que se activa cuando esa parte del programa
se ejecuta. O bien el propio programa produce daño a la máquina o produce alguna
modificación en el sistema de modo que un asaltante pueda entrar en él. Estos
problemas no ocurren con paquetes comercialmente disponibles, pero cualquier
software "sin certificación" debe ser considerado bajo sospecha. El software disponible
gratuitamente a partir de boletines electrónicos o el software pirateado que circula de
mano en mano es especialmente sospechoso. No se pueden detectar estos problemas
hasta que se ha producido el daño, por lo que es aconsejable ser extremadamente
cuidadoso al añadir software desconocido a la máquina. En el peor caso, los
administradores de sistema consiente de la seguridad exigirán acceso al código fuente
de las aplicaciones examinándolas cuidadosamente en un entorno seguro y luego
compilándolas directamente en la máquina destino, lo que generalmente no es posible
pero en cualquier caso se puede estar alerta a comportamientos sospechosos por parte de
las fuentes del software.

REDES DE AREA LOCAL

Las máquinas conectadas por medio de redes de área local (LAN) constituyen un
riesgo de seguridad muy peligroso debido a que al introducirse un asaltante en cualquier
máquina de la red podrá fácilmente saltar a otras máquinas, por eso es importante que
los usuarios de máquinas de una red le den la suficiente importancia a las contraseñas
seguras. Dichos usuarios generalmente están asociados en un único proyecto, muchas
LANs tienen herramientas como NFS o rlogin que permiten fácilmente compartir
ficheros y datos entre máquinas. Esto por supuesto es arriesgado, pero es aceptable si las
máquinas individuales se mantienen seguras. A veces es necesario una contraseña
adicional antes de volver a acceder a la red, lo que puede hacer más lento las actividades
de los usuarios pero proporcionan protección adicional cuando la seguridad es una
cuestión importante.
La mayoría de las LANs permiten grupos de máquinas que pueden compartir
fácilmente ficheros o presentaciones remotas. Las máquinas fuera de cualquier grupo
particular tienen acceso restringido a dichos grupos los que hacen que la seguridad de
una máquina en la LAN puede estar comprometida sin corromper por ello a la LAN
entera. Por ende los grupos pueden aliviar significativamente las molestias de la
seguridad. Es aconsejable consultar al administrador de la red para establecer una
política en cada LAN.
 
SEGURIDAD UUCP
 
Los subsistemas de comunicaciones de datos son un gran riesgo de seguridad ya
que son herramientas expresamente diseñadas para permitir el acceso remoto desde el
mundo exterior cuando uucp funciona, se conecta a otra máquina y ejecuta ordenes en
ella, leyendo y escribiendo ficheros cuando se solicita. Al contar con una seguridad
pobre se arriesga a que un asaltante o intruso, incluso una equivocación sin malicia en el
uso de uucp pueda dañar seriamente a la máquina en cambio el software de uucp
moderno es muy seguro y fuerte si se toman precauciones de seguridad. La seguridad
uucp se degrada con el tiempo, por eso hay que estar vigilantes en la observación de sus
herramientas. El principal tema a tener en cuenta en la seguridad asociada con uucp son
los permisos de los ficheros. Los ficheros del directorio /usr/lib/uucp deben mantener
los permisos que tenían cuando se cargó el software en el sistema. Una buena práctica
es listar éstos ficheros con Is-la tan pronto como sean cargados en la máquina y luego
verificar su corrección cada vez que se cambie alguna cosa en los directorios
/usr/lib/uucp o /etc/uucp. El sistema uucp está diseñado de manera que una máquina
posea jerarquía de directorios públicos donde toda actividad de uucp ocurra
normalmente en dicha área pública. Además hay una lista de ordenes que pueden ser
ejecutadas por una máquina remota mediante la orden uux.
La localización del directorio público es /var/spool/uucppublic, y la lista de
ordenes disponibles está formada tan solo por la orden de correo rmail. No se pueden
recibir correo de máquinas remotas a menos que se permita a otras máquinas ejecutar
ésta orden.

FICHERO DE PERMISOS DE UUCP

 
Los permisos de uucp pueden ser personalizados. Los datos de control están
guardados en un fichero leído por los programas uucp cuando éstos se ejecutan. En el
caso de efectuarse una petición que no es permitida por los datos de control, ésta es
rehusada y la conexión uucp se rompe, en cambio si está dentro de la lista aceptable, se
sirve. El fichero /etc/uuco/Permissions contiene ésta información, pero solo deberían
poder leerlo el superusuario y la presentación nuucp.
Los permisos pueden ser desde bastante abiertos hasta bastante restrictivos. El
valor implícito establecido al cargarse la máquina es bastante limitado. En un fichero
ASCH normal las líneas comienzan con # y son tratadas como comentarios, y las líneas
restantes contienen datos. La disposición básica es una serie de líneas que contienen
parejas clave = valor, donde las palabras claves describen la capacidad de controlar y
donde los valores especifican los permisos permitidos. En el caso de haber más de un
valor para una clave, los items deben ir separados con " : ". Cada línea puede controlar
un grupo específico de permisos determinando como actúa la máquina cuando llama a
otras o como son tratadas las otras máquinas cuando son ellas las que llaman a la propia.
Para acomodar el sistema uucp a necesidades concretas se utilizarán varias líneas.

PERMISOS IMPLÍCITOS

Recurrimos a los permisos implícitos por omisión de los "uucp" para obtener
buena seguridad por medio de una entrada simple como:
LOGNAME = uucp
Donde LOGNAME sirve para referirse a los ids de presentación que necesiten
los servicios de "uucp" en las máquinas que pueden llamar a la máquina local las que se
denominan remotas.
LOGNAME = nuucp por su parte restringe el acceso remoto al sistema "uucp" al
id de presentación "nuucp".
Con el fichero Permissions se restringe el sistema "uucp" a transferencias del
fichero al directorio público y desde el mismo. Solo la orden implícita "rmail" esta
permitida.
 

ADAPTACIÓN DEL FICHERO PERMISSIONS

Al fichero se puede agregar más líneas para adaptar a ciertas necesidades la

seguridad de "uucp".
En el archivo pueden haber dos clases de líneas: la que empieza con LOGNAME
que modifica las acciones del sistema para llamadas que entran, y las que comienzan
con MACHINE que modifican las acciones para conexiones con máquinas específicas a
las que llama.
Pueden existir tantas líneas MACHINE como se necesiten a diferencia de
LOGNAME que solo puede haber una.
Al modificarlas hay que agregar parejas adicionales de clave = valor en la misma
línea, en el caso de que ésta fuera demasiado larga puede continuarse con | (diagonal
inversa) para escapar el caracter de nueva línea.
 
CONTROL DE LLAMADAS DE ENTRADA CON LA LÍNEA LOGNAME
 
Cuando una máquina llama a la local se permite que se le envíen los trabajos
ubicados en la cola para ella o se fuerza a la máquina local a llamar a la máquina remota
antes de enviarle trabajos de salida que estén en la cola destinados a ella, ésta última es
más segura ya que una máquina que llame puede mentir a cerca de su "uname" y tomar
ficheros no destinados a la misma. Esta mentira es denominada "spoofing" (engaño) en
el sistema de "uucp", se previene que suceda eso con la última opción.
La palabra clave SENDFILES= añadida a LOGNAME= sirve para controlar si
los trabajos sirven o no para ser enviados cuando la máquina local sea llamada por
ejemplo:
LOGNAME = nuucp SEND FILES = yes permitirá transferencias Y
LOGNAME = nuucp SENDFILES = no impedirá las mismas en todos los casos.
 
La omisión de SENDFILES = call significa que los ficheros solamente serán
enviados a otra máquina cuando sea la máquina local quien la llame y no cuando sea la
máquina remota quien llame a la local. Para controlar si la máquina local permite o no a
una máquina remota solicitar ficheros del sistema local se puede añadir la palabra clave
REQUEST=. Por ejemplo,
LOGNAME= nuucp SENDFILES= yes REQUEST= yes, esto permitirá a la
máquina remota captar ficheros de la local haya o no peticiones para envío lo que puede
ser muy peligroso, debería especificarse REQUEST= no.
También es posible especificar que directorios pueden ser utilizados por
máquinas remotas al leer o escribir ficheros añadiendo las palabras claves READ= y
WRITE= a la entrada de LOGNAME=. El directorio que se especifique designa a una
subestructura completa, de modo que cualquier directorio por debajo del designado
puede ser escrito o leído. Si se utiliza READ=/ y WRITE=/, se permite la lectura y
escritura de todos los directorios de la máquina. Esto es definitivamente no
recomendable. Por omisión se utiliza los valores READ=/var/spool/uucppublic, éste es
el directorio público recomendable.
Cuando haya una llamada de la máquina remota a la local se puede disponer el
sistema "uucp" para rehusar la llamada pero preparar la máquina para que llame a la
remota. Para forzar este comportamiento de devolución de llamada se utilizará
CALLBACK= yes. Por omisión de llamada no es necesario CALLBACK= no.
 
 
CONTROL DE LLAMADAS DE SALIDA CON LAS LÍNEAS MACHINE
 
Se pueden modificar los permisos para una máquina o lista de máquinas
especificadas utilizando la cadena MACHINE= al comienzo de la línea. Cualquier
cambio a la lista de órdenes diferente a los valores implícitos va asociado con una
máquina específica que debe ser nombrada explícitamente en la entrada MACHINE=.
Si se desea que todas las máquinas que llamen tengan los mismos permisos, se puede
utilizar la cadena especial OTHER a continuación de MACHINE= para referirse a todas
las máquinas, o se pueden designar las máquinas específicas que se deseen. Las palabras
clave REQUEST=, SENDFILES=, y WRITE= pueden aparecer en la línea
MACHINE=, con el mismo significado que en la línea LOGNAME=.
Además es posible modificar la lista de órdenes que otra máquina puede ejecutar
en la máquina local, bien cuando las máquinas remotas sean llamadas o cuando sean
ellas quienes ejecuten peticiones "uux" sobre la máquina local. Para cambiar las órdenes
se añade la palabra clave COMMANDS= a la línea MACHINE=, seguido de la lista de
órdenes separadas entre sí por dos puntos. Por ejemplo:
MACHINE=OTHER COMMANDS= rmail:news:lp
 
LA ORDEN UUCHECK

La disposición del fichero Permissions puede ser verificada con la orden

/usr/uucp/uucheck, que comprueba la corrección del subsistema uucp, prestando
especial atención a los datos de Permissions. La orden uucheck está restringida al
superusuario, ya que los permisos de uucp deberían ser mantenidos en secreto. Para
ver una explicación detallada de como están configurados los permisos de uucp, se
utiliza la siguiente orden:
#/usr/lib/uucp/uucheck-v
 
la orden uucheck es una herramienta muy útil que puede reducir sustancialmente la
confusión a la hora de establecer los permisos uucp.
 
 MÁQUINAS REMOTAS DESCONOCIDAS Y SONDEOS
 
Si una llamada de entrada se encuentra que procede de una máquina que el
sistema local no tiene registrado en sus ficheros SYSTEMS, la llamada puede ser
aceptada como normal, o puede ejecutarse un guión shell por parte del sistema uucp
utilizado para registrar llamadas procedentes de máquinas desconocidas, o por
precauciones de seguridad similares. Esta capacidad no esta soportada en el fichero
Permissions: funciona de forma un poco diferente: si el fichero
/usr/lib/uucp/[Link] es ejecutable, la llamada de entrada procedente de una
máquina remota se da por terminada y se ejecuta la orden [Link]: si el fichero
no está presente o no ejecutable, la llamada es aceptada en la categoría
MACHINE=OTHER. Normalmente la característica [Link] está
discapacitada ya que es habitual desear recibir correo de las máquinas que pudieran
tener conocimiento de la máquina local, pero a las cuales la máquina local puede no
conocer. Sin embargo, cuando se sospechan brechas en la seguridad a través del sistema
uucp, esta característica puede ser activada haciendo [Link] ejecutable.
Además el sistema uucp puede ser configurado para sondear a otros sistemas.
Esto significa que una máquina puede llamar a otro sistema y solicitar los trabajos
destinados a ella. Esta característica se utiliza con frecuencia cuando una máquina no
puede llamar a la máquina local por alguna razón, pero la máquina local si puede
llamarla a ella. Por ejemplo: una máquina puede tener solamente soporte de llamada de
entrada.

 
ATAQUES AL SISTEMA

Un ataque malicioso generalmente comienza con piratas que solo desean ampliar sus
conocimientos a través de otro, y una clase de asaltante entrará en la máquina,
curioseará por el sistema de ficheros, se aburrirá, y saldrá de él sin daños, la otra clase
de asaltante sin embargo puede desear robar datos o simplemente dañar al sistema.
La forma de atacar es: el asaltante obtiene el número telefónico o modem (o LAN) a
través de una red de otros asaltantes, o incluso por marcar al azar los números
telefónicos, luego experimenta hasta que descubre un id de presentación desprotegido y
de esta manera acceder a la máquina, entonces puede inspeccionar el fichero de
contraseñas y el resto del sistema hasta que encuentra una oportunidad para cambiar su
id de presentación por root.
Los ficheros del sistema son alterados, los permisos reordenados, y se añaden
órdenes corrompidas al sistema para hacerlo más fácil de quebrar posteriormente, luego
las conexiones de red son exploradas para localizar máquinas cercanas que atacar.
Cuando una máquina es asaltada, el asaltante produce daño tan solo por diversión, y
finalmente la información de acceso será transferida a otro asaltante y el proceso
comenzará de nuevoA cerca de los ataques maliciosos se puede aprender mucho:
En primer lugar la seguridad de las contraseñas es crítica para detener la entrada al
principio, en segundo lugar una vez que un asaltante entra en un sistema detectar y
prevenir el ataque puede ser extremadamente difícil, en tercer lugar una vez que el
sistema ha sido violado es muy probable que el sistema sea atacado de nuevo y los
ataques se extenderán a otras máquinas vecinas, en cuarto lugar si se toman acciones
inadecuadas contra un ataque el asaltante aprenderá de los cambios efectuados y
continuará superándolos.
 
 COMPORTAMIENTO DEL DEFENSOR
 
Generalmente la primera reacción ante la sospecha de un ataque a la máquina
propia es negar que haya ocurrido, se puede pensar en buenas razones que explique
porqué los permisos de los ficheros han sido alterados o incluso cómo se ha modificado
repentinamente el fichero de contraseñas. En realidad uno casi nunca recuerda cual era
el aspecto del sistema lo que el asaltante malicioso aprovechará para introducirse más
profundamente en la máquina. Cuando se esté seguro de que ha ocurrido un ataque se
tratará de negar su importancia, incluso cuando estén activas presentaciones
desconocidas, con frecuencia se querrá contactar con los usuarios por mail o write para
preguntarles porque están usando la máquina haciendo justamente lo que los asaltantes
desean.
Lo siguiente sería anunciar a todos los usuarios que la máquina esta bajo ataque con
esto de nuevo se ha advertido a los asaltantes que han sido descubiertos, entonces
algunos pasos para mejorar la seguridad serían: cambiar las contraseñas eligiendo otras
contraseñas similares a aquellas que los asaltantes puedan haber utilizado. Finalmente
tras repetidos ataques se puede tomar la decisión de cancelar totalmente toda la
conectividad de la máquina, lo que sirve de entrenamiento al atacante pues con el se ha
advertido que se sabe que la máquina esta comprometida y se han efectuado cambios en
la seguridad a un ritmo tan lento que los asaltantes pueden adelantarse a las
precauciones tomadas. Los asaltantes pueden incluso plantar algún software de tipo
Caballo de Troya que atrape las contraseñas cuando alguien se presente ante la máquina.
Como última medida se impedirá el uso propio de la máquina.
Lo aconsejable al detectarse un ataque es no cambiar el sistema mientras se plantea
la defensa, es también inadecuado un anuncio con news describiendo los cambios que se
van a efectuar.
La primera acción abierta debería ser cambiar completamente el sistema: cambiar los
números telefónicos de los modems, volver a cargar el software del sistema, cambiar
todas las contraseñas e id de presentación y luego restablecer las conexiones uucp con
las otras máquinas.
Lo más importante es que en ningún caso debería haber evidencia de que se tiene
conciencia de un ataque.
 
DETECCIÓN DE UN ATAQUE
 
La detección de un ataque puede ser difícil al ser generalmente la mayoría de los
asaltantes más experimentados que los defensores.
Los lugares claves para buscar un ataque son los cambios a los permisos en los
ficheros relacionados con la seguridad o /etc/inittab, /etc/profile, los ficheros de datos de
cron y los ficheros de control de la facilidad de accesos a servicios. Un cambio en el
contenido de cualquiera de estos ficheros es sospechoso, especialmente en
/etc/passwd, /etc/uucp/permissions, los ficheros systems de uucp y /etc/profile.
Los ficheros de registro uucp pueden proporcionar información sobre conexiones
uucp inusuales con otras máquinas que puedan ser desconocidas. Los usuarios inusuales
presentados en la máquina durante horas nocturnas son también sospechosos. El
fichero /var/adm/sulog contiene un registro con todos los usos de la orden utilizada con
frecuencia por los asaltantes.
Un asaltante experimentado puede evitar ficheros tales como sulog para suprimir sus
huellas pero los permisos y la fecha de modificación de los ficheros puede revelar que
fueron alterados.
 La detección de un ataque puede ser un trabajo para Sherlock Holmes que es un lugar
ideal para utilizar una herramienta de monitorización de seguridad.
CABALLO DE TROYA, VIRUS Y GUSANOS
 
La forma más desagradable de ataque se produce cuando el saltante modifica la
máquina sustituyendo algunas piezas claves del software por copias corruptas que
permiten el acceso del mismo. Esto solo ocurre cuando se ha advertido a los asaltantes
que fueron detectados y puede ser muy difícil de detectar, para ello se podrían utilizar
procedimientos rutinarios de copias de seguridad y así copiar el programa corrupto en
un archivo, luego al reconstruir el sistema como defensa, la tendencia será la de
restaurar la copia de seguridad en vez de volver a cargar el sistema desde el principio.
Generalmente eso solo restaura el programa corrupto y una vez más ayuda al asaltante a
entrenarse.
Cuando se sospecha un ataque los datos de copias de seguridad no pueden ser fiables
y debe tenerse cuidado al restaurar ese material. Es bueno hacer copias de seguridad
sólo de los datos del usuario y no del software del sistema cuando se vuelve a cargar el
sistema se debería utilizar el original, el adquirido con la máquina.
Los virus y gusanos trabajan con los mismos objetivos que los piratas pero pueden
extender e infectar a otras máquinas sin la acción directa del asaltante.
El virus es un programa que se pega así mismo a una pieza existente de software,
mientras que un gusano es un programa autónomo que sobrevive debido a la naturaleza
multitarea del sistema lo que generalmente los activa, es la ejecución de un programa
infectado o el montaje de un disco infectado lo que puede producir daños inmediato
pero generalmente el virus espera cierto período de tiempo mientras infecta a más
disquettes o a la LAN, luego de alguna fecha determinada se despertará y destruirá el
sistema anfitrión. Esas fechas pueden ser extremadamente difíciles de detectar y reparar,
la mejor defensa es impedirlas siendo muy precavido con las conexiones a otras
máquinas y con el software que cargue.

LOS UNIX SEGUROS

 
El departamento de defensa estadounidense (DOD) ha realizado una recopilación
conocida con el nombre de Orange Boock, del que se definen siete niveles de seguridad
organizados en cuatro clases.
Los sistemas de la clase A deben responder a criterios respecto no solo al sistema
operativo, sino también a la arquitectura material de la máquina. Se trata de ordenadores
diseñados a medida para las necesidades militares.
La clase B1 impone un sistema de protección jerárquico en el que cada objeto se
etiqueta, como "no clasificado", "difusión restringida", "confidencial", y "secreto de
defensa". Los usuarios pertenecen a categorías que tienen acceso a cierto nivel de
confidencialidad.
Las clases B2 (protección estructurada), y B3 (protección por ámbitos de seguridad)
son extensiones de la clase B1.
La clase C1 (protección direccional) impone al sistema operativo la protección de los
datos de los usuarios (definición de un espacio de usuario), y controlar su acceso
(palabra clave).
Clase C2 refuerza el control de acceso a la información: por ejemplo cada usuario
tiene un perfil en el sistema. Este debe conservar un rastro de los accesos mediante un
sistema auditor: acceso a los ficheros, intentos no autorizados, etc. Además todo rastro
residual de un proceso o de un usuario (áreas de memoria, ficheros temporales,...) deben
borrarse tras su finalización.
 
 
 
CONCLUSIÓN
 
El sistema UNIX es ahora tan bueno como la mayoría de los sistemas
operativos. Las versiones de SVR4 han sido certificada en los niveles de seguridad B2 y
B3 del departamento de defensa de los Estados Unidos.
Las cuestiones de seguridad son muy complejas, debido a la existencia de los
subsistemas.
Todo debe estar correctamente ajustado para lograr una seguridad óptima. Se
pueden adoptar pasos para impedir el acceso no autorizado.
Con el paso del tiempo, la tendencia natural de un sistema operativo complejo es
la disminución de la seguridad, por ello hay que estar constantemente alerta para
detectar agujeros en la seguridad y defender rápidamente el sistema.
UNIX dispone de:
Muchos modos para que los usuarios accedan al sistema, herramientas para la
comunicación entre máquinas y usuarios diferentes. Actualmente hay razones para que
persona no autorizadas irrumpan en el sistema computador (ej. Robo comercial de
datos, etc.)
Lo importante es tratar de equilibrar la facilidad de acceso para los “amigos” y la
prevención de acceso para los “enemigos”