Файловая система (ФС) — это компонент ОС, отвечающий за постоянное хранение данных.
Задачи:
· хранение данных в потенциально неограниченных объемах
· долгосрочное сохранение данных (perecnetsis)
· одновременная доступность данных многим процессам
В отличие от оперативной памяти ФС являются постоянной памятью, поэтому на первое место для них выходят сохранность и доступность данных, а затем уже стоит быстродействие.
Некоторые из видов файловых систем:
· Дисковые
· Виртуальные (в памяти и не только)
· Сетевые
· Распределенные
· Мета ФС (ФС, которые используют другие ФС для организации хранения данных, а сами добавляют особую логику работы)
Файловый интерфейс — это простой и удобный способ работы с данными, поэтому многие ОС распространяют его на другие объекты, помимо файлов данных. Например, в Unix все устройства подключаются в системе как специальные файлы (символьно-специфичные — для устройств с последовательным вводом-выводом; и блочно-специфичные — для устройств с буферизированным вводом-выводом). Кроме того, в Linux есть специальные виртуальные файловые системы: sysfs, которая оперируют файлами, отображающими системные структуры данных из памяти ядра, а также tmpfs, которая позволяет создавать файлы в оперативной памяти. Такой подход привел к тому, что Unix стал известен как файл-центричная ОС, хотя есть другие ОС, которые еще далее продвинулись в этом. Например, такие объекты, как сокеты (см. лекцию про работу с сетью) в Unix имеют собственные системные вызовы, в то время как в системе Plan 9 (которая стала развитием идей Unix) они доступны через тот же файловый интерфейс.
|
|
|
Файл
Файл — это именованная область диска. (Неверное и устаревшее определение). Верное определение: Файл — это объект файловой системы, содержащий информацию о размещении данных в хранилище. При этом хранилище может быть, как физическим запоминающим устройством (диском, магнитной лентой и т.д.), так и виртуальным устройством, за которым стоит оперативная память, какое-либо устройство ввода-вывода, сетевое соединение или же другая файловая система.
Основные операции над файлами:
· c reate — создание
· delete— удаление
· open — открытие (на запись, чтение или же на то и другое вместе)
· close — закрытие
· read — чтение
· write— запись
· append — запись в конец
· seek — переход на заданную позицию для последующего чтения/записи
· getattr — получение атрибутов файла
· setattr — установка атрибутов файла
· lock — блокировка файла для эксклюзивной работы с ним (в большинстве ОС блокировка файлов реализуется в виде рекомендательных, а не обязательных замков)
Файловый дескриптор — это уникальный для процесса номер в таблице дескрипторов процесса (которая хранится в ядре ОС), который операционная система предоставляет ему, чтобы выполнять указанные операции с файлом. Системы Windows оперируют схожей концепцией — описатель файла (file handle).
|
|
|
Помимо указанных выше операциий в Unix используются следующие важные системные вызовы для работы с файловыми дескрипторами:
· dup— создание копии записи в таблице дескрипторов с новым индексом, указывающим на тот же файл
· dup 2— "перенаправление" одной записи на другую
· fsntl— управление нестандартными аттрибутами и свойствами файлов, которые могут поддерживаться теми или иными файловыми системами
Директория
Директория — это объект файловой системы, содержащий информацию о структуре и размещении файлов. Часто это тоже файл, только особый.
В большинстве ФС директории объединяются в дерево директорий, таким образом создавая иерархическую систему хранения информации. Это дерево имеет корень, который в Unix системах называется /. Положение файла в этом дереве — это путь к нему от корня — т.н. абсолютный путь. Кроме того, можно говорить об относительном пути от выбранной директории к другому объекту ФС. Относительный путь может содержать особое обозначение .., которое указывает на предка (родителя) директории в дереве директорий.
|
|
|
Логическое дерево директорий может объединять больше одной ФС. Включение ФС в это дерево называется монтированием (mount). В результате монтирования корень ФС привязывается к какой-то директории внутри дерева. Для первой монтируемой системы ее корень привязывается к корню самого дерева.
В Unix также реализована операция chroot, которая позволяет изменить корень текущего дерева на одну из директорий внутри него. В рамках одного сеанса работы, выполнив ее, уже нельзя вернуться назад, т.е. получить доступ ко всем узлам дерева, которые не являются потомками нового корня ФС.
Существует два подхода к привязке файлов к директориям: в большинстве ФС эта привязка является косвенной — через использование ссылки на отдельный объект, хранящий метаданные файла. Такие ссылки называются жесткими (hard link). В таких системах один файл может иметь несколько ссылок на себя из разных директорий. В такой системе создание нового файла происходит в 2 этапа: сначала выполняется операция create, которая создает сам файловый объект, а затем link, которая привязывает его к конкретной директории. Операция link может выполняться несколько раз, и каждый файл хранит количество ссылок на себя из разных директорий. Удаление файла происходит с точностью до наоборот: выполняется операция unlink, после чего файл перестает быть привязанным к директории. Если при этом его счетчик ссылок становится равным 0, то система выполняет над файловым объектом операцию delete. Однако есть и более примитивные системы, в которых метаданные о файле хранятся прямо в директории. Фактически, в таких ФС реализована однозначная привязка файла к единственной директории.
|
|
|
В обоих видах систем часто поддерживается также концепция символических ссылок (реализуемых в виде специальных файлов), которые ссылаются не непосредственно на файловый объект ФС, а на объект, находящийся по определенному пути. В этом случае ФС уже не может обеспечить проверку существования такого объекта и управление другими его свойствами, как это делается для жестких ссылок, но, с другой стороны, символические ссылки позволяют ссылаться на файлы в одном логическом дереве директорий, но за пределами текущей ФС.
Операции над директориями:
· create — создать
· delete — удалить
· readdir (list) — получить список непосредственных потомков данной директории (файлов и других директйиро)
· opendir— открыть директорию для изменения информации в ней
· closedir — закрыть директорию
· link/unlink
Схемы размещения файлов
Схема размещения файлов — это общий подход к хранению данных и метаданных файла на запоминающем устройстве. Основные критерии эффективности той или иной схемы — это утилизация диска, быстродействие операций чтения, записи и поиска, а также устойчивость к сбоям.
Фрагментация — это отсутствие технической возможности использовать часть
пространства хранилища данных из-за того или иного размещения данных в нем. Виды фрагментации:
· внешняя — невозможность использования целых блоков
· внутренняя — невозможность использования частей отдельных блоков
Внутренняя фрагментация неизбежна в любом хранилище, которое оперирует блоками большего размера, чем единица хранения (например, жесткий диск хранит данные побайтно, но файлы могут начинаться только с начала логического блока, как правило, имеющего размеры порядка килобайт). Возможность появления внешней фрагментация зависит от схемы размещения данных.
В этой схеме файл хранится как одна непрерывная последовательность блоков. Для указания размещения файла достаточно задать адрес его начального блока и общий размер.
Pис. 9.1. Непрерывная схема размещения файлов
Преимущества:
· легко реализовать
· самая лучшая производительность
Недостатки:
· внешняя фрагментация
· необходимость реализовать учет дырок
· проблемы с ростом размера файла
Это самая простая схема размещения. Она идеально подходит для любых носителей, который предполагают использование только в режиме для чтения, или же существенное (на порядки) превышение числа операций чтения над записью.
Связный список
В этой схеме блоки файла могут находится в любом месте диска и не быть упорядочены каким-то образом, но каждый блок должен хранить ссылку на последующий за ним. Для указания размещения файла достаточно задать адрес его первого блока.
Pис. 9.2. Схема размещения файлов связным списком
Преимущества:
· нет внешней фрагментации
· простота реализации
Недостатки:
· самая худшая производительность (особенно на магнитных дисках)
· плохая устойчивость к ошибкам: повреждение одного блока в середине файла приведет к тому, что все последующие за ним блоки будут недоступны
· не круглая цифра (в степенях 2) доступного места в блоке из-за использования части пространства блока для хранения указателя на следующий блок
Поэтому в чистом виде такая схема редко применяется. Перечисленные недостатки в основном устраняет табличная реализация этой схемы. В ней информация о следующих блоках связного списка выносится из самих блоков в отдельную таблицу, которая размещается в заранее заданном месте диска. Каждая запись в таблице хранит номер следующего блока для данного файла (или же индикатор того, что данный блок не занят либо же испорчен). Такая технология называется таблицей размещения файлов (FAT). Недостатком табличной схемы является централизация всех метаданных в таблице, что приводит к опасности потери всей ФС в случае непоправимого повреждения таблицы, а также к тому, что для больших дисков эта таблица будет иметь большой объем, а она должна все время быть полностью доступной в памяти.
Индексная схема
В этой схеме блоки разделяют на 2 типа: те, которые используются для хранения данных файла, и те, которые хранят метаданные — т.н. индексные узлы (inode). Таким образом, в отличие от предыдущей схемы, метаданные о файлах хранятся распределенно в ФС, что делает этот подход более эффективным и отказоустойчивым. Кроме того, эта схема соответствует собственно иерархической модели ФС и тривиально поддерживает операции link/unlink: директория хранит ссылки на индексные узлы привязанных к ней файлов. Поскольку индексные узлы — это обычные блоки диска, к ним применяются те же методы работы, что и для обычных блоков (например, кеширование).
Pис. 9.3. Индексная схема размещения файлов
Преимущества:
· концептуальное соответствие между логической и физической схемой хранения
· большая эффективность и быстродействие
· большая отказоустойчивость
Недостатки:
· фиксированный размер индексного узла, что налагает ограничения на размер файла (для решения этой проблемы используются непрямые inod'ы, которые хранят ссылки не на блоки данных, а на inode'ы следующего уровня)
·
Оптимизация работы ФС
Важным параметром, влияющим на оптимизацию ФС является средний размер файла. Он сильно зависит от сценариев использования системы, но проводятся исследования, которые замеряют это число для типичной файловой системы. В 90-х годах средний размер файла составлял 1КБ, в 2000-ных — 2 КБ, на данный момент — 4КБ и более.
Pис. 9.4. Связь размера блока с быстродействием и утилизацией диска при среднем размере файла в системе 2 КБ
Важный метод оптимизации ФС — это кеширование. В отличие от кеширования процессора в случае дисковых хранилищ точный LRU возможен, но иногда он может быть даже вреден. Поэтому для дисков часто используется сквозной кеш (изменение данных в нем сразу же вызывает изменение данных на диске), хотя он менее эффективен. Хотя в Unix системах для увеличения быстродействия исторически принято было использовать операцию sinc, которая периодически, а не постоянно, сохраняла изменения данных в дисковом кеше на носитель.
Также оптимизация очень существенно зависит от физических механизмов хранения данных, т.к. профиль нагрузки, например, для магнитного и твердотельных дисков совершенно разные, не говоря о ФС, работающих по сети.
Подходы к оптимизации ФС, использующих жесткий диск:
· чтение блоков наперед (однако зависит от шаблона использования: последовательный или произвольный доступ к данным в файле)
· уменьшение свободного хода дисковой головки за счет помещения блоков в один цилиндр
· использование ФС на основе журнала
Pис. 9.5. Подходы к оптимизации индексной схемы
·
Взаимодействие с сетью
«Сеть — это компьютер» (лозунг корпорации Sun)
Поддержка работы с сетью на первый взгляд не является функцией ядра ОС, однако на практике большинство ОС реализуют ее в ядре. Для этого есть несколько причин:
· работа с сетью нужна подавляющему большинству нетривиальных программ, поэтому логично, что ОС должна предоставить для них сетевой сервис, абстрагированный от разнородных аппаратных средств и низкоуровневых протоколов поддержки соединения
· Любая программа стремится расшириться до тех пор, пока с его помощью не станет возможно читать почту. Те программы, которые не расширяются настолько, заменяются теми, которые расширяются. (Закон оборачивания софта Jamie Zawinski)
· работа с сетью должна быть быстрой
· ограничения безопасности, связанные с работой с сетью
· относительная простота реализации: небольшой набор стандартных протоколов, среди которых основные — это IP, TCP и UDP
Также в основе реализации компьютерных сетей лежит Принцип устойчивости (Закон Постела):
Будьте консервативными в том, что отправляете, и либеральными в том, что принимаете от других.
Заблуждения программистов про сеть
Разработка распределенных программ, использующих сеть, отличается от разработки программ, работающих на одном компьютере. Эти отличия выражены в следующем списке т.н. «заблуждений» программистов про сеть:
· сеть надежна
· расходы на транспорт нулевые
· задержка нулевая
· часы синхронизированы
· пропускная способность неограниченна
· топология сети неизменна
· сеть гомогенна
· есть только один администратор
· сеть безопасна
Сетевая модель OSI
Сетевая модель OSI — это теоретическая эталонная модель сетевого взаимодействия открытых систем. В ней реализован принцип разделения забот (separation of concerns), который выражен в том, что взаимодействие происходит на 7 разных уровнях, каждый из которых отвечает за решение одной проблемы:
· 7й - Прикладной (application) — доступ к сетевым службам прикладных приложений, данные представляются в виде "запросов" (requests)
· 6й - Представления (presentation) — кодирование и шифрование данных
· 5й - Сеансовый (session) — управление сеансом связи
· 4й - Транспортный (transport) — связь между конечными пунктами (которые не обязательно связанны непосредственно) и надежность, данные представляются в виде "сегментов" (datagrams)
· 3й - Сетевой (network) — определение маршрута и логическая адресация, обеспечение связи в рамках сети, данные представляются в виде "пакетов (packets)
· 2й - Канальный (data link) — физическая адресация, обеспечение связи точка-точка, данные представляются в виде "кадров" (frames)
· 1й - Физический (physical) — работа со средой передачи, сигналами и двоичными данными (битами)
При обеспечении связи между узлами (хостами) данные проходят процесс «погружения» с прикладного уровня на физический на отправителе и обратный процесс на получателе.
На практике доминирующей моделью сетевого взаимодействия является стек протоколов TCP/IP, который в целом соответствует модели OSI, однако не регламентирует обязательное наличие всех уровней в ней. Как следует из названия, обязательными протоколами в ней являются TCP (или его альтернатива UDP), а также IP, которые реализуют транспортный и сетевой уровень модели OSI.
Уровни TCP/IP стека:
· 4й - Прикладной уровень (Process/Application) — соответствует трем верхним уровням модели OSI (однако, не обязательно реализует функциональность их всех)
· 3й - Транспортный уровень (Transport) — соответствjует транспортному уровню модели OSI
· 2й - Межсетевой уровень (Internet) — соответствует сетевому уровню модели OSI
· 1й - Уровень сетевого доступа (Network Access) — соответствует двум нижним уровням модели OSI
В этой модели верхний и нижний уровни включают в себя несколько уровней модели OSI и в разных случаях они могут быть реализованы как одним протоколом взаимодействия, так и несколькими (соответствующими отдельным уровням). Например, протокол HTTP реализует уровни прикладной и представления, а протокол TLS — сеансовый и представления, а в сочетании между собой они могут покрыть все 3 верхних уровня. При этом протокол HTTP работает и самостоятельно, и в этом случае, поскольку он не реализует сеансовый уровень, HTTP-соединения называют "stateless", т.е. не имеющими состояния.
Модель TCP/IP также называют песочными часами, поскольку посредине в ней находится один протокол, IP, а протоколы под ним и над являются очень разнообразными и покрывают разные сценарии использования. Стандартизация протокола посередине дает большую гибкость низкоуровневым протоколам (которая нужна из-за наличия разных способов соединения) и высокоуровневым (нужную из-за наличия разных сценариев работы).
Pис. 10.1. TCP/IP стек как песочные часы
Интерфейс BSD сокетов
Интерфейс сокетов — это де-факто стандарт взаимодействия прикладной программы с ядром ОС — точка входа в сеть для приложения. Он соединяет прикладной уровень стека TCP/IP, который реализуется в пользовательском пространстве, с нижними уровнями, которые, как правило, реализуются в ядре ОС.
Сокеты рассчитаны на работу в клиент-серверной парадигме взаимодействия:
активный клиент подключается к пассивному серверу, который способен одновременно обрабатывать множество клиентских соединений. Для идентификации сервера при сокетном соединении используется пара IP-адрес—порт. Порт— это уникальное в рамках одного хоста число, как правило, ограниченное в диапазоне 1-65535. Порты делятся на привилегированные (1-1024), которые выделяются для приложений с разрешения администратора системы, и все остальные — доступные любым приложениям без ограничений. Большинство стандартных прикладных протоколов имеют стандартные номера портов: 80 — HTTP, 25 — SMTP, 22 — SSH, 21 — FTP, 53 — DNS. Один порт может одновременно использовать только один процесс.
Сокет — это файлоподобный объект, поддерживающий следующие операции:
· создание — в результате в программе появляется соответствующий файловый дескриптор
· подключение — выполняется по-разному для клиента и сервера
· отключение
· чтение/запись
· конфигурация
Основные системные вызовы для работы с сокетами:
· socket— создание сокета
· connect — инициация клиентского соединения
· bind — привязка сокета к порту
· listen — перевод сокета в пассивный режим прослушивания порта (актуально только для TCP соединений)
· accept — принятие соединения от клиента (который вызвал операцию connect) — это блокирующая операция, которая ждет поступления нового соединения
· ·read/write или же send/recv — запись/чтение данных в сокет
· resvfrom/sendto — аналогичные операции для UDP сокетов
· setsockopt — установка параметров сокета
· close·— закрытие сокета
Поскольку сокеты — это, фактически, интерфейс для погружения на третий уровень TCP/IP-стека, сокеты не предоставляют механизмов для управления кодированием данных и сенсами работы приложений — они просто позволяют передать "сырой" поток байт.
Общая схема взаимодействия через сокет
Pис. 10.2. Общая схема взаимодействия через сокет для TCP соединения
Как видно из схемы, на сервере для установления TCP соединения нужно выполнить 3 операции:
1. bind захватывает порт, после чего другие процессы не смогут занять его для себя
2. listen (для TCP соединения) переводит его в режим прослушивания, после чего клиенты могут инициировать подключения к нему
3. однако, пока на сервере на выполнен accept, клиентские соединения будут ожидать в очереди (backlog) сокета, ограничения на которую могут быть заданы в вызове listen
Выполнение accept приводит к появлению еще одного объекта сокета, который отвечает текущему клиентскому соединению. При этом серверный сокет может принимать новые соединения.
После выполнения accept сервер может реализовать несколько сценариев обслуживания клиента:
· эксклюзивный вариант — обслуживание происходит в том же потоке, который выполнил accept, поэтому другие клиенты ждут завершения соединения в очереди
· 1 поток на соединение — сразу же после выполнения accept создается новый поток, куда передается появившийся сокет, и дальнейшая коммуникация происходит в этом потоке, который закрываетсjя по завершению соединения. Тем временем сервер может принимать новые соединения. Такая схема является наиболее распространенной. Ее основной недостаток — это большие накладные расходы на каждое соединение (отдельный поток ОС)
· неблокирующий ввод-вывод — при этом в одном потоке сервер принимает соединение, а в другом потоке работает т.н. цикл событий (event loop), в котором происходит асинхронная обработка всех принятых клиентских соединений
Неблокирующий (асинхронный) ввод-вывод
Сокеты поддерживают как синхронный, так и асинхронный ввод-вывод. Асинхронный IO является критической функцией для создания эффективных сетевых серверов. Для поддержки асинхронного ввода вывода у сокетов (как и у других файловых дескрипторов) есть параметр O_NONBLOCK, который можно установить с помощью системного вызова fcntl. После перевода файлового дескриптора в неблокирующий режим, с сокетом можно работать с помощью системных вызовов select и poll, которые позволяют для группы файловых дескрипторов узнать, какие из них готовы к чтению/записи. Альтернативой являются специфичные для отдельных систем операции, которые реализованы более эффективно, но не являются портабельными: epoll в Linux, dqueue во FreeBSD и др.
RPC и сетевые архитектуры
Распределенная программа используето для взаимодействия определенный протокол, который также можно рассматривать как интерфейс вызова процедур удаленно (RPC — remote procedure call). Фактически, интерфейс RPC реализует прикладной уровень модели OSI, но для его поддержки также необходимо в той или иной мере реализовать протоколы уровня представления и, иногда, сеансового уровня. Уровень представления решает задачу передачи данных в рамках гетерогенной (т.е. состоящей из различных компонент) сети в "понятной" форме. Для этого нужно учитывать такие аспекты, как старшинство байт (endianness), кодировки для текстовых данных, представления композитных данных (коллекций, структур) и т.д. Еще одной задачей RPC-уровня часто является нахождение сервисов (service discovery).
Реализация RPC может быть основана на собственном (ad hoc) или же каком-то из стандартных протоколов прикладного уровня и представления. Например, реализация RPC по методолгии REST использует стандартные протоколы HTTP в качестве транспортного и JSON/XML для представления (сериализации). XML/RPC или JSON/RPC — это ad hoc RPC, которые используют XML или JSON для представления данных. Протоколы ASN.1 и Thrift — это бинарные протоколы, которые определяют реализацию всех 3-х уровней.
В форматах сериализации существует 2 дихотомии: бинарные и текстовые форматы, а также статические (использующие схему) и динамические (без схемы, schema-less).
Распространенные форматы сериализации включают:
· JSON — текстовый динамический формат
· XML — тестовый формат с опциональной схемой
· Protocol Buffers — бинарный статический формат
· MessagePack — основанный на JSON бинарный формат
· Avro — основанный на JSON формат со схемой
· EDN (extensible data notation) — текстовый динамический формат
Сетевые приложения могут быть реализованы в виде разных сетевых архитектур. Ключевым параметром для каждой архитектуры является уровень централизации: от полностью централизованных — клиент-сервер — до полностью децентрализованных —peer- to- peer/ P2 P. Важными моделями между этими двумя крайностями является модель сервисно-ориентированной архитектуры (SOA), а также модель клиент-очередь-клиент.
Безопасность
Общие принципы безопасности
Информационная безопасность — это непрерывный процесс защиты информационных систем от угроз трех видов:
· несанкционированный доступ (НСД) и использование
· нарушение целостности, конфиденциальности, подлинности и других характеристик данных
· нарушение доступности и/или полноценного функционирования информационной системы
Подсистема безопасности не является выделенным компонентом ОС и ее практически невозможно добавить в систему пост-фактум, т.е. она должна быть встроена с самого начала.
Принципы создания безопасной системы:
· принцип безопасных настроек по умолчанию
· принцип валидации данных, поступающих от других участников системы
· принцип полной медации — всегда проверка текущих прав
· принцип наименьших привилегий — выдавать права, достаточные для выполнения только требуемых операций и не более того
· принцип разделения привилегий — по возможности, требовать согласия нескольких участников для выполнения операций
· принцип экономии на механизме — механизмы защиты должны быть максимально простыми из возможных и реализовываться на самом низком из возможного уровня
· принцип минимального общего между разными участниками системы
· принцип открытого дизайна — архитектура, реализация и используемые алгоритмы в системе должны быть известны, а в секрете могут держаться только ограниченные по объему авторизационные данные (ключи, пароли и т.п.)
· принцип психологической приемлемости
Основные сервисы системы безопасности описываются аббревиатурой AAA:
· Аутентификация (Authentication) — установление "личности" стороны, с которой происходит взаимодействие
· Авторизация (Authorization) — проверка прав на выполнение каких-либо операций в системе
· Аудит (Accounting) — учет операций, связанных с системой безопасности (для возможности последующего расследования и установления причин проблемы)
Способы (факторы) аутентификации:
· по паролю
· по вопросу безопасности
· по одноразовому паролю
· по жетону (уникальным числом)
· с помощью сертификата ЭЦП
Аутентификация может быть как однофакторной, так и многофакторной.
Механизмы работы системы безопасности
В системе безопасности рассматриваются 3 сущности: участники системы (субъекты, пользователи), ресурсы (например, файлы) и права доступа.
Единицей управления является домен защиты— это пара объект и права доступа. Домен может соответствовать одному субъекту или их группе.
Матрица контроля доступа — это теоретическая модель, которая описывает матрицу, которая приводит в соответствие все ресурсы системы со всеми ее субъектами. В ячейках этой матрицы находятся права доступа конкретного пользователя/роли/группы к конкретному ресурсу. Такая матрица позволяет описать все права доступа в системе, однако ее практическое применение не эффективно.
На практике используются 2 следующих подхода:
· списки контроля доступа (Access Control List, ACL), которые предполагают хранение и учет прав на уровне ресурсов, т.е., фактически, по столбцам этой матрицы
· мандатные системы (Capability или C-list), которые предполагают хранение прав доступа у субъектов системы, т.е. по строкам матрицам
В системе, основанной на ACL, для каждого ресурса определен список субъектов с их правами. Например, в ФС Unix у каждой директории и файла определены 3 типа субъектов: пользователь-владелец, группа-владелец и все остальные, — а также 3 типа прав: чтение, запись и выполнение. Другим примером ACL является список правил межсетевого экрана, ресурсами в которых являются хосты/подсети и/или возможность обращения к определенным портам/использования определенных протоколов. В такой системе вместо прав доступа устанавливаются действия экрана при обращении: разрешить, запретить, ограничить и т.д. При этом, учитывая потенциальную неограниченность различных субъектов-участников сети, в такой системе в основном используются обобщенные субъекты: все хосты, все внешние хосты, все хосты из определенной подсети и т.д.
В системах на основе мандатов мандат выдается отдельно для каждого субъекта на каждое право доступа. Мандат, как правило, реализуется как числовой жетон (token), который выдается субъекту системой безопасности. Этот жетон может быть:
· просто уникальным числом, которое записывается в базу данных для кортежа пользователь, домен безопасности. Проблема такого способа в потенциально неограниченном количестве записей в системе с большим количеством ресурсов и/или субъектов. В такой системе автентифицированному субъекту достаточно предоставить жетон для того, чтобы идентифицировать ресурс, к которому он хочет получить доступ, и получить доступ
· криптографической величиной, полученной применением односторонней функции к паре домен безопасности и секретный ключ, известный только ядру системы, с= f (domain, key). В этом случае для проверки мандата субъект должен предоставить не только сам жетон, но и идентификатор ресурса и права доступа. Проверка будет производится повторным вычислением значения функции над теми же аргументами. Безопасность системы основана на невозможности получить то же значение жетона без знания секретного ключа. В этой системе затруднен отзыв отдельных мандатов, поскольку для отзыва мандата нужно либо изменить идентификатор ресурса, что повлияет на всех субъектах, имеющих к нему доступ, либо изменить ключ, который, как правило, уникален для пользователя, но отзыв ключа приведет к отзыву всех мандатов этого пользователя. Для решения этой проблемы используются т.н. непрямые объекты.
Хотя с точки зрения модели Матрицы прав доступа в обоих системах хранится одна и та же информация, эта модель описывает только статические характеристики системы и не описывает ее поведения в динамике.
При рассмотрении динамики работы системы безопасности на основе мандатов обладают следующими преимуществами перед списками контроля доступа:
· отсутствие необходимости использования общего пространства имен ресурсов, известного всем субъектам системы
· возможность более гранулярного учета прав: в системе на основе списка контроля доступа администраторам системы необходимо исчерпывающее знание о всех субъектах системы — поскольку это психологически неприемлемо, субъекты обычно агрегируют более общими сущностями — принципалами безопасности
В то же время в мандатных системах более трудно решить следующие проблемы:
· ограничить передачу мандата от одного субъекта другому (такая возможность также может быть и полезным свойством системы)
· отзыв мандатов, особенно выборочный отзыв отдельных прав, а не всех мандатов для какого-то субъекта
Во многих реальных системах используется комбинация обоих подходов: например, в файловой системе Unix ACL используются для первичного контроля прав, а для проверки текущих прав используются мандат, который выдается после первичной авторизации, проверка которого намного эффективнее.
Системы на основе мандата часто используются для создания т.н. "песочниц", например, для выполнения кода, полученных из недоверенных источников — поскольку в такой системе проще реализовать принцип «по умолчанию без доступа»
Реализация системы безопасности
.
Аппаратная платформа предоставляет такие базовые механизмы для поддержки системы безопасности:
· кольца процессора (CPU rings), которые используются в сегментной организации памяти
· привилегированные инструкции (в некоторых платформах)
· рандомизация адресного пространства программы, защита стека и т.п.
Используя эти примитивы ОС выстраивает систему безопасности. Основа этой системы в большинстве ОС:
· это выполнение всех критических операций в ядре ОС и предоставление ограниченного интерфейса к ним через механизм системных вызовов
· резделение пользователей на администраторов (в Unix-системах: особый пользователь root) и обычных пользователей с ограниченными правами доступа к системным каталогам и настройкам.
Unix
История Unix
UNIX появился в 1973 (начал разрабатываться в 1969) в Bell Labs. Первая целевая платформа — миникомпьютеры DEC (PDP-7).
В Unix были созданы такие технологии, как: язык C, оператор pipe (|) для взаимодействия между процессами, интерфейс сокетов BSD и многие другие.
UNIX изначально был условно открытой системой, достаточно удобной для портирования на другие архитектуры. Поэтому довольно быстро появились разные ветки (варианты) Unix'ов. Первой такой веткой (fork'ом) стал Берклевский дистрибутив (BSD) в 1977 году. В то же время, лицензия UNIX не давала возможности неограниченного изменения и модификации системы, с чем были связанны многие юридические конфликты. В конце концов, на данный момент сформировалось несколько закрытых коммерческих версий Unix'а, несколько открытых версий, а также ряд Unix-подобных систем, созданных с нуля (прежде всего, GNU/Linux).
Pис. 12.1. Семейство потомков Unix и Unix-подобных ОС
Основные дистрибутивы Unix
Коммерческие дистрибутивы
Коммерческие версии Unix ведут свою родословную от т.н. Unix System V.
Практически все они прекратили свое развитие. Основные представители:
· SCO UnixWare (прекращен)
· Sun Solaris (прекращен)
· IBM AIX
· HP-UX
На данный момент развивается в качестве ОС для дата-центров только illumos — открытый наследник Sun Solars, который был самой продвинутой и активно изменяющейся версией Unix'а.
Ключевые технологии illumos:
· ФС ZFS
· технолония изоляции и создания т.н. песочниц Solaris Zones
· система интроспекции DTrace
· технология виртуализации Kernel Virtual Machine
Дистрибутивы BSD
Берклевский дистрибутив развивался как альтернатива System V Unix и с момента выхода в свет версии 4.3 Tahoe стал полностью открытым и бесплатным. С дистрибутивами BSD связанна одна из самых распространенных open-source лицензий — лицензия BSD. BSD-версии Unix продолжают активно развиваться.
Представители BSD семейства:
· FreeBSD
· OpenBSD
· NetBSD
· DragonflyBSD
На основе дистрибутива FreeBSD было создано ядро Darwin, которое используется в MacOS X.
GNU/Linux
Linux — это Unix и не Unix — полностью новая система, созданная на основе принципов Unix, как их понимал Линус Торвальдс. Толчком для написания системы стали распространение учебного варианта Unix'а MINIX, созданного Таненбаумом, а также появление процессора Intel 386 с поддержкой плоской сегментной модели, что радикально упростило написание ядра ОС.
Linux обошел другие варианты Unix'а на волне open-source за счет использования наработок движения GNU (компилятор gcc, утилиты core-utils, редактор Emacs и др.) и лицензии GPL, которая требует открытия доработок системы на тех же условиях, что и оригинальной системы.
Linux — это ядро, на основании которого создается дистрибутив — набор системных утилит и других программ, необходимых для работы системы, таких как графическая оболочка, офисные приложения и т.п. Существуют десятки дистрибутивов GNU/Linux, среди которых наиболее распространены ветки Red Hat (Red Hat Enterprise Linux, Fedora, Suse, CentOS) и Debian (Debian, Ubuntu, Mint).
Специфическим дистрибутивом Linux является ОС Google Android.
Принципы Unix
· открытая система (man, POSIX, open source)
· файл-центричность и текст-центричность
o "Small pieces, loosely joined"
o развитые средства IPC
· иерархическая файловая система с примитивной моделью безопасности
· плоское API системных вызовов, основанное на C
o дополнительные возможности спрятаны в ioctl, fnctl, и т.п.
· пользователь root
· модель запуска процессов fork/exec
· развитая система управления зависимостями
Поддержка GUI в Unix
Исторически ядро Unix разрабатывалось без поддержки графического интерфейса, который на тот момент еще не был развит. По мере развития различных вариантов графической аппаратной части в Unix было создано решения для поддержки и работы с ними — протокол X11, разработанный рабочей группой в университете MIT.
Pис. 12.2. Схема взаимодействия в рамках протокола X11
X11 протокол имеет различные реализации:
· xfree86
· X.org
· Wayland
На базе X11 протокола, как правило, строятся более высокоуровенвые графические фреймворки (GUI toolkits). Самые распространенные фреймворки в Unix-среде:
· GTK
· Qt
Оконные менеджеры решают задачу управления интерфейсом приложений в рамках единой концепции (на данный момент принята концепция Рабочего стола или WIMP). Как правило, оконные менеджеры строятся на основе графических фреймворков. Например, самый распространенный менеджер Gnome использует GTK, KDE построен на основе Qt.
Другие оконные менеджеры:
· обычные: Xfce, Sawfish
· плиточные: ion3, XMonad
Управление зависимостями (менеджеры пакетов)
В условиях создания новых приложений с использованием созданной ранее базы программных библиотек, важной и сложной задачей, которую решает любой дистрибутив Unix (а также, на данный момент и среда всех языков программирования), является управление зависимостями. Для этого (почти) каждый дистрибутив Unix имеет специальную программу — пакетный менеджер, который отвечает за ведение базы существующих библиотек и их версий, зависимостей и совместимости между версиями, а также мест хранения исходного или объектного кода, из которых можно загрузить ту или иную версию.
Различают менеджеры зависимостей, которые работают на уровне исходного кода (с его последующей сборкой) и на уровне бинарных файлов.
Самые распространенные пакетные менеджеры:
· менеджеры на основе формата APT в Debian
· менеджеры на основе формата RPM в Red Hat
· BSD ports и система Portage Gentoo Linux
Также, большинство сред языков программирования предоставляют свой особый менеджер пакетов. Например:
· Maven в Java
· RubyGems в Ruby
· NPM в Node.js
Принципы разработки в Unix
В книге "Искусство программирования под Unix" (TAOUP) Эрик Реймонд сформулировал следующие принципы хорошего тона, которые предпочтительно применяются при разработке как самих частей Unix систем, так и программ для Unix:
· Модульности (Modularity): создавать простые части, связываемые чистыми интерфейсами
· Ясности (Clarity): ясные решения лучше хитрых и умных
· Композиции (Composition): создавать программы, которые могут быть связанными с другими программами
· Разделения (Separation): разделять политику и механизм, интерфейс и реализацию
· Простоты (Simplicity): придумывать самое простое решение, добавлять сложность только по необходимости
· Бережливости (Parsimony): создавать большие программы, только когда продемонстрированно, что другие не справятся
· Прозрачности (Transparency): продумывать программы с тем, чтобы сделать интроспецкцию и отладку возможной и максимально простой
· Прочности (Robustness): прочность — это дитя прозрачности и простоты
· Представлений (Representation): вкладывать знания в данные, чтобы логика программы была тупой и надежной
· Наименьшего удивления (Least Surprise): при проектировании интерфейсов всегда нужно выбирать наименее неожиданный вариант
· Тишины (Silence): когда у программы нет ничего удивительного, чтобы сообщить, она не должна сообщать ничего
· Починки (Repair): стараться починить все, что можно, но когда это не удается — падать, падать громко и как можно раньше
· Экономии (Economy): время программиста дорого стоит, его лучше сберечь и потратить машинное время
· Генерации (Generation): по возможности избегать кодирования, когда можно написать программу, которая будет писать другие программы
· Оптимизации (Optimization): прототипировать перед шлифовкой, добиться работы программы перед ее оптимизацией
· Разнообразия (Diversity): не доверять никаким утверждениям о единственном верном пути
· Расширяемости (Extensibility): проектировать на будущее — оно наступит раньше, чем мы думаем
Наряду с фанатами Unix существуют и Unix-ненависники, которые даже написали собственную книгу — Руководство Unix-ненависника.
Вот некоторые типичные претензии к Unix системам:
· Слабая поддержка GUI
· Слабая поддержка сценариев работы обычного пользователя (т.н. Desktop сценарии)
· Недостаточное следование модели “всё – файл”
· Примитивная модель безопасности: простой ACL, пользователь root
· Примитивная файловая система
· Дополнительные возможности спрятаны в ioctl, fnctl, ...
· Устаревший системный язык (C)
Windows
История Windows
Pис. 13.1. Хронология развития Windows
Windows — это семейство ОС, которое развивалось постепенно, начиная с переделки ОС CP/M в ОС MS-DOS. MS-DOS, как и CP/M, был примитивной однопользовательской ОС для только появлявшихся персональных компьютеров. Он был создан в рамках существующих на тот момент аппаратных ограничений этих устройств (16-битная архитектура, малые доступные ресурсы, такие как мощность процессора, объемы памяти и постоянных хранилищ). Изначально эта система должна была загружаться с дискет емкостью порядка 750 Кб, работать в текстовом графическом режиме и управлять памятью до 1 МБ. Система Windows изначально была графической оболочкой поверх MS-DOS.
Вместе с быстрым развитием возможностей ПК начала быстро развиваться и Windows, вскоре упершись в ограничения своей архитектуры. Windows 95/98 стала 32-разрядной версий системы, которая еще не использовала такие стандартные технологии поддержки многопользовательской работы, как разделение на режим ядра и пользователя, вытесняющую многозадачность, ФС с разделением прав доступа и т.п.
Реализацией современных концепций ОС стало ядро Windows NT, которое послужило основой систем Windows XP/7/8/10 и Windows Server.
Pис. 13.2. Архитектура Windows NT
Windows NT — это название современного ядра Windows.
Его основные характеристики:
· разделение на режим ядра и пользователя
· гибридное ядро, включающее микроядро, уровень абстракции устройств и драйверов (HAL) и сервисы ОС, работающие в ядерном режиме (Executive), а также сервисы ОС, работающие в пользовательском режиме: окружение (Environment) и интеграции (Integral)
· поддержка вытесняющей многозадачности
· поддержка SMT/SMP
· ввод-вывод на основе пакетного и асинхронного режимов
Микроядро выполняет следующие функции:
· синхронизация
· планирование выполнения нитей и обработки прерываний
· перехват исключений
· инициализацию драйверов при запуске системы
Исполнительные сервисы ОС (Executive) включают:
· ввод-вывод (в т.ч. взаимодействие с графическими устройствами через интерфейс GDI)
· управление устройствами (в т.ч. питанием, поддержка Plug-n-play утсройств)
· управление объектами ядерного режима
· управление процессами и межпроцессорным взаимодействием
· управление памятью и кешами
· управление конфигурацией (через системный реестр)
· безопасность
Сервисы окружения ядра WinNT поддерживают 3 режима работы:
· Win32-совместимый (с поддержкой MSDOS и Win16 приложений), включающий также оконный менеджер - сервис csrss.exe
· Posix-совместимый (удалено, начиная с win 7)
· OS/2-совместимый (удалено, начиная с win 7)
· поддержка команд bash, (Linux-on-Windows, в экспериментальном дистрибутиве Windows 10)
Ключевые особенности Windows
· привязка к архитектуре x86 (Windows не поддерживает других архитектур, помимо ARM(прекращена))
· GUI-центричность
· Windows API
· Управление конфигурацией через реестр
· Большое внимание обратной совместимости
· Системный язык C++, затем C#
Критика windows
· закрытая система
· проблемы с композицией програм
· проблемы с безопасностью
· непригодность для многих сценариев работы (прежде всего, как высокопроизводительной серверной ОС)
Дата добавления: 2021-05-18; просмотров: 197; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!