Кратко

  • В CTSS, который описывает Jerry Saltzer, ссылки в каталогах заёмщиков могли влиять на режим доступа. Отзыв требовал менять чужой каталог, а для полного перечня допущенных приходилось искать ссылки по всей системе.
  • Multics оставил ссылке роль косвенного адреса, а решение перенёс в список контроля у целевого сегмента. Это упорядочило полномочия, но не вернуло скопированные данные и не аннулировало само по себе сохранённые решения.

Владелец файла прекращает совместную работу, но запись для доступа находится не у него, а в каталоге другого пользователя. Чтобы закрыть путь, нужно изменить чужое пространство. Чтобы убедиться, что путей больше нет, приходится обследовать все каталоги. Удобная ссылка становится распределённым реестром разрешений, которого никто не видит целиком.

Так Saltzer сравнивал ранний Compatible Time-Sharing System с Multics. В CTSS другие пользователи помещали в свои каталоги специальные ссылки на исходный файл. Ссылка называла оригинал и обычно содержала дополнительные ограничения на допустимые режимы. Гибкость позволяла одному человеку получать разные права на один файл в зависимости от выбранного имени.

Последствия касались не только интерфейса. Отзыв был неудобен, потому что ссылка жила у заёмщика. Защитный аудит требовал искать по каждому каталогу, что было дорого и затрагивало сведения о других пользователях. Расположение имени стало влиять на расположение власти.

Multics сохранил возможность косвенно назвать ресурс, но перестал считать ссылку основанием доступа. Она помогала найти сегмент и не несла привилегии. Право определял список контроля доступа, связанный с самим сегментом.

Одна цель, один источник решения

В описании 1974 года хранилище Multics организовано как именованные сегменты. Сегмент служил единицей каталога, единицей отображения в виртуальную память процесса и отдельно защищаемой единицей. Процессу назначался неподделываемый идентификатор принципала. При попытке обратиться к зарегистрированному ресурсу его сравнивали с записями списка ресурса.

Режим тоже имел значение. Для сегмента различались чтение, запись и исполнение; для очередей сообщений и каталогов существовали собственные операции. Имя определяло цель, но не подменяло ответ о принципале и действии.

Поэтому второй путь к тому же сегменту не создавал второе право. Ответственный мог изменить список у ресурса, не собирая все псевдонимы. Аудитор мог начинать с ресурса и применимых правил, а не считать каждое имя потенциальным скрытым пропуском.

Сами правила оставались сложными. Идентификатор мог учитывать человека, проект и отделение; более конкретная запись опережала общую; право менять каталог давало власть над некоторыми спецификациями ниже. Архитектура не устраняла иерархию, а делала точку её применения обозримой.

Почему отказались от общего приложения

Saltzer описывает и собственный неудачный вариант Multics. Ранний проект использовал начальный список каталога как общее приложение к спискам всех ресурсов внутри. Одно изменение наверху могло затронуть много целей. Однако сочетание общих и частных записей давало разный результат для каждого ресурса, и последствия трудно было предвидеть.

В итоге начальный список стали копировать при создании ресурса. Последующая смена значения по умолчанию не переписывала старые ресурсы, зато текущее состояние каждого можно было понять отдельно. Saltzer рассматривает механизм как компромисс между выразительностью, понятностью и стоимостью реализации.

Ограничение ссылки следует той же логике. Условия на каждом пути удобны для исключений, но порождают конкурирующие описания одной власти. Чем больше мест могут тайно даровать право, тем труднее доказать его прекращение после ухода сотрудника, завершения проекта или срочного запрета.

Сохранённое разрешение тоже стареет

В более поздней работе Saltzer и Michael D. Schroeder сформулировали принцип полной медиации: доступ к ресурсу должен проверяться на наличие полномочия. Текст о Multics добавляет инженерное условие. Непрерывно работающая система может запоминать решение для будущего использования, поэтому изменение полномочий должно распространиться в такие локальные памяти.

Это не означает перечитывание списка перед каждым байтом. Проверка при открытии файла или отображении сегмента может породить открытый дескриптор, отображение, сеанс либо запись кэша. Если они продолжают действовать после центрального изменения, политика уже новая, а фактическое состояние — ещё старое.

Полезное свидетельство разрешения связывает принципала, окончательно разрешённый ресурс, действие, версию правила, время решения и срок жизни производного состояния. У отзыва своя цепочка: изменение принято, зависимые сеансы и кэши аннулированы, старые полномочия истекли, новая попытка отклонена. Исчезновение видимой ссылки этой цепочки не заменяет.

У отзыва есть необратимая граница

Правило у ресурса помогает прекратить будущие операции, но не забирает уже раскрытую информацию. Saltzer отмечает, что пользователь с правом чтения может сделать копию. Запрет на исходном сегменте не стирает её. Контроль после разрешённой передачи оставался отдельной задачей.

Multics в статье не изображён безупречным итогом. В ней перечислены незавершённые механизмы и слабые места, включая слишком большую наиболее защищённую область. Ясная граница показывает, чему приходится доверять, но не удостоверяет правильность доверенной части.

Современные общие URL, псевдонимы, дескрипторы и сеансы нередко объединяют словом «доступ». Сравнение Saltzer требует четырёх разных реестров: имён, действующих выдач, наблюдавшегося использования и распространения отзыва. Ссылка может по-прежнему находить файл. Возможность его открыть должна оставаться отдельным решением.

Источники