Теоретические основы компьютерной безопасности, часть 1: Эволюция ЭВМ

Информационная безопасность в целом не является новой научной дисциплиной. Считается, что впервые вопросы информационной безопасности были задокументированы в трактате «Искусство войны» древнекитайского полководца Сунь Цзы. Этот трактат был написан в V-м веке до нашей эры, но уже в нем автор говорил о важности обладания актуальной информацией о собственных силах и силах противника, о необходимости сокрытия этой информации и распространении ложной информации, адресованной противоборствующей стороне: «Поэтому просвещенные государи и мудрые полководцы двигались и побеждали, совершали подвиги, превосходя всех других, потому, что всё знали наперед. Знание наперед нельзя получить от богов и демонов, нельзя получить и путем умозаключений по сходству, нельзя получить и путем всяких вычислений. Знание положения противника можно получить только от людей».

Можно сказать, что практически до конца первой половины XX-го века суждения Сунь Цзы были корректны, и вопросы обеспечения информационной безопасности, в основном, сводились к организации безопасного взаимодействия людей и документов (при их создании, пересылке, потреблении информации из них). Но все кардинально поменялось с появлением электронных вычислительных машин (ЭВМ) и развитием систем связи, в частности, появлением сети ArpaNet, на базе которой позже сформировалась современная глобальная сеть Интернет. Эти технические средства привнесли революцию в процессы обработки информации: теперь документ (его образ в ЭВМ) стало возможным копировать и пересылать за тысячи километров буквально за доли секунды, а попутно появились относительно простые способы решения задач уничтожения и искажения информации. Все это породило самостоятельную ветвь отрасли информационной безопасности – компьютерную безопасность. В этой области знаний были разработаны все используемые сегодня методы защиты информации в компьютерных системах на базе строгого доказательного подхода, что гарантирует (при соблюдении некоторых условий) выполнение критериев безопасности для компьютерной системы.

Мы уже затрагивали эту объемную тему в статье об изолированных программных средах, но лишь применительно к рассматриваемому в ней вопросу изолированной программной среды. В этот раз текст посвящен рассмотрению истории становления теоретических основ компьютерной безопасности, а также наиболее значимых результатов (и предпосылок их возникновения), которые используются в компьютерных системах и сегодня уже в качестве базы для реализации механизмов обеспечения информационной безопасности. Ради повышения удобства восприятия статья будет разделена на две части: первая часть посвящена эволюции ЭВМ от ENIAC до операционной системы MULTICS с упором на задачи, связанные с безопасностью, а во второй мы рассмотрим процесс зарождения теоретических основ компьютерной безопасности.

Итак, первой ЭВМ принято считать ENIAC (англ. Electronic Numerical Integrator and Computer – электронный численный интегратор и вычислитель) [1]. Ключевым отличием этого устройства от ранее созданных электромеханических вычислителей была универсальность решаемых задач, хотя она была сильно ограничена по меркам более современных ЭВМ. ENIAC создавался для выполнения баллистических расчетов в интересах подразделений артиллерии армии США. Однако завершение работы над ЭВМ пришлось на февраль 1946-го года, что не позволило использовать ENIAC по его первоначальному назначению: в мирное время попросту отсутствовала потребность в таком количестве расчетов для артиллерии. Однако эта ситуация позволила продемонстрировать гибкость ЭВМ в противовес узкоспециальным вычислительным устройствам: конфигурация переключателей ENIAC (аналог современной программы) позволяла задать необходимую последовательность выполнения математических и иных операций (см. рисунок 1), кроме того, в системе команд ENIAC присутствовал условный переход, что позволяет реализовать все основные алгоритмические конструкции: ветвления, циклы, вызовы подпрограмм и пр. Эта гибкость позволила использовать ENIAC для расчета математической модели водородной бомбы – задачи, которая даже не была сформулирована на момент создания ЭВМ.

