Sistemas operativos modernos

torio improvisado creado para él. Si el código móvil se pone en su propio proceso y sólo tiene estas capacidades limitadas, no podrá tener acceso a ningún otro recurso del sistema y por tan­ to estará en verdad confinado a una caja de arena sin necesidad de modificar su código ni eje­ cutarlo por interpretación. Ejecutar código con el menor número posible de derechos de acceso constituye el principio de privilegios mínimos y es una pauta muy útil para producir sistemas seguros. Haciendo un breve resumen, las ACLs y las capacidades fienen propiedades un tanto com­ plementarias. Las capacidades son muy eficientes porque si un proceso dice “Abrir el archivo al que apunta la capacidad 3”, no es necesario efectuar verificaciones. Con ACL, podría reque­ rirse una búsqueda (tal vez larga) en la ACL. Si no se manejan grupos, para otorgar a todo mun­ do acceso de lectura a un archivo sería preciso enumerar todos los usuarios de la ACL. Las capacidades también permiten encapsular un proceso fácilmente, mientras que las ACLs no. Por otra parte, las ACLs permiten la revocación selectiva de derechos, cosa que no hacen las capacidades. Por úlfimo, si se elimina un objeto y no se eliminan las capacidades, o si se eli­ minan las capacidades y no el objeto, surgen problemas. Las ACLs no tienen este problema. 9.7 SISTEMAS DE CONFIANZA Gran parte de este capítulo se dedicó al hecho de que casi todos los sistemas de computación modernos tienen fugas como un colador Los cálculos de los daños causados en el mundo por virus y problemas similares exceden el billón de dólares anual por concepto de esfuerzo des­ perdiciado en reparar problemas, reconstruir datos dañados, etcétera, sin mencionar las opor­ tunidades de negocios perdidas. Una persona inocente podría hacer dos preguntas lógicas en lo tocante a esta situación: 1. ¿Es posible construir un sistema de computación seguro? 2. Si es posible, ¿por qué no se hace? La respuesta a la primera pregunta en esencia es sí. Desde hace décadas se sabe cómo cons­ truir un sistema seguro. MULTICS, diseñado en los años sesenta, tenía como una de sus metas principales la seguridad, y la logró de forma aceptable. La razón por la que no se están construyendo sistemas seguros es más complicada, pero se reduce a dos cuestiones fundamentales. Primera, los sistemas actuales no son seguros pero los usuarios no están dispuestos a deshacerse de ellos. Si Microsoft anunciara que tiene un produc­ to nuevo, SecureOS, que se garantiza inmune a virus pero no ejecuta aplicaciones Windows, es muy difícil asegurar que todo mundo, individuos y compañías por igual, soltaría Windows co­ mo si fuera una papa caliente y compraría de inmediato el nuevo sistema. El segundo problema es más sutil. La única forma de construir un sistema seguro es que sea sencillo. Las funciones son enemigas de la seguridad. Los diseñadores creen (con o sin ra­ zón) que los usuarios quieren más funciones. Más funciones impHcan más complejidad, más código, más errores de programación y más fallas de seguridad.