#LyX 1.3 created this file. For more info see http://www.lyx.org/ \lyxformat 221 \textclass article \language spanish \inputencoding latin1 \fontscheme default \graphics default \paperfontsize default \spacing single \papersize letterpaper \paperpackage a4 \use_geometry 0 \use_amsmath 0 \use_natbib 0 \use_numerical_citations 0 \paperorientation portrait \secnumdepth 3 \tocdepth 3 \paragraph_separation indent \defskip medskip \quotes_language english \quotes_times 2 \papercolumns 1 \papersides 1 \paperpagestyle default \layout Title Evolución de los esquemas de seguridad extendidos en Unix \layout Author Gunnar Eyal Wolf Iszaevich \newline gwolf@gwolf.org \newline UNAM FES Iztacala \newline Departamento de Seguridad en Cómputo (DGSCA--UNAM) \newline \newline Congreso Nacional de Software Libre CONSOL 2003 \layout Date 7 de febrero, 2003 \layout Abstract Los sistemas Unix son descendientes del proyecto Multics, un sistema con magníficas ideas pero demasiado complejo para su época. Unix fue en un principio tan sólo una simplificación de Multics, y esto fue lo que lo hizo tan exitoso. \layout Abstract La seguridad en un sistema Unix tradicional está completamente basada en la separación entre \emph on kernel \emph default y \emph on userland \emph default , y en los tradicionales permisos \family typewriter rwxrwxrwx \family default . \layout Abstract Sin embargo, con el paso de los años fue haciéndose necesario ampliar este esquema para cubrir las necesidades actuales del mundo real. \layout Abstract En esta plática cubriré: \layout Abstract - Los esquemas de MAC (Mandatory Access Control) existentes en diferentes Unixes (Trusted-*) \layout Abstract - Las capacidades POSIX 1003.1e, su implementación en Linux \layout Abstract - Systrace, sus implementaciones en BSD y en Linux \layout Abstract - Ventajas/desventajas de estos métodos \layout Abstract \begin_inset ERT status Collapsed \layout Standard \backslash eject \end_inset \layout Standard \begin_inset LatexCommand \tableofcontents{} \end_inset \layout Standard \begin_inset ERT status Collapsed \layout Standard \backslash eject \end_inset \layout Section Esquemas de seguridad -- ¿Qué? ¿Para qué? \layout Standard Parte esencial al conocer o comparar cualquier sistema operativo hoy en día debe ser el esquema de seguridad que nos ofrece. Ya sea para sistemas diseñados como servidores o como clientes, conectados o no conectados a red, hoy en día vemos que casi la totalidad de los sistemas operativos manejan a algún grado, aún en el mundo de las PDAs, los conceptos de multitarea, redes y usuarios. \layout Standard En este texto estudiaremos los esquemas de seguridad implementados por la familia de sistemas operativos probablemente más longeva y exitosa de la historia, los Unixes, así como las nuevas direcciones que nos marcan los recientes desarrollos en los sistemas Unix libres. \layout Section Modelo de Multics \layout Standard El primer esquema que analizaremos es el implementado por Multics, el cual pese a tener ya cerca de 40 años de existencia aún es tomado como referencia para diseño de nuevos esquemas. \layout Subsection \begin_inset LatexCommand \label{sub:¿Qué-es-Multics} \end_inset ¿Qué es Multics? ¿Por qué iniciamos con él? \layout Standard El diseño de Multics ( \emph on Multiplexed Information and Computing Service \emph default ) fue descrito en 1965 \begin_inset LatexCommand \cite{Multics introduction and overview} \end_inset y desarrollado desde entonces y hasta 1973. En su momento fue un sistema operativo muy revolucionario y ambicioso -- Planteaba soportar brindar servicios de cómputo como se brindan los servicios telefónico o eléctrico: Los subscriptores tendrían una toma a través de la cual conectarían su terminal al sistema central. Esto exigía un sistema que hoy sería catalogado como \emph on de alta disponibilidad \emph default a todo nivel, y con muy altos estándares de seguridad. Es uno de los primeros sistemas que expresamente buscaba dar soporte a múltiples ambientes de programación e interfaces al usuario, un amplio rango de aplicaciones, y tener la habilidad de evolucionar conforme cambie la tecnología. Multics fue también uno de los primeros sistemas operativos escrito en un lenguaje de alto nivel (en PL/1 \begin_inset LatexCommand \cite{Multics PL/1} \end_inset ), pensando en permitir una gran portabilidad y facilidad en la depuración. \layout Standard El basar el sistema en PL/1 fue, además, una muy acertada decisión. En más de treinta años prácticamente no se detectaron \emph on buffer overflow \emph default s en Multics, uno de los mayores dolores de cabeza de los programadores de C, dado que PL/1 maneja nativamente los límites máximos de las cadenas. \layout Standard Las ambiciones de Multics fueron, sin embargo, demasiado elevadas para la época. El sistema operativo tardó mucho en estar listo. Era ridículamente grande y lento para las capacidades de memoria y procesamient o aún de las computadoras más grandes de su época. Esto hizo que varias de las empresas que inicialmente lo impulsaron abandonaran su desarrollo. Una de estas fue Bell Labs -- Tras abandonar el proyecto Multics, pero partiendo de varias interesantes ideas que éste planteó por primera vez, sus hoy famosos empleados Kernighan, Thompson y Ritchie se avocaron al diseño de un Multics recortado, llamado --como broma-- UNICS y posteriormente Unix, y un lenguaje de relativamente alto nivel, el actual C. \layout Standard Pese a las demoras en su desarrollo, Multics sí fue un sistema exitoso. Hubo una buena cantidad de sistemas corriendo Multics, el último de los cuales fue \emph on jubilado \emph default en el 2000 en el ejército canadiense. El primer sistema en obtener la clasificación A1 del Departamento de Defensa de los EUA \begin_inset LatexCommand \cite{DOD 5200.28-STD} \end_inset ---cosa que definitivamente no ocurre todos los días--- fue SCOMP, un desarroll o basado en Multics. Multics mismo, en 1985, recibió la certificación B2. Hay actualmente varios proyectos de construir emuladores de Multics \begin_inset LatexCommand \cite{simtics} \end_inset . Emuladores, sí, no adecuaciones, pues Multics requiere características de hardware no presentes en las computadoras actuales. \layout Standard Resulta ya obvio que la influencia de Multics es de grandísima importancia e innegable. Mencionaremos brevemente sus principales características de seguridad. Para quien busque información más a detalle respecto a Multics, recomiendo fuertemente el sitio multicians.org \begin_inset LatexCommand \cite{multicians.org,Multics FAQ,Multics features,Multics hist} \end_inset . \layout Subsection Un sistema de anillos \layout Standard La seguridad en Multics parte de un diseño conceptualmente conformado de ocho \emph on anillos concéntricos \emph default de privilegio, implementados en hardware (que, por software, podían dar la ilusión de ser en realidad 64 anillos). Entre más cerca del centro (0) está un anillo, mayores privilegios tiene. Los procesos que requieren privilegios de sistema por regla general corren en el anillo 2 o inferiores, las bibliotecas compartidas en anillo 3, y los programas de usuario en anillos superiores. \layout Standard Buena parte de esto está implementado desde hardware, lo cual hace que explotar la seguridad del sistema sea mucho más difícil que en sistemas como los actuales, en los que prácticamente todos los mecanismos de seguridad ---a excepción de los más básicos para sistemas multitarea, como la separación de segmentos de memoria--- están implementados en el sistema operativo. \layout Subsection \begin_inset LatexCommand \label{sub:ACLs-completos} \end_inset ACLs completos \layout Standard Con el nombre ACL nos referimos genéricamente a las listas de control de acceso --- La lista de quién tiene derecho de hacer qué con cada objeto en el sistema. Probablemente el primer sistema en incluir verdaderas listas de control de acceso fue Multics. \layout Standard Un ACL en Multics puede verse así: \layout Quotation \family typewriter rew VanVleck.SysAdmin.a r Backup.SysDaemon.z rw *.SysAdmin.* \layout Standard Este ACL tiene tres entdadas, cada una de ellas especificando permisos, el juego de usuarios al que se aplican estos permisos \begin_inset Foot collapsed true \layout Standard Además de los permisos para archivos ( \family typewriter rew \family default , lectura, ejecución y escritura) están definidos los permisos para directorio ( \family typewriter sma \family default , status, modificación, agregar). Al reimplementar la idea en Unix, se estandarizó en \family typewriter rwx \family default (lectura, escritura y ejecución) para todo objeto, considerando al directorio como un tipo especial de archivo. \end_inset , y las instancias de estos usuarios. Los ACLs se construyen del elemento más específico hacia el más general, y la primer ocurrencia encontrada es la que determina acceso, con una política de denegación por default. En este caso, indica que el usuario VanVleck en el rol o instancia SysAdmin tienen derecho de lectura, escritura y ejecución ( \family typewriter rew \family default ) cuando fueron autenticados en una sesión interactiva ( \family typewriter a \family default ), el usuario Backup en la instancia SysDaemon tienen lectura cuando son demonios ( \family typewriter z \family default ), y culaquier usuario en el rol de SysAdmin con cualquier forma de autenticació n tiene lectura y escritura. \layout Standard Los ACLs de Multics son muy eficientes comparados con muchos desarrollados posteriormente, incluso los de Posix y los de Windows NT, por la simplicidad del esquema y la ausencia de líneas de negación. \layout Standard El que Multics haya logrado una certificación B2 es, en buena parte, consecuenci a de su diseño de ACLs. \layout Section Unix clásico \layout Standard Como mencionamos en \begin_inset LatexCommand \ref{sub:¿Qué-es-Multics} \end_inset , Unix puede considerarse hijo directo de Multics. Analicemos ahora pues el esquema de seguridad existente en los sistemas Unix y derivados. \layout Subsection Espacios e interfaces \layout Standard El sistema de anillos de Unics fue simplificado reduciéndolo a únicamente dos modos: El espacio de kernel y el espacio de usuario. \layout Subsubsection Espacio de kernel \layout Standard El código que se ejecuta en espacio de kernel no tiene restricción alguna en el sistema: Tiene acceso directo a todo el hardware, puede realizar cualquier operación sin acudir a las capas de abstracción que el kernel ofrece (y de hecho, es justamente su función --- Por ejemplo, los módulos que permiten al kernel entender diferentes sistemas de archivos y ofrecer a los programas usuario un modelo abstracto uniforme se ejecutan en espacio de kernel). El código que se ejecuta en espacio de kernel, además, tiene acceso a toda la memoria de la computadora, es capaz de manipular la tabla de procesos e inclusive de modificar datos de los diferentes procesos. En la mayoría de los sistemas Unix, hay únicamente un proceso corriendo en espacio de kernel --- Precisamente, el kernel. Varias implementaciones de Unix \begin_inset Foot collapsed false \layout Standard Como NeXTstep/OpenStep, Darwin, Minix, y varios más \end_inset \layout Comment Mencionar algunos sistemas microkernel, ligas \layout Standard , tienen una implementación de \emph on microkernel \emph default , lo que significa que el kernel incluye únicamente una fracción del código privilegiado, y las demás facilidades de bajo nivel (por ejemplo, manejo de memoria, manejo de sistemas de archivos, manejo de red) son implementadas por procesos privilegiados adicionales. Esto nos da una mucho mayor separación funcional, lo que lleva a una mayor limpieza en el código, e incluso a veces nos permite substituir el código en ejecución para funciones fundamentales del sistema, pero al mismo tiempo lleva a una implementación más compleja, que tiende a ser más lenta. \layout Subsubsection Espacio de usuario \layout Standard Todos los programas a excepción del kernel y ---en su caso--- estos programas privilegiados adicionales trabajan en espacio de usuario. Esto significa que tienen ciertas restricciones, entre ellas: \layout Itemize No pueden utilizar directamente ningún dispositivo \layout Itemize No pueden leer espacios de memoria que pertenezcan a otro proceso y no estén explícitamente marcados como memoria compartida \layout Itemize No pueden tocar ninguna de las tablas internas del kernel (de procesos, de asignación de memoria, etc.) \layout Standard Para llevar a cabo cualquiera de estas acciones tienen que solicitarlo al kernel. \layout Subsubsection Llamadas al sistema \layout Standard Cuando un programa no privilegiado requiere efectuar una operación para la cual no tiene privilegios, hace una llamada al sistema. Esta es básicamente como una llamada a cualquier función proporcionada por la biblioteca estándar de C, con la única particularidad que el encargado de atenderla no será el mismo proceso, sino que el kernel. \layout Standard Cuando estamos depurando un programa, nos puede ser de gran utilidad emplear el comando \family typewriter strace \family default en Linux \begin_inset LatexCommand \cite{strace (1)} \end_inset , \family typewriter ktrace \family default y \family typewriter kdump \family default en los sistemas BSD, y \family typewriter truss \family default en Solaris y en otros Unixes. Este comando nos muestra cada llamada al sistema efectuada por el programa en cuestión. Como puede observarse tras correr este comando, hay una gran cantidad de llamadas al sistema, las cuales pueden ser clasificadas en diferentes categoría s (archivos, procesos, red, señales, IPC). \layout Comment * Title: "Linux Kernel Module Programming Guide" \layout Comment Author: Ori Pomerantz. \layout Comment URL: http://www.tldp.org/LDP/lkmpg/mpg.html \layout Comment Keywords: modules, GPL book, /proc, ioctls, system calls, interrupt handlers . \layout Comment Description: Very nice 92 pages GPL book on the topic of modules programming. Lots of examples. \layout Subsection Permisos de uso \layout Standard Ahora bien, ¿cómo puede determinar el kernel si un proceso determinado tiene derecho de llevar a cabo una determinada llamada al sistema? Para la mayor parte de ellos \layout Standard En Unix tenemos definido un sistema simple y efectivo de permisos para cada objeto existente en nuestro árbol de directorio. Al solicitar una operación sobre de él, el kernel verifica si el usuario bajo el cual está corriendo dicho proceso, o alguno de los grupos a los que pertenece, tiene derecho de llevar a cabo la operación indicada sobre el objeto. Para esto, cada objeto tiene definido un usuario dueño y un grupo, y permisos de lectura, escritura y ejecución. Este simple esquema típicamente lo vemos representado como los tres juegos de \family typewriter rwx \family default --- Permiso de lectura, escritura y ejecución para usuario, grupo y resto del mundo. \layout Standard Para comunicación simple entre procesos, y para que el kernel notifique a los procesos de determinados eventos, contamos con diferentes señales predefinidas (ver \begin_inset LatexCommand \cite{signal(7)} \end_inset ), algunas de ellas \emph on atrapables \emph default (esto es, que el proceso puede tener una rutina diseñada para atender a esta señal, y en el caso de no existir dicha rutina, el sistema operativo utilizará un comportamiento predefinido dependiendo de la señal), algunas de ellas no (el proceso no puede decidir qué hacer con ella - el sistema operativo es quien lo decide y lo impone). Las reglas de comunicación por señales mandan que un proceso sólo puede mandar un proceso a otro si el proceso que envía la señal corre como root, o si ambos procesos tienen el mismo UID real o efectivo (ver \begin_inset LatexCommand \cite{kill(2)} \end_inset ). \layout Standard Respecto a la comunicación en red, la restricción es básicamente que ningún usuario que no sea root puede abrir un socket TCP o UDP por puertos menores al 1024, y que sólo root puede enviar paquetes \emph on crudos \emph default (que no fueron procesados de la manera estándar por la pila). \layout Subsubsection Uso de dispositivos \layout Standard Una computadora tiene una gran cantidad de dispositivos de muy diferentes tipos. En Unix se hace una muy práctica abstracción, al afirmar que \emph on todo es un archivo \emph default . Todos los dispositivos tienen una entrada en el árbol de directorio del sistema, que por medio de un inodo especial (de caracteres o de bloques) apunta al manejador indicado en el kernel. \layout Standard Los dispositivos por bloques (por ejemplo, los discos) nos permiten acceso aleatorio, transfiriendo bloques de longitud fija (típicamente 512 bytes). Los dispositivos por caracteres (por ejemplo, un puerto serial) están más bien orientados a un flujo de datos, permitiéndonos transferencias de caractere s individuales, pero con forma de acceso secuencial, sin proporcionarnos la posibilidad de retroceder o adelantar nuestra posición. \layout Standard Los inodos que describen a un dispositivo lo hacen por medio de dos números, el mayor y el menor. Con ellos indican al kernel qué manejador utilizar para este dispositivo y con qué parámetros. Estos inodos llevan el mismo sistema de permisos que cualquier otro archivo del sistema. \layout Subsection El superusuario \layout Standard En Unix todo está regulado por los permisos que tiene cada usuario. Hay un usuario especial en cada sistema: \emph on root \emph default , o el superusuario. Para el superusuario, los permisos de cualquier archivo siempre le permitirán lectura, escritura y ejecución --- Esto significa que el superusuario puede hacer cualquier cosa en el sistema, nada le será negado. \layout Subsection La problemática con el esquema tradicional de Unix \layout Standard Si bien para muchas aplicaciones el esquema de Unix es adecuado, dista mucho de ser perfecto. El tener un usuario capaz de \emph on absolutamente \emph default todo, el tener a un administrador con capacidad de leer, eliminar o modificar cualquier dato en el sistema hacen que un sistema Unix no sea suficiente para ciertas aplicaciones donde hacen falta garantías de confidencialidad e integridad --- En muchos casos, aplicaciones gubernamentales o militares \begin_inset Foot collapsed true \layout Standard Cabe mencionar que con la aparición de sistemas de criptografía fuerte, como GnuPG, cada usuario puede tener garantía de la confidencialidad e inetgridad de su información. El uso de sistemas de criptografía, sin embargo, requiere de intervención manual, y no puede ser considerado parte integral del sistema operativo. \end_inset . \layout Standard Yéndonos un poco hacia la terminología técnica, el problema es que el sistema de permisos en Unix está basado en DAC ( \emph on control de acceso discrecional \emph default ), del cual el administrador está exento, mientras que muchas aplicaciones del mundo real nos demandan MAC ( \emph on control de acceso mandatorio \emph default u \emph on obligatorio \emph default , \begin_inset LatexCommand \ref{sub:Control-de-acceso} \end_inset ). \layout Standard En muchos casos es también necesaria la separación de roles de administración --- Tener un administrador diferente para los diferentes servicios, manteniendo la auditabilidad de cambios \begin_inset Foot collapsed true \layout Standard Esto, nuevamente, es implementable a través de programas adicionales que han sido desarrollados a lo largo de los años de existencia de Unix, pero tomó en algunos casos varias décadas encontrar los mecanismos adecuados. \end_inset . \layout Standard Estas limitaciones, ciertamente, son comprensibles si recordamos que Unix no es sino una simplificación de Multics. Sin embargo, dada la popularidad que con el paso de los años adquirió Unix, fue haciéndose necesario encontrar cómo paliar estas carencias. \layout Section Sistemas confiables ( \emph on Trusted-* \emph default ) \layout Standard En 1987, el National Computer Security Center de los Estados Unidos comisionó al grupo Trusted Unix Working Group (Trustix) para emitir una serie de recomendaciones que elevaran la seguridad en los sistemas Unix ( \begin_inset LatexCommand \cite{trustix} \end_inset ). Varios sistemas operativos han implementado estas recomendaciones (junto con varias más, como niveles de confidencialidad y roles de usuarios), aunque siempre tienen que mantenerse como una rama del sistema especializada y aparte, dadas las diferencias que estas recomendaciones implican para usuarios, administradores y desarrolladores --- Los sistemas que implementan esto dejan de ser estrictamente Unixes para convertirse en sistemas basados en Unix. Los más conocidos en esta categoría son Trusted Solaris y Trusted DG/UX. \layout Subsection Trusted Solaris \layout Standard Si bien el foco de nuestra atención son los sistemas operativos libres, vale la pena hacer un análisis breve de lo que provee Trusted Solaris \begin_inset LatexCommand \cite{trusted_solaris-features-benefits} \end_inset , probablemente el sistema confiable más difundido y con mayor historia. \layout Standard Trusted Solaris implementa muchas características enfocadas a permitir un control granular de permisos y a proveer un registro completo de eventos \begin_inset LatexCommand \cite{trusted_solaris-oper-env} \end_inset . La primer gran diferencia que brinca a la vista al utilizar TrustedBSD es que ya no existe una cuenta de superusuario ( \family typewriter root \family default ) \begin_inset LatexCommand \cite{trusted_solaris-root} \end_inset . La administración se realiza a través de diferentes usuarios con roles administrativos, y hay mecanismos de registro de sucesos que hacen tan rastreables las actividades de un administrador como las de cualquier otro usuario. Además, a diferencia de los Unixes estándar, para entrar con un rol administrat ivo al sistema es indispensable registrarse primero como usuario, y posteriormen te desde su cuenta asumir un rol administrativo. Este proceso, además de corregir malas prácticas de administración, permite rastrear a un usuario cualquier mal uso de las funciones de administración. \layout Standard Los objetos del sistema de archivos, aparte de tener información y mecanismos para llevar a cabo MAC, tienen \emph on etiquetas \emph default asociadas describiendo su nivel de sensibilidad --- Un archivo puede estar marcado como \emph on confidencial \emph default , \emph on público \emph default , etc. Estas, además de ser informativas y ser desplegadas notoriamente en cada ventana en que se trabaje, permiten definir relaciones y colaborativas jerárquicas entre usuarios. \layout Standard Pese a las grandes diferencias que estos puntos suponen, el entorno general sigue teniendo un fuerte \emph on sabor \emph default a Unix. Según la documentación de Sun, cualquier administrador familiarizado con Solaris podrá administrar Trusted Solaris sin mucho problema. \layout Standard También para los usuarios hay también fuertes diferencias en la operación del sistema. En todo momento, el usuario ve en pantalla en el entorno CDE información respecto al nivel de sensibilidad de la información que está trabajando. Para mayor información acerca del uso diario de Trusted Solaris, sugiero referirse a \begin_inset LatexCommand \cite{trusted_solaris-user-guide} \end_inset . \layout Subsection \begin_inset LatexCommand \label{sub:TrustedBSD} \end_inset TrustedBSD \layout Standard El proyecto TrustedBSD \begin_inset LatexCommand \cite{trustedbsd} \end_inset implementó buena parte de las recomendaciones de Trustix, así como varias extensiones adicionales \begin_inset LatexCommand \cite{trustedbsd-components} \end_inset , de manera mucho menos intrusiva sobre un sistema FreeBSD. La recientemente liberada versión 5.0 de FreeBSD incorpora ya buena parte del código desarrollado por éste proyecto \begin_inset LatexCommand \cite{trustedbsd-dn} \end_inset , y, aunque en menor grado, también OpenBSD y Darwin han importado subsistemas importantes. \layout Comment Confirmar esto... \layout Standard Los principales subsistemas desarrollados por TrustedBSD son: \layout Subsubsection Listas de control de acceso (ACLs) \layout Standard Como mencionamos en \begin_inset LatexCommand \ref{sub:ACLs-completos} \end_inset , las listas de control de acceso nos permiten un control mucho más granular de qué usuarios o grupos gozan de qué privilegios de acceso a cada objeto en el sistema. \layout Subsubsection Eventos auditables \layout Standard Para que un sistema sea considerado confiable, es fundamental tener la posibilid ad de analizar las bitácoras y determinar inequívocamente cuál fue la causa de los eventos registrados. \layout Subsubsection Atributos extendidos \layout Standard El manejo de atributos extendidos permiten asociar a cada archivo la \emph on metainformación \emph default que el usuario o el administrador juzguen importante para las diferentes extensiones de módulos de seguridad que existan (u otros fines cualquiera). Por ejemplo, la información de ACLs y de MACs es guardada ya de esta manera, y la información de las capacidades también lo será una vez que su desarrollo llegue a un nivel adecuado de estabilidad. \layout Subsubsection Capacidades granulares \layout Standard TrustedBSD implementa un subconjunto de las capacidades que veremos en la sección \begin_inset LatexCommand \ref{sec:Capacidades-POSIX-1003.1e} \end_inset . \layout Subsubsection \begin_inset LatexCommand \label{sub:Control-de-acceso} \end_inset Control de acceso mandatorio (MAC) \layout Standard Es fundamental para considerar a un sistema seguro el no tener usuarios todopoderosos. A diferencia de los sistemas Unix estándar, que nos proporcionan control de acceso discrecional (DAC), esto permitirá restringir a las operaciones efectuadas aún por superusuarios. \layout Standard Además de esto, es importante poder controlar el acceso que tienen procesos u otros objetos a determinados recursos del sistema --- por ejemplo, uso de sockets de red, nodos de sysctl \begin_inset Foot collapsed true \layout Standard La interfaz estándar en Unix a las banderas del kernel en ejecución. En Linux, el pseudosistema de archivos /proc es en buena medida una implementac ión de llamadas a sysctl. \end_inset , objetos del sistema de archivos, etc. \layout Section \begin_inset LatexCommand \label{sec:Capacidades-POSIX-1003.1e} \end_inset Capacidades POSIX.1e \layout Standard Buscando estandarizar las diferentes respuestas a las limitaciones en materia de seguridad de las diferentes implementaciones de Unix, el grupo POSIX inició a mediados de los 80s a definir el estándar POSIX.1e. Otros nombres por los cuales este estándar es conocido son IEEE 1003.1e, P1003.1e y POSIX6. \layout Comment Fecha exacta de inicio de 1003.1e \layout Subsection ¿Qué es el estándar POSIX.1e? \layout Standard El trabajo sobre este estándar parte de que es muy importante tener definido un consenso respecto a las implementaciones de seguridad entre los diferentes sistemas operativos, puesto que sólo así los desarrolladores se verán motivados a utilizarlas, aprovechando sus ventajas sin perder portabilidad. POSIX.1e busca corregir varias situaciones no deseables en los sistemas Unix tradicionales, notablemente el agregar ACLs y el poder asignar privilegios o limitaciones específicas no sólo a la relación de objetos en el sistema de archivos contra usuarios, sino que a cada proceso de manera independiente, limitando la cantidad de acciones que requieren asumir la identidad de root o de algún otro usuario, y limitando el daño que puede causar un atacante una vez que comprometió a un proceso \begin_inset LatexCommand \cite{Posix summary} \end_inset . \layout Standard Hay otro estándar relacionado con POSIX.1e --- POSIX.2c. Mientras que el primero busca definir las interfaces de seguridad para sistemas abiertos para ACLs, separación de privilegios, control de acceso mandatorio y mecanismos de etiquetas de metainformación, POSIX.2c busca definir utilidades de seguridad para implementar lo definido por POSIX.1e. \layout Subsubsection Su estado actual \layout Standard Tristemente, en 1999 POSIX decidió retirar la propuesta de este estándar, por lo cual POSIX.1e nunca será un estándar aprobado. Las razones para retirar el trabajo sobre este estándar fueron principalmente \begin_inset LatexCommand \cite{Security extensions to Posix} \end_inset : \layout Paragraph Falta de consenso por prácticas divergentes \layout Standard Durante la etapa de desarrollo de este estándar, diferentes grupos de desarrollo implementaron las características que estaban a discusión. Cada grupo, claro, lo hizo de manera independiente y descoordinada, lo cual llevó a interfaces completamente diferentes, con grupos de usuarios con mayor interés en que no cambie lo ya establecido que en estandarizarse. \layout Paragraph Falta de implementaciones \layout Standard Algunos elementos en el estándar sufrieron de lo opuesto: Nunca fueron implement ados, y de la manera en que estaban siendo descritos, simplemente no eran implementables --- El estándar cubría una interfaz ideal teórica, alejada por completo de cualquier desarrollo similar, alejada de las necesidades reales. \layout Paragraph Cambios en las necesidades \layout Standard El mundo del cómputo avanza a muy gran velocidad. Cuando el trabajo en este estándar inició, la guía principal para juzgar un sistema como seguro eran los criterios de TCSEC (Trusted Computer Security Evaluation Criteria) \layout Comment Liga/referencia de TCSEC \layout Standard . El mundo ha ido evolucionando rápidamente, y estos criterios simplemente ya no son válidos hoy en día. \layout Comment http://www.guug.de/~winni/posix.1e/download.html --- Revisar validez, agregar a bibliografía. \layout Subsection Implementaciones existentes de las capacidades POSIX.1e \layout Standard Dentro del mundo del software propietario, podemos hablar básicamente de la implementación de los ACLs en Solaris y de los mecanismos de seguridad presentes en Irix 6.5. \layout Comment Revisar bibliografía respecto Irix: http://www.geek-girl.com/bugtraq/1999_1/0424.ht ml \layout Standard En el mundo del software libre, ha habido bastante más avance hacia la implement ación de las porciones más relevantes de este estándar. \layout Standard El proyecto FreeBSD reporta avance en la implementación de las extensiones de auditoría, MAC, ACLs y atributos extendidos desde marzo de 1999 y hasta abril del 2000 \begin_inset LatexCommand \cite{Posix-FreeBSD} \end_inset . Para estructurar mejor el foco de trabajo y desarrollo del sistema y facilitar compartir el código con los otros proyectos BSD, a partir de esa fecha el desarrollo en esta materia fue delegado al grupo de trabajo del proyecto TrustedBSD \begin_inset LatexCommand \cite{trustedbsd} \end_inset . \layout Subsubsection Las capacidades POSIX en Linux \layout Standard En Linux ha habido también un muy interesante trabajo para la implementación de las capacidades granulares POSIX \begin_inset LatexCommand \cite{Posix linux faq} \end_inset . La mayor parte de este esfuerzo se ha centrado en las capacidades POSIX. Esta es una implementación de granularización de privilegios, nuevamente haciendo menos necesario el uso de la cuenta de superusuario. Para este modelo, cada proceso tiene tres juegos de banderas, o \emph on bitmaps \emph default : Capacidades heredables ( \emph on inheritable \emph default , \emph on I \emph default ), permitidas ( \emph on permitted \emph default , \emph on P \emph default ) y efectivas ( \emph on effective \emph default , \emph on E \emph default ). Cuando un proceso intenta llevar a cabo una operación que requiere privilegios, el sistema operativo revisa en el bitmap E, en vez de verificar, como tradicion almente se hace, que el UID efectivo del proceso sea 0. \layout Standard Un proceso puede tener capacidades declaradas como permitidas sin que estas sean efectivas. Esto es porque los procesos pueden desactivar temporalmente alguna de sus capacidades, para disminuir los riesgos en caso de ataque. Este proceso puede solicitar nuevamente al kernel que le asigne las capacidades inactivas únicamente si estas figuran en el bitmap P. El bitmap I son las capacidades que heredará un nuevo proceso que éste invoca a través de la llamada \family typewriter exec \family default \begin_inset Foot collapsed true \layout Standard No así con las llamadas \family typewriter fork \family default o \family typewriter clone \family default --- En estas, el proceso hijo es una copia exacta del proceso padre. \end_inset . \layout Standard En Linux, no sólo los procesos pueden tener definidas capacidades. También los archivos --- aunque para evitar confusiones, a estos tres mismos bitmaps se les llama permitidos ( \emph on allowed \emph default , \emph on A \emph default ), forzados ( \emph on forced \emph default , \emph on F \emph default ) y efectivo ( \emph on effective \emph default , \emph on E \emph default ). El bitmap A indica qué capacidades puede heredar del bitmap I del proceso que lo invoque un ejecutable a través de un \family typewriter exec \family default . El bitmap F indica las capacidades que los procesos creados a partir de este ejecutable \emph on siempre \emph default recibirán, independientemente de lo que indique el proceso que lo llame --- un tanto al estilo del SUID en Unix. Por último, el bitmap E indica cuáles bits del bitmap del proceso nuevo deben ser heredados a procesos hijos suyos. Todos los bits de este último bitmap serán sólo 1 cuando el programa no está diseñado pensando en capacidades, o sólo 0 cuando sí implemente control interno de capacidades, y por ello puede ser implementado utilizando un solo bit en el sistema de archivos. El bitmap E que será asignado a un nuevo proceso al iniciar su ejecución es: \layout Quotation P = F | (A & I) \layout Standard Lo cual nos indica que hay que ser \emph on muy \emph default cuidadosos al activar bits en el bitmap F --- Este, repito, es el equivalente granular del SUID de Unix, y hay que tratarlo con el mismo cuidado.. \layout Standard Hay 29 capacidades definidas en el kernel de Linux, a la versión 2.4.20. Para mayor detalle, sugiero consultar \begin_inset LatexCommand \cite{capacidades en 2.4.20} \end_inset . Estas son: \layout Itemize \family typewriter CAP_CHOWN \layout Itemize \family typewriter CAP_DAC_OVERRIDE \layout Itemize \family typewriter CAP_DAC_READ_SEARCH \layout Itemize \family typewriter CAP_FOWNER \layout Itemize \family typewriter CAP_FSETID \layout Itemize \family typewriter CAP_FS_MASK \layout Itemize \family typewriter CAP_KILL \layout Itemize \family typewriter CAP_SETGID \layout Itemize \family typewriter CAP_SETUID \layout Itemize \family typewriter CAP_SETPCAP \layout Itemize \family typewriter CAP_LINUX_IMMUTABLE \layout Itemize \family typewriter CAP_NET_BIND_SERVICE \layout Itemize \family typewriter CAP_NET_BROADCAST \layout Itemize \family typewriter CAP_NET_ADMIN \layout Itemize \family typewriter CAP_NET_RAW \layout Itemize \family typewriter CAP_IPC_LOCK \layout Itemize \family typewriter CAP_IPC_OWNER \layout Itemize \family typewriter CAP_SYS_MODULE \layout Itemize \family typewriter CAP_SYS_RAWIO \layout Itemize \family typewriter CAP_SYS_CHROOT \layout Itemize \family typewriter CAP_SYS_PTRACE \layout Itemize \family typewriter CAP_SYS_PACCT \layout Itemize \family typewriter CAP_SYS_ADMIN \layout Itemize \family typewriter CAP_SYS_BOOT \layout Itemize \family typewriter CAP_SYS_NICE \layout Itemize \family typewriter CAP_SYS_RESOURCE \layout Itemize \family typewriter CAP_SYS_TIME \layout Itemize \family typewriter CAP_SYS_TTY_CONFIG \layout Itemize \family typewriter CAP_MKNOD \layout Itemize \family typewriter CAP_LEASES \layout Standard A través de la capacidad \family typewriter CAP_SETPCAP \family default , un proceso puede alterar (para agregar o para retirar capacidades) los bitmaps de otros procesos en ejecución en el sistema. Además de esto, utilizando el programa \family typewriter execcap \family default podemos ejecutar un programa especificándole un juego de capacidades: \layout Quotation \family typewriter execcap 'cap_sys_admin=eip' update \layout Standard ejecutará el programa \family typewriter update \family default con \family typewriter CAP_SYS_ADMIN \family default en sus tres bitmaps. \layout Comment ¿Y cómo lo activo? \layout Section Systrace \layout Standard Niels Provos, del equipo de desarrollo de OpenBSD, desarrolló y presento en el 2002 una interesante propuesta \begin_inset LatexCommand \cite{systrace-pdf} \end_inset : Un mecanismo, parcialmente implementado en el kernel y parcialmente en espacio de usuario, que permite dejar de depender en privilegios SUID/SGID y, en general, en los roles de un superusuario, y a la vez permite restringir el comportamiento de un programa para evitar que, de ser éste atacado, lleve a cabo operaciones no deseables, limitando las llamadas al sistema que puede ejecutar (e inclusive permitiendo especificar diferentes comportamien tos para llamadas con diferentes argumentos). Las tres metas principales de diseño de Systrace son controlar la escalación de privilegios a través de políticas, facilitar la detección de intrusos a nivel host, y aumentar las capacidades de monitoreo y auditoría de un sistema sin salir del esquema de un Unix genérico. Este mecanismo, llamado Systrace, permite confinamiento granular de procesos, detección de intrusos, auditoría y elevación de privilegios, y facilita el tedioso proceso de generación de políticas, al contar con un generador de políticas interactivo. Además de todo esto, systrace permite que cada usuario genere juegos de políticas para cada uno de los binarios del sistema sin intervención de root (y, claro, sin exceder sus propios privilegios). Además de todo esto, systrace es portable a otros sistemas operativos, y (a diferencia de otros sistemas similares) representa muy poca carga adicional al rendimiento del sistema --- Sin embargo, esto es aún un punto en el que está trabajando el equipo de desarrollo, pues sí hay un impacto sensible con ciertas llamadas al sistema relacionadas con el sistema de archivos. \layout Standard La decisión de implementar a systrace de manera híbrida, en espacio de kernel y en espacio de usuario, fue tomada pensando en eficiencia (el implementar en espacio de usuario hubiera hecho que para toda llamada al sistema hubiera una gran cantidad de cambios de contexto, haciendo sensiblemente más lenta la operación general), seguridad (al tener al monitor de privilegios como un proceso de usuario es mucho más fácil detenerlo, engañarlo o aprovechar la ventana de oportunidad entre la creación de un proceso y la asignación de sus privilegios --- Implementando en kernel, un proceso al ser creado ya tiene la política asignada, heredada de su proceso padre) y portabilidad (si todo fuera implementado en espacio de kernel, adecuar systrace para otros sistemas operativos hubiera básicamente consistido en reescribirlo). \layout Standard Claro está, systrace fue diseñado con la consigna de que fuera prácticamente inviolable. Algunas ideas ingeniosas fueron implementadas --- Por ejemplo, cuando un proceso hace una llamada al sistema, el kernel copia los argumentos de esta llamada, los verifica y ejecuta la llamada \emph on desde la copia \emph default , no desde el espacio original. Esto evita que los argumentos puedan ser modificados (por ejemplo, con un proceso que comparta memoria con el primero) después de solicitar autorizaci ón pero antes de ser realmente ejecutados. Esto permitió además simplificar varias acciones tradicionalmente complejas en los esquemas de ACLs y políticas implementados en otros sistemas --- Por ejemplo, el kernel reescribe los argumentos de las llamadas que involucran archivos, de modo que cuando verifica los privilegios sobre una liga simbólica, antes de continuar con la operación resuelve la liga, y trabaja ya directamente con el objeto real en el sistema de archivos. Otra aplicación de la reescritura de llamadas a función es para tener un mejor control sobre las aplicaciones que requieran tener acceso a red. \layout Standard La generación de políticas puede llevarse a cabo (ejecutando binarios que presuponemos confiables) ya sea de forma automática o manual. Si lo hacemos de forma automática, ejecutamos nuestra aplicación de todas las maneras que normalmente esperamoe que sea llamada, registrando las llamadas al sistema que ésta realiza y etiquetándolas como válidas, y una vez generada y activada la política, detectará cualquier uso fuera del patrón definido. Si lo hacemos de forma manual, cada llamada al sistema que el proceso realice será suspendida hasta que el usuario (a través de una aplicación independiente) marque a dicha llamada como válida o inválida, opcionalmente especificando ciertos parámetros. Además de esto, las políticas son definidas por medio de un lenguaje muy claro y simple, por lo que ajustarlas a mano es una labor bastante sencilla. \layout Standard Hay un proyecto muy interesante relacionado con Systrace llamado Hairy Eyeball \begin_inset LatexCommand \cite{Hairy Eyeball} \end_inset , que ha generado políticas estándar para ya 160 binarios, y probablemente el resultado del trabajo de este proyecto sea pronto integrado al sistema base de OpenBSD. Hoy en día systrace es ya parte del árbol estable de OpenBSD, y existen paquetes no oficiales para brindarle soporte en Linux, inclusive integrado ya a la rama inestable de Debian como parche no oficial al núcleo y como un par de paquetes con los programas en espacio de usuario \begin_inset LatexCommand \cite{deb-systrace} \end_inset . \layout Bibliography \bibitem {Multics introduction and overview} Corbató, F. J., y Vyssotsky, V. A., \begin_inset LatexCommand \htmlurl[Introduction and overview of the Multics system]{http://www.multicians.org/fjcc1.html} \end_inset , AFIPS Conf Proc 27, 185-196, 1965. \layout Bibliography \bibitem {Multics PL/1} \begin_inset LatexCommand \url[Multics PL/1]{http://www.multicians.org/pl1.html} \end_inset \layout Bibliography \bibitem {DOD 5200.28-STD} \begin_inset LatexCommand \url[Department of Defense Trusted System Evaluation Criteria]{http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html} \end_inset , Dec. 1985 \layout Bibliography \bibitem {simtics} \begin_inset LatexCommand \url[SIMTICS Isn't MULTICS]{http://simtics.sourceforge.net/design.html} \end_inset \layout Bibliography \bibitem {multicians.org} \begin_inset LatexCommand \url[Multicians]{http://www.multicians.org} \end_inset \layout Bibliography \bibitem {Multics FAQ} \begin_inset LatexCommand \url[FAQ e información general de Multics]{http://www.multicians.org/general.html} \end_inset \layout Bibliography \bibitem {Multics features} \begin_inset LatexCommand \url[Características (software y hardware) de Multics]{http://www.multicians.org/features.html} \end_inset \layout Bibliography \bibitem {Multics hist} \begin_inset LatexCommand \url[Historia de Multics]{http://www.multicians.org/history.html} \end_inset \layout Bibliography \bibitem {strace (1)} Página de manual de strace(1) (en sistemas Linux) \layout Bibliography \bibitem {signal(7)} Página de manual de signal(7) \layout Bibliography \bibitem {kill(2)} Página de manual de kill(2) \layout Bibliography \bibitem {trustix} \begin_inset LatexCommand \url[TRUSTIX: Access Control Lists]{http://www.cotse.com/texts/rainbow/silver.htm} \end_inset \layout Bibliography \bibitem {trusted_solaris-features-benefits} \begin_inset LatexCommand \url[Trusted Solaris[tm] 8 Operating Environment Features and Benefits]{http://wwws.sun.com/software/solaris/trustedsolaris/features.html} \end_inset \layout Bibliography \bibitem {trusted_solaris-oper-env} \begin_inset LatexCommand \url[Trusted Solaris[tm] Operating Environment]{wwws.sun.com/software/solaris/trustedsolaris/ds-ts8/index.html} \end_inset \layout Bibliography \bibitem {trusted_solaris-root} \begin_inset LatexCommand \url[FAQ: Why can't I log in as root after installing Trusted Solaris?]{wwws.sun.com/software/solaris/trustedsolaris/ts_tech_faq/faqs/root_log.html} \end_inset \layout Bibliography \bibitem {trusted_solaris-user-guide} \begin_inset LatexCommand \url[Trusted Solaris User's Guide: Introduction to Trusted Solaris]{docs.sun.com/db/doc/805-8115-10/6j7klujb8} \end_inset \layout Bibliography \bibitem {trustedbsd} \begin_inset LatexCommand \url[The TrustedBSD Project]{http://www.trustedbsd.org/} \end_inset \layout Bibliography \bibitem {trustedbsd-components} \begin_inset LatexCommand \url[TrustedBSD - Components]{http://www.trustedbsd.org/components} \end_inset \layout Bibliography \bibitem {trustedbsd-dn} \begin_inset LatexCommand \url[The TrustedBSD Project - Daemonnews]{http://ezine.daemonnews.org/200110/trustedbsd.html} \end_inset \layout Bibliography \bibitem {Posix summary} \begin_inset LatexCommand \url[Summary about Posix.1e]{http://wt.xpilot.org/publications/posix.1e/index.html} \end_inset \layout Bibliography \bibitem {Security extensions to Posix} \begin_inset LatexCommand \url[Fwd: Security extensions to Posix what would have been Posix.1e/2c)]{http://lists.nas.nasa.gov/archives/ext/linux-security-audit/1999/06/msg00057.html} \end_inset \layout Bibliography \bibitem {Posix-FreeBSD} \begin_inset LatexCommand \url[POSIX.1e implementation for FreeBSD]{http://www.watson.org/fbsd-hardening/posix1e/index.html} \end_inset \layout Bibliography \bibitem {Posix linux faq} \begin_inset LatexCommand \url[Linux Capabilities FAQ 0.2]{ftp://ftp.guardian.no/pub/free/linux/capabilities/capfaq.txt} \end_inset \layout Bibliography \bibitem {capacidades en 2.4.20} Archivo del código fuente del kernel de Linux \family typewriter include/linux/capability.h \family default , Andrew G. Morgan, Alexander Kjeldaas \layout Bibliography \bibitem {systrace-pdf} \begin_inset LatexCommand \url[Improving Host Security with System Call Policies]{http://www.citi.umich.edu/techreports/reports/citi-tr-02-3.pdf} \end_inset , Niels Provos \layout Bibliography \bibitem {systrace-web} \begin_inset LatexCommand \url[Systrace - Interactive Policy Generation for System Calls]{http://www.citi.umich.edu/u/provos/systrace/index.html} \end_inset , Niels Provos \layout Bibliography \bibitem {Hairy Eyeball} \begin_inset LatexCommand \url[Proyecto Hairy Eyeball]{http://blafasel.org/~floh/he/index.html} \end_inset \layout Bibliography \bibitem {deb-systrace} \begin_inset LatexCommand \url[Paquete kernel-patch-systrace en Debian]{http://packages.debian.org/unstable/devel/kernel-patch-systrace.html} \end_inset \begin_inset LatexCommand \url[Paquete de Systrace en Debian]{http://packages.debian.org/unstable/admin/systrace.html} \end_inset , \begin_inset LatexCommand \url[Paquete de xsystrace en Debian]{http://packages.debian.org/unstable/x11/xsystrace.html} \end_inset \layout Bibliography \bibitem {systrace Alex} \begin_inset LatexCommand \url[Systrace]{http://www.openbsd.org.mx/~alex/gulev2002/Systrace/index.html} \end_inset , Alejandro Juárez Robles, Congreso GULEV 2002 \the_end