Успех ENIAC породил настоящий бум ЭВМ, появился ряд компаний, которые занялись производством все более совершенных вычислительных машин. Наиболее известной была компания International Business Machines (IBM), прочие занимали значительно меньшую долю рынка, поэтому все эти компании шутливо называли «IBM и семь гномов» [2]. ЭВМ компании IBM стали называть мэйнфреймы (от англ. mainframe), что происходит от названия процессорных стоек системы – специальных шкафов, в которых размещалось оборудование ЭВМ.

ЭВМ того периода позволяли подготовить программу на отдельном носителе (например, перфокарте), после чего программа вводилась в ЭВМ посредством считывателя и выполнялась. Непосредственный запуск программы производился оператором ЭВМ – т.е. отсутствовало какое-либо разделение ресурсов (в первую очередь вычислительных) между различными программами. Подобный режим работы ЭВМ носил название однопоточной обработки и применялся, например, в мэйнфрейме IBM 704 [3].

Однопоточная обработка была неэффективна, так как программы могли выполняться разное время и в работе ЭВМ мог образовываться простой (или наоборот – какой-нибудь емкой задачи могло не хватить выделенного времени для завершения работы). Кроме того, до запуска программы еще необходимо было выполнить различные подготовительные процедуры: сбросить память и регистры, чтобы убрать следы предыдущей программы, подготовить считыватели и другие периферийные устройства и пр. Хорошей иллюстрацией насколько такой подход был не эффективен может служить порядок работы с мэйнфреймом IBM 701 в лаборатории General Motors Research (GMR): каждому пользователю выделялось 15 минут (при этом час аренды ЭВМ стоил 300 долларов США), из них в среднем пользователь 10 минут тратил на подготовительные процедуры и печать результатов, а на сами вычисления оставалось порядка 5 минут [4]. Тогда у сотрудников GMR возникла идея создания некоторой постоянно исполняемой программы (монитора), которая будет выполнять следующие функции:

1. Корректно инициализировать (сбрасывать) внутренние и периферийные устройства ЭВМ.

2. Автоматически запускать следующую программу, которая уже загружена в оперативную память ЭВМ.

Эта программа позволила решить сразу две проблемы: во-первых, сократились потери времени пользователя на самостоятельную подготовку ЭВМ к работе, во-вторых, предварительная загрузка нескольких программ позволяла более оптимально распределить время: если какая-то программа завершала работу до того, как исчерпается выделенный временной лимит, то программа-монитор сразу запускала следующую программу в очереди, и это позволяло избежать простоя дорогостоящего вычислительного ресурса ЭВМ.

Описанная программа-монитор была реализована для мэйнфрейма IBM 704 в мае 1956 года и получила название системы ввода/вывода (Input/Output system). Именно эта программа считается первой разработанной операционной системой [4]. По названию лаборатории за системой закрепилось название General Motors & North American Aviation Input/Output system (GM-NAA I/O).

Однако необходимо заметить, что GM-NAA I/O не является многопользовательской системой в привычном нам понимании: в ней вообще нет сущности пользователя, в процессе выполнения отдельной пользовательской задачи этой программе по-прежнему принадлежат все ресурсы ЭВМ, промежуточные результаты выводятся через периферийные устройства и не сохраняются на самой ЭВМ, а сами программы пользователи, как и раньше, должны приносить на носителях в машинный зал. Поэтому на этапе разработки GM-NAA I/O вопросы компьютерной безопасности не возникли.

Но подход GM-NAA I/O тоже не был лишен недостатков. Во-первых, простои в работе ЭВМ могли образовываться, если пакет программ был подобран неудачно и завершался до того, как оператор будет готов загружать следующий пакет. Во-вторых, для пользователя порядок выполнения программ оставался прежним: необходимо передать носитель с программой оператору и ждать своей очереди на получение вычислительного ресурса. Решить эти проблемы позволило дальнейшее развитие систем-мониторов и появление идеи разделения времени (time sharing).

Есть версия, что одной из причин изобретения метода разделения времени ЭВМ стало условие, на котором компания IBM предоставляла Массачусетскому Технологическому Институту (англ. Massachusetts Institute of Technology – MIT) доступ к своей новой модели ЭВМ – IBM 7090 (более совершенная версия мэйнфрейма в сравнении с IBM 704): MIT получал 8-ми часовой непрерывный отрезок для работы с ЭВМ – это было гораздо больше, чем у любого другого института или колледжа Новой Англии. Но сама компания IBM также использовала этот компьютер для своих задач, одной из которых был расчет гандикапа для яхт, так как президент компании IBM был заядлым яхтсменом, а определение коэффициента гандикапа для больших яхт требовало вычислений по достаточно сложным формулам. И тем самым условием предоставления огромного 8-ми часового отрезка для нужд MIT стало то, что при возникновении задачи расчета гандикапа все остальные задачи должны быть прерваны и запущена эта приоритетная задача [5]. Естественно ребятам из MIT было очень обидно прерывать какую-нибудь сложнейшую расчетную задачу, терять все промежуточные результаты, ради того, чтобы посчитать коэффициенты гапдикапа, что занимало у ЭВМ буквально несколько секунд...

Сама идея и основные принципы операционной системы разделяемого времени были сформулированы Джоном МакКарти, профессором Стэндфордского университета в меморандуме «Предложение по разделению времени», написанном 1 января 1959 г. [6] (да, это тот самый Джон МакКарти, который считается автором термина "искусственный интеллект"). Джон МакКарти писал, что типичный жизненный цикл программы в большей степени состоит из стадии ее написания и дальнейшей отладки, а не непосредственного расчета. При этом для самой ЭВМ операции также занимают разное время и наиболее длительными являются операции ввода/вывода. Разработчик программы вынужден злоупотреблять функцией вывода различных данных, чтобы собрать (скорее всего избыточную) информацию о ходе выполнения его программы – если программа завершится с ошибкой, то разработчик получит данные, в которых можно найти причину этой ошибки и исправить ее.

Джон МакКарти приходит к выводу, что реализация отладки программы в реальном времени, когда у пользователя будет диалог с вычислительной машиной, позволит снизить объем операций, выполняемых ЭВМ для расчета одной задачи, по самой скромной оценке, в 5 раз. Но такой диалоговый режим возможен, если ЭВМ будет иметь возможность выполнять расчетные задачи (эффективно расходующие машиночасы ЭВМ), пока пользователь анализирует вывод, готовит новые входные данные и т.п.

МакКарти описывает конкретные технические задачи, которые необходимо решить, чтобы обеспечить такую оптимизированную работу ЭВМ:

1. Реализовать функцию распределения памяти ЭВМ между разными программами. При этом сама программа должна стать переносимой (т.е. не использующей абсолютные адреса в памяти ЭВМ, а некие относительные адреса).

2. Реализовать прерывание исполнения программы. Для этого было предложено включить в состав ЭВМ часы реального времени с линией прерывания, а также заменить некоторые инструкции (в частности, stop) на инструкцию отладки, которая будет передавать управление программе оператора.

3. Предотвратить возможное разрушение программного кода другой программой.

Первые две задачи были революционными для своего времени: например, переносимость программы требовала разработки неких символьных адресов, которые бы затем транслировались в физические адреса памяти ЭВМ – это требовало создания некоего промежуточного (между исходным кодом на языке высокого уровня и машинными кодами) представления программы (объектного кода). А наличие прерывающего таймера – по сути, говорило о необходимости параллельной работы двух программ на ЭВМ: основной программы, выполняющей расчеты, и программы монитора, которая обрабатывает сигналы от таймера. Технически это было куда сложнее, чем программа-монитор, которая запускалась только перед началом исполнения основной вычислительной задачи, готовила для этой задачи все окружение, а потом полностью передавала управление этой задаче. Исполнение двух параллельных программ требовало серьезного изменения самой архитектуры ЭВМ.

Последний пункт в этом перечне наиболее интересен с точки зрения развития компьютерной безопасности. По сути это было первое осознание необходимости реализации функции безопасности в управляющей программе ЭВМ. До этого подобная задача была неактуальна: программы передавались оператору на носителе, т.е. они являлись пассивными объектами, а при исполнении они получали в монопольный доступ все ресурсы ЭВМ – не было каких-то «чужих» ресурсов, для которых требовалось бы обеспечивать целостность. Подход с разделением времени все менял: в оперативной памяти ЭВМ должны были параллельно присутствовать разные программы, при этом каждая программа имеет возможность записывать в оперативную память произвольные данные, а значит, возникает вероятность, что ошибки в одной программе могут привести к нарушению работы всех остальных программ (необходимо отметить, что Джон МакКарти вообще не рассматривал вариант злого умысла со стороны автора программы).

В своем меморандуме Джон МакКарти предлагает даже возможные решения проблемы перезаписи памяти чужой программы:

1. Модификация трансляторов, исключающая возможность адресации памяти за пределами диапазона, выделенного программе.

2. Использование контрольных сумм для областей памяти, чтобы обнаруживать факт модификации.

3. Разработать такие техники программирования, чтобы нарушение работы прочих программ было маловероятным.

По сути, перечисленные подходы можно считать первыми защитными мерами операционной системы (правда не реализованными, а лишь предложенными).

И уже в 1961-м году в MIT начинается разработка Совместимой системы разделения времени (Compatible Time Sharing System – CTSS), которая ставит перед собой целью реализовать идеи разделяемого времени. Разработку возглавил профессор Фернандо Хосе Корбато, который во многих документах и переписках упоминается как Корби.

Кстати, на YouTube можно посмотреть полную версию интервью Корби.

Основным нововведением системы стал многопользовательский диалоговый режим работы посредством терминалов типа телетайп. Кроме того, у пользователей появилось собственное пространство для хранения информации в виде файлов и для предотвращения несанкционированного доступа пользователей к чужим файлам (умышленного или случайного) в CTSS была реализована парольная аутентификация [7]. В первой реализации CTSS файлы пользователей хранились на персональных магнитных лентах пользователей, которые активировались при начале сеанса соответствующего пользователя [8].

Несмотря на все ограничения CTSS стала настоящим прорывом в области операционных систем. Результатом стал грант от Управления перспективных исследовательских проектов Министерства обороны США (Advanced Research Projects Agency – ARPA): 2 миллиона долларов США в 1963-м году и 3 миллиона в 1964-м [9]. Это позволило начать в стенах MIT разработку промышленной операционной системы, готовой к применению, в том числе, на ЭВМ Министерства обороны США (CTSS, конечно, не могла претендовать на такую роль, так как была больше демонстрацией технологии и академической разработкой, а не законченным промышленным программным обеспечением).

Средства гранта были направлены для реализации Проекта MAC (англ. Project MAC). В состав команды вошли представители Исследовательской группы компьютерных систем MIT и Лаборатории искусственного интеллекта – наиболее компетентные в то время подразделения в вопросах, связанных с разработкой программ для ЭВМ. Аббревиатура MAC расшифровывалась участниками по-разному: для членов Исследовательской группы компьютерных систем MAC означало Multiple Access Computing, т.е. вычисления с множественным доступом, а для членов Лаборатории искусственного интеллекта – Machine Aided Cognition, т.е. сознание, создаваемое машиной. Это двойственная расшифровка отражала цели проекта: общей целью было исследование методов применения компьютеров для совершенствования интеллектуальной деятельности человека, а более частной целью было создание операционной системы, обеспечивающей параллельный доступ пользователей к ресурсам ЭВМ[10].

Проект MAC существовал более 10 лет и основным его результатом стала операционная система Multics (название образовано от словосочетания Multiplexed Information and Computing Services). Эта операционная система заменила CTSS: в 1965-м году команда проекта прекратила развитие CTSS и полностью переключилась на создание Multics [11].

Первой фазой разработки Multics стало описание концепции супервизора операционной системы, которая включала и базовые архитектурные решения: механизмы управления памятью, процессы, планировщик, динамическую компоновку кода процессов, интерактивную оболочку и пр. [12]. Все это привычные компоненты современных операционных систем, но в Multics большинство этих концепций реализовывались впервые. В частности, понятие процесса кардинально меняло роль программы пользователя в системе. Если раньше у пользователя была некоторая вычислительная задача, имевшая начало (момент запуска) и окончание (завершение расчета и вывод результата), то теперь программа могла «работать бесконечно», точнее она могла быть загружена в память все время, чтобы, например, предоставлять определенные сервисы другим программам (процессам). Такая программа могла даже не взаимодействовать с устройствами ввода/вывода, а использовать исключительно механизмы межпроцессного взаимодействия – также нового механизма, который не имел смысла в эпоху пакетной загрузки вычислительных задач.

Но заложенные в концепции идеи требовали дальнейшей проработки, которая заключалась в изучении возможности реализации концепции на аппаратном уровне и с помощью специальной программы (процесса), которая и получила название супервизор – т.е. некоторая управляющая программа, контролирующая поведение всех остальных программ ЭВМ.

Одним из основных объектов управления операционной системы Multics было машинное время, которое, как мы помним, стоило в те времена очень дорого. Поэтому авторский коллектив разработал концепцию счетов, ассоциированных с конкретными пользователями и систему учета, которая списывала средства со счетов пользователя при запуске и работе процессов от имени этого пользователя [13]. При разработке решения по учету использования ресурсов ЭВМ было сформулировано два принципа:

1. Каждый факт потребления ресурсов ЭВМ должен быть связан с каким-то счетом.

2. Потребление ресурсов производится только процессом, для которого определена принадлежность к некоторому счету.

При этом за всеми процессами и потреблением ресурсов следил специальный служебный процесс-аудитор, задачей которого было вести учет ресурсов (и отражать факты потребления в некоем журнале). Кроме того, процесс-аудитор должен был препятствовать любым попыткам нарушения своей работы или нарушения целостности данных счетов, например, приписывание пользователем несуществующих средств на своем счете. Оригинальная схема концепции из документа [13] приведена на рисунке 3.

Несмотря на то, что концепция счетов и учета потребления ресурсов напрямую не связана с задачами компьютерной безопасности (обеспечение конфиденциальности, целостности и доступности информации, обрабатываемой в компьютерной системе), само описание реализации и использованные термины в несколько ином виде существуют и по сей день в любой современной операционной системе. Так счет (или в английском языке – account) – это учетная запись пользователя. Сейчас она в меньшей степени ассоциирована с денежными средствами и оплатой потребленных ресурсов (если, конечно, мы не говорим о ресурсах облачных платформ, где как раз учетная запись имеет смысл во многом похожий на описание, приведенное в [13]), но само название сущности сохранилось в первозданном виде. Также учетная запись определяет какие ресурсы компьютера или сервисы операционной системы доступны пользователю, но теперь ограничением является не состояние счета пользователя, а наличие у него определенных прав. Концепция того, что все процессы должны через учетные записи быть связаны с пользователями, а все действия в системе реализовываться процессами – основа любого механизма безопасности операционной системы. Данные, в которых фиксируются все действия процессов, мы до сих пор зовем данными аудита, несмотря на то, что это больше не является основанием для выставления счетов пользователям за потребленные ресурсы компьютера. А свойства процесса-аудитора в несколько преобразованном виде стали стандартными свойствами монитора ссылок или монитора безопасности операционной системы (это понятие будет затронуто в следующей части нашей статьи).

Параллельно велась работа и над механизмами защиты операционной системы Multics. По-прежнему вопрос защиты рассматривался, в первую очередь, с точки зрения защиты процессов и данных пользователей от случайной или умышленной порчи другим процессом (возможно, этого же пользователя или другого пользователя). Профессор Роберт Грэхэм в своей работе «Protection in an information processing utility» [14] впервые попытался построить математическую модель защиты данных в операционной системе Multics. За основу Грэхэм взял уже реализованные на тот момент (1969-й год) механизмы ЭВМ: режимы ведущего (master) и ведомого (slave), а также сегментную организацию памяти.

Режимы ведущего и ведомого были первой реализацией специального аппаратного режима работы ЭВМ для процессов операционной системы: в режиме ведущего процесс имеет возможность выполнять любые команды процессора и менять значения любых регистров, а в режиме ведомого процесс ограничен – ему доступно только какое-то подмножество команд и часть регистров.

Сегментная организация памяти предполагает разделение непрерывного адресного пространства памяти ЭВМ на сегменты – области памяти переменной длины, в которых расположены все данные пользователей и программный код процессов. В то время эта был наиболее популярный способ работы с данными: в единое адресное пространство проецировалось содержимое оперативной памяти, файловой системы, памяти прочих устройств и пр. Каждый сегмент мог иметь переменную длину, поэтому в операционной системе присутствовала таблица сегментов, которая позволяла перевести номер конкретного сегмента в плоский адрес общей памяти. Процесс использовал для адресации два числа: номер сегмента и номер машинного слова в сегменте, что позволяло менять физическое расположение сегмента в памяти и просто переписывать значение в таблице сегментов. Запись в таблице сегментов получила название дескриптора. В простейшем случае дескриптор включал информацию о начальном адресе сегмента о его длине. Дополнительно к этому Грэхэм предложил добавить поле, отражающее права доступа к сегменту: возможность доступа в режиме ведомого, возможность записи данных в сегмент и возможность запуска кода, расположенного в сегменте.

Дополнительно в своей модели Грэхэм предложил ввести понятие кольца (ring), которому принадлежит сегмент, что разделяло все сегменты на непересекающиеся классы. Также внутри сегмента определялись точки входа – некоторые сервисы, которые предоставляли программы, расположенные в этом сегменте (процедуры). Для процедур также предлагалось вести отдельную таблицу счетчиков расположений, где приводились адреса точек входа (номер сегмента и номер слова в сегменте), а также сведения о номере кольца, к которому относилась соответствующая точка входа, рисунок 4.

Далее предлагалась модель разграничения доступа, в которой фигурировал процесс, обращающийся к какому-то сегменту (либо с целью вызова процедуры, либо для чтения/записи данных): если номер кольца сегмента исходного процесса был ниже номера кольца сегмента, к которому производилось обращение, то запрошенный доступ обрабатывался в соответствии с индикатором доступа сегмента. В ином случае – доступ запрещался. Также в модели Грэхэма вводился ряд дополнительных сущностей и ограничений, чтобы корректно обработать вопрос транзитивности доступа: если процесс с номером кольца i вызывает процедуру в сегменте с номером кольца j, то выполнение этой процедуры должно вестись от уровня i или j? Обрабатывать подобную ситуацию должен был супервизор, для чего предусматривалось, что прямая передача управления из одного сегмента в другой при смене номера кольца должна приводить к ошибке, чтобы это запускало код супервизора.

Модель Грэхэма – это первая попытка формального описания модели безопасности компьютерной системы, причем многие концепции (например, кольца безопасности) до сих пор используются и в современных процессорах. Минусом модели Грэхэма являлось то, что он не представил никаких формальных критериев безопасности (защищенности) системы и не доказал, что предложенная им модель их обеспечивает.

С технической точки зрения модель Грэхэма была очень удачной: она использовала стандартные для того времени механизмы ЭВМ и позволяла реализовать развитые механизмы защиты сегментов от несанкционированной модификации. Эта модель легла в основу механизма виртуальной памяти и символических ссылок операционной системы Multics [15]: авторский коллектив проработал отдельные нюансы реализации, взял предложенные в работе Грэхэма методы адресации на основе таблиц дескрипторов и индикаторы доступа к ним, но модель колец безопасности не была реализована.

Разработка Multics заняла несколько лет, наконец 1 октября 1969-го года была выпущена версия системы для коммерческого использования. ЭВМ MIT, находящаяся в распоряжении Проекта MAC в этом же году была подключена к сети ArpaNet (предшественник сети Интернет) и уже к июню 1970-го общее количество пользователей операционной системы Multics превысило 400 человек (рисунок 5) [16].

В последующие годы популярность Multics только росла, система начала применяться и за границами MIT. В итоге система стала функционировать и на объектах основного заказчика проекта – Министерства обороны США, что привело к необходимости обработки в ней информации, составляющей государственную тайну. Как следствие возникли вопросы: действительно ли те механизмы безопасности, которые заложили участники Проекта MAC в Multics можно считать достаточными для предотвращения утечек критичной информации?

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

Для тех же, кто не только дочитал до конца, но и хотел бы ознакомиться с вопросом еще глубже - список источников:

1. Swaine M. R., Freiberger P. A. ENIAC, Encyclopedia Britannica. URL: https://www.britannica.com/technology/ENIAC

2. Getting Along With I. B. M. // The New York Times. 1973. 7 января, с. 1.

3. IBM 704. Electronic data-processing machine. Manual of operation, Computer History Museum. URL: https://archive.computerhistory.org/resources/text/Fortran/102653985.05.01.acc.pdf .

4. Ryckman G. F. 17. The IBM 701 Computer at the General Motors Research Laboratories // Annals of the History of Computing. IEEE. 1983. № 5 (2). С. 210–212.

5. Vleck T., The IBM 7094 and CTSS, The Multicians web site. URL: https://multicians.org/thvv/7094.html .

6. McCarthy J. Memorandum to P. M. Morse Proposing Time-Sharing, Professor John McCarthy Father of AI. URL: http://www-formal.stanford.edu/jmc/history/timesharing-memo.ps .

7. McMillan R. The World's First Computer Password? It Was Useless Too // Wired. 2012. 27 января.

8. Corbato F.J., Merwin-Daggett M., Daley R.C., An experimental time-sharing system // AFIPS. 1962. №21. С. 335-344.

9. Garfinkel S., Ableson H., Architects of the Information Society. MIT Press, 1999, 86 с.

10. Massachusets Institute of Technology Project MAC, Progress to July 1964. URL: https:/apps.dtic.mil/dtic/tr/fulltext/u2/465088.pdf.

11. Massachusets Institute of Technology Project MAC, Progress Report III July 1965 to July 1966. URL: https:/apps.dtic.mil/dtic/tr/fulltext/u2/648346.pdf.

12. Vyssotsky V. A., Corbato F. J., Graham R. M. Structure of the Multics Supervisor. URL: https://multicians.org/fjcc3.html.

13. Vleck T. Resource management and Accounting for Multics, URL: https://people.csail.mit.edu/saltzer/CTSS/Multics-Documents/M00s/M0066.pdf.

14. Graham R. M., Protection in an information processing utility // Commun. ACM. 1968. № 5, С. 365-369.

15. Daley, R. C., Dennis J. B., Virtual Memory, Processes, and Sharing in Multics // ACM symposium on Operating System Principles. New York, 1967. С. 12.1–12.8.

16. Massachusets Institute of Technology Project MAC, Progress Report VII July 1969 to July 1970. URL: https:/apps.dtic.mil/dtic/tr/fulltext/u2/732767.pdf.