Resumen

  • En CTSS, los enlaces de los prestatarios podían influir en los modos de acceso; Jerry Saltzer señaló que esa flexibilidad volvía difícil revocar un permiso y costoso saber quién conservaba uno.
  • Multics dejó que el enlace nombrara indirectamente el segmento, pero situó la decisión en la lista de control del propio segmento; así mejoró la trazabilidad sin prometer recuperar datos copiados ni borrar decisiones en caché.

¿Cuántos directorios hay que revisar para responder una pregunta elemental: quién puede leer este archivo? En la comparación que Jerry Saltzer publicó sobre CTSS y Multics, la respuesta de CTSS podía ser «todos». Un usuario compartía un archivo permitiendo que otras personas colocaran enlaces en sus propios directorios. Esos enlaces señalaban el original y solían incluir restricciones adicionales sobre las operaciones permitidas.

El mecanismo resolvía una necesidad práctica, pero repartía el estado de autorización. Para retirar el acceso había que modificar el directorio del prestatario. Una misma persona podía llegar al mismo archivo por dos enlaces y obtener facultades distintas. Para auditar el conjunto de accesos era preciso recorrer directorios ajenos, con coste operativo y con el riesgo de revelar información que el auditor no necesitaba conocer.

Saltzer no rechazó el enlace. Separó sus funciones. En Multics seguía siendo una dirección indirecta, útil para nombrar y localizar. No aportaba privilegio. El permiso se evaluaba mediante la lista de control de acceso asociada al segmento señalado.

El archivo conserva la pregunta decisiva

Multics organizaba el almacenamiento en segmentos con nombre. Cada segmento era una unidad de catálogo, una unidad que podía mapearse en la memoria virtual de un proceso y una unidad protegida por separado. El proceso tenía un identificador de principal. Al solicitar acceso, el sistema comparaba ese identificador con la lista del segmento y determinaba el modo permitido.

La operación importaba. Leer, escribir y ejecutar no eran equivalentes. Las colas de mensajes distinguían entre insertar y extraer; los directorios, entre listar, modificar y añadir. Una referencia que resolvía el segmento no bastaba para contestar qué verbo estaba autorizado.

Esta arquitectura colocaba la explicación junto al recurso: una ruta respondía qué segmento era; la lista respondía qué principal podía hacer qué cosa. Cambiar el nombre usado para llegar no debía crear un derecho nuevo. Si el propietario retiraba a una persona de la lista, no necesitaba localizar antes todos los alias que apuntaban al segmento.

La ventaja también era contable. El auditor podía partir de una lista ligada al recurso y examinar las entradas aplicables. Había complejidad —identidades con varias partes, grupos, compartimentos, prioridades entre entradas específicas y generales—, pero esa complejidad tenía un lugar visible. El sistema no obligaba a inferir el permiso a partir de la geografía de los nombres.

Menos herencia, más comprensión

El diseño llegó allí después de descartar una alternativa. Una versión anterior de Multics trataba la lista inicial de un directorio como un apéndice común de los objetos creados en él. Parecía una herencia cómoda: una modificación superior podía influir en muchos objetos. En la práctica, el orden y la combinación de reglas daban resultados diferentes en cada caso. El efecto de una sola modificación era difícil de anticipar.

Multics pasó a copiar la lista inicial cuando se creaba el objeto. El cambio redujo la capacidad de alterar retrospectivamente todos los objetos mediante el valor por defecto, pero dejó a cada uno con una lista que podía leerse por sí misma. Para Saltzer, la protección era un equilibrio entre expresividad, comprensión y coste de implementación. La generalidad que multiplica errores no es neutral.

El contraste con CTSS encaja en esa filosofía. Permitir que cada enlace module el acceso añade opciones. También crea excepciones dispersas que sobreviven a la intención original. Hacer que el enlace sea solo un nombre limita su poder y concentra la decisión que debe revisarse cuando cambian las relaciones laborales, los proyectos o la sensibilidad de los datos.

Una decisión recordada también debe revocarse

El trabajo posterior de Saltzer con Michael D. Schroeder formuló ocho principios de protección, entre ellos la mediación completa: todo acceso debe someterse a una comprobación de autoridad. El texto de 1974 ya advertía que los sistemas continuos recuerdan decisiones para usos futuros. Por eso una modificación de autoridad necesita propagarse a esas memorias locales.

La precisión evita una lectura ingenua. Un control realizado al abrir un archivo o mapear un segmento no equivale a releer la lista antes de cada instrucción. Un descriptor abierto, una sesión, un mapeo o una caché puede conservar la respuesta anterior. La actualización central demuestra que cambió la política; no demuestra cuándo dejaron de servir todos los resultados derivados de ella.

Una prueba operativa debería unir el principal, el segmento resuelto, la operación solicitada, la versión de la regla y la duración del permiso local. La revocación exige después otra cadena: cambio aceptado, dependencias invalidadas, credenciales o sesiones caducadas y un nuevo intento denegado. Contar enlaces eliminados no sustituye ese recorrido.

La copia queda fuera del alcance

Saltzer también traza un límite incómodo. Quien tiene derecho de lectura puede copiar el segmento. Retirar el permiso de origen no borra esa copia. El control del uso posterior a una divulgación autorizada era un problema que la lista no resolvía.

El artículo de 1974 tampoco presenta Multics como sistema perfecto. Enumera mecanismos incompletos y reconoce que demasiados módulos seguían dentro de la zona de mayor privilegio. La frontera entre nombre y autoridad ayuda a identificar qué debe ser fiable; no certifica que ese conjunto sea correcto.

La lección actual no consiste en copiar una ACL de los años setenta. Consiste en no convertir una referencia visible en una explicación de autoridad. Un enlace compartido puede seguir existiendo después de una baja. Un alias puede resolver bien y aun así recibir un rechazo. Un identificador puede ser estable mientras el permiso cambia. Nombrar, autorizar, usar y revocar son estados relacionados, pero necesitan pruebas distintas.

Fuentes