Свободные инструменты резервного копирования

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

Существенной частью организации процесса резервного копирования является построение отказоустойчивого расширяемого хранилища для хранения резервных копий. Данная тема находится за рамками данной статьи.

В данной статье приводится сравнение свободных средств резервного копирования по материалам [1, 2], а также собственного опыта. Список инструментов, рассматриваемых в статье:

• amanda
• bacula
• backuppc
• duplicity
• rsync
• rsnapshot
• rdiff-backup
• backupninja
• obnam

Проектирование баз данных

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

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

Первые шаги технического руководителя в новой компании

Продукты в современном мире надо проектировать и производить быстро. За первый месяц надо уже практически во всем разобраться:

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

Но сначала.

Программное обеспечение TSF вне ядра

Программное обеспечение TSF вне ядра состоит из доверяемых приложений, которые используются, чтобы реализовать функции безопасности. Обратите внимание на то, что совместно используемые библиотеки, включая модули PAM в некоторых случаях, используются доверяемыми приложениями. Однако, не существует экземпляра, где сама совместно используемая библиотека рассматривается как доверяемый объект. Доверяемые команды могут быть сгруппированы следующим образом.

• Системная инициализация
• Идентификация и аутентификация
• Сетевые приложения
• Пакетная обработка
• Управление системой
• Аудит пользовательского уровня
• Криптографическая поддержка
• Поддержка виртуальной машины

Компоненты исполнения Linux

Компоненты исполнения ядра могут быть разделены на три составляющие части: основное ядро, потоки ядра и модули ядра, в зависимости от того, как они будут выполняться.

• Основное ядро включает код, который выполняется, чтобы предоставить услугу, такую как обслуживание системного вызова пользователя или обслуживание события исключения, или прерывание. Большинство скомпилированного кода ядра подпадает под эту категорию.
• Потоки ядра. Чтобы выполнить определенные стандартные задачи, такие как очистка дисковых кэшей или освобождение памяти, путем выгрузки неиспользованных страничных блоков, ядро создает внутренние процессы или потоки. Потоки запланированы точно так же, как обычные процессы, но у них нет контекста в непривилегированном режиме. Потоки ядра выполняют определенные функции языка C ядра. Потоки ядра размещены в пространстве ядра, и работают только в привилегированном режиме.
• Модуль ядра и модуль ядра драйверов устройств  — фрагменты кода, которые могут быть загружены и выгружены в и из ядра по мере необходимости. Они расширяют функциональные возможности ядра без необходимости перезагружать систему. После загрузки объектный код модуля ядра может получить доступ к другому коду ядра и данным таким же образом, как статически скомпонованный код объекта ядра.

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

Логические компоненты Linux

Ядро состоит из логических подсистем, которые обеспечивают различные функциональные возможности. Даже при том, что ядро  — единственная исполняемая программа, различные сервисы, которые оно предоставляет, могут быть разделены и объединены в разные логические компоненты. Эти компоненты взаимодействуют, чтобы обеспечить определенные функции. Ядро состоит из следующих логических подсистем:

• Файловая подсистема и подсистема ввода-вывода: Эта подсистема реализует функции, связанные с объектами файловой системы. Реализованные функции включают те, которые позволяют процессу создавать, поддерживать, взаимодействовать и удалять объекты файловой системы. К этим объектам относятся регулярные файлы, каталоги, символьные ссылки, жесткие ссылки, файлы, специфичные для определенных типов устройств, именованные каналы и сокеты.
• Подсистема процессов: Эта подсистема реализует функции, связанные с управлением процессами и управлением потоками. Реализованные функции позволяют создавать, планировать, исполнять и удалять процессы и субъекты потоков.
• Подсистема памяти: Эта подсистема реализует функции, связанные с управлением ресурсами памяти системы. Реализованные функции включают в себя те, которые создают и управляют виртуальной памятью, включая управление алгоритмами разбивки на страницы и таблицами страниц.
• Сетевая подсистема: Эта подсистема реализует сокеты UNIX и Интернет-домена, а также алгоритмы, используемые для планирования сетевых пакетов.
• Подсистема IPC: Эта подсистема реализует функции, связанные с механизмами IPC. Реализованные функции включают в себя те, которые упрощают управляемый обмен информацией между процессами, позволяя им совместно использовать данные и синхронизировать их выполнение при взаимодействии с общим ресурсом.
• Подсистема модулей ядра: Эта подсистема реализует инфраструктуру, позволяющую поддерживать загружаемые модули. Реализованные функции включают загрузку, инициализацию и выгрузку модулей ядра.
• Расширения безопасности Linux: Расширения безопасности Linux реализуют различные аспекты безопасности, которые обеспечиваются для всего ядра, включая каркас Модуля безопасности Linux (Linux Security Module, LSM). Каркас LSM служит основой для модулей, позволяющей реализовать различные политики безопасности, включая SELinux. SELinux  — важная логическая подсистема. Эта подсистема реализует функции мандатного управления доступом, чтобы добиться доступа между всеми предметами и объектами.
• Подсистема драйвера устройства: Эта подсистема реализует поддержку различных аппаратных и программных устройств через общий, не зависящий от устройств интерфейс.
• Подсистема аудита: Эта подсистема реализует функции, связанные с записью критических по отношению к безопасности событий в системе. Реализованные функции включают в себя те, которые захватывают каждый системный вызов, чтобы записать критические по отношению к безопасности события и те, которые реализуют набор и запись контрольных данных.
• Подсистема KVM: Эта подсистема реализует сопровождение жизненного цикла виртуальной машины. Она выполняет завершение инструкции, используемое для инструкций, требующих только небольших проверок. Для любого другого завершения инструкции KVM вызывает компонент пространства пользователя QEMU.
• Крипто API: Эта подсистема предоставляет внутреннюю по отношению к ядру криптографическую библиотеку для всех компонентов ядра. Она обеспечивает криптографические примитивы для вызывающих сторон.

Программное обеспечение ядра функций безопасности Linux

Ядро  — это основная часть операционной системы. Оно взаимодействует непосредственно с аппаратными средствами, реализует совместное использование ресурсов, предоставляет общие сервисы для приложений, и предотвращает прямой доступ приложений к аппаратно-зависимым функциям. К числу сервисов, предоставляемых ядром, относятся:

1. У правление выполнением процессов, включая операции их создания, завершения или приостановки и межпроцессоного обмена данными. Они включают:

• Равнозначное планирование процессов для выполнения на ЦП.
• Разделение процессов в ЦП с использованием режима разделения по времени.
• Выполнение процесса в ЦП.
• Приостановка ядра по истечениии отведенного ему кванта времени.
• Выделение времени ядра для выполнения другого процесса.
• Перепланирование времени ядра для выполнения приостановленного процесса.
• Управление метаданными, связанными с безопасностью процесса, такими как идентификаторы UID, GID, метки SELinux, идентификаторы функциональных возможностей.

2. Выделение оперативной памяти для исполняемого процесса. Данная операция включает в себя:

• Разрешение, выдаваемое ядром для процессов, на совместное использование части их адресного пространства при определенных условиях; однако, при этом ядро защает собственное адресное пространство процесса от внешнего вмешательства.
• Если система испытывает нехватку свободной памяти, ядро освобождает память путем записи процесса временно в память второго уровня или раздел подкачки.
• Согласованное взаимодействие с аппаратными средствами машины, чтобы установить отображение виртуальных адресов на физические адреса, которое устанавливает соответствие между адресами, сгенерированными компилятором, и физическими адресами.

3. Обслуживание жизненного цикла виртуальных машин, которое включает:

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

4. Обслуживание файловой системы. Это включает в себя:

• Выделение вторичной памяти для эффективного хранения и извлечения пользовательских данных.
• Выделение внешней памяти для пользовательских файлов.
• Утилизация неиспользованного пространства для хранения данных.
• Организация структуры файловой системы (использование понятных принципов структурирования).
• Защита пользовательских файлов от несанкционированного доступа.
• Организация контролируемого доступа процессов к периферийным устройствам, таким как терминалы, лентопротяжные устройства, дисководы и сетевые устройства.
• Организация взаимного доступа к данным для субъектов и объектов, предоставление управляемого доступа, основанного на политике DAC и любой другой политике, реализуемой загруженной LSM.

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

Программы с привилегиями, связанными с программным обеспечением Linux

Примеры программ, работающих с привилегиями ,связанными с программным обеспечением:

• Программы, исполняемые системой, например, демоны cron и init.
• Программы, которые выполняются доверенными администраторами в рамках задач системного администрирования.
• Программы, которые работают с привилегированными идентификаторами, выполняя программные файлы SUID.

Все программное обеспечение, которое работает с привилегиями, связанными с аппаратными средствами или привилегиями, связанными с программным обеспечением, является частью функций безопасности исследуемого ПО (TOE Security Functions, TSF).
В системе, которая администрируется надлежащим образом, непривилегированное программное обеспечение проверяется политикой безопасности системы и не имеет никаких средств обхода механизмов, обеспечивающих ее осуществление. Этому непривилегированному программному обеспечению нельзя доверять всегда; такое ПО упоминается как недостоверное программное обеспечение. Доверяемые процессы, которые не реализуют функции безопасности, должны быть защищены от несанкционированного вмешательства, с помощью функций безопасности Linux. Им необходимо доверять, чтобы не выполнить какую-либо функцию, которая нарушает политику безопасности Linux.

Функциональные возможности Linux

У ядра Linux имеется платформа для реализации привилегий, связанных с программным обеспечением, для многих различных функций, обеспеченных ядром Linux при помощи функциональных возможностей. Эти функциональные возможности, которые основываются на еще не получившем официального утверждения варианте стандарта POSIX.1e и многих других дополнительных возможностях, определенных и полностью задокументированных в файле include/linux/capability.h, позволяют разбить полномочия программного обеспечения ядра, связанного с нулевым идентификатором пользователя в ряд дискретных полномочий на основе предпринимаемых действий.
Функциональные возможности связывают с идентификаторами пользователей следующим образом:

• Если исполняется приложение SUID от имени владельца, являющимся обладателем учетной записи root, то для данного процесса включены все функциональные возможности.
• Если семейство системных вызовов set*uid используется для изменения UID процесса вызова на ID, не равный 0, то для такого процесса все функциональные возможности заблокированы.
• У процессов, изначально запущенных как подпроцессы учетной записью root, имеется весь набор функциональных возможностей.
• У процессов, изначально запущенных как подпроцессы любыми учетными записями, отличными от root, отсутствует набор функциональных возможностей.

Привилегия, связанная с программным обеспечением
Ядро ограничивает использование многих системных вызовов или функциональных областей, вызванных системными вызовами процессов, которые обладают определенными функциональными возможностями. Если вызывающий процесс не обладает необходимой возможностью, выполнение затронутой области кода будет запрещено, и вызывающей стороне будет возвращена ошибка EPERM.
Например, если процесс пытается создать специальный файл устройства, инициализируя системный вызов mknod, ядро выполняет соответствующую проверку, чтобы удостовериться, что процесс может создавать специальные файлы устройств; при этом проверяется, что процесс обладает функциональной возможностью CAP_MKNOD. В отсутствие специальных модулей ядра, которые определяют и используют соответствующие функциональные возможности (что, например, имеет место для объекта оценки), при проверке функциональных возможностей система возвращается назад, к предоставлению привилегий, связанных с программным обеспечением уровня ядра, на основе пользовательского идентификатора процесса.
Полный перечень всех функциональных возможностей, включая их описания, содержится в файле исходного кода ядра Linux include/linux/capability.h.

Политика MAC модуля обеспечения защиты Linux SELinux

Совместно с мандатным контролем доступа, реализованным с SELinux LSM, SELinux LSM MAC представляет собой политику безопасности системы, которая отличается от политики владельца в DAC, определяющей, кому к какой информации должен быть предоставлен доступ.
Политика MAC, предоставленная SELinux, опирается на два вида политики:

• Принудительное присвоение типов (Type Enforcement, TE), которое используется, чтобы реализовать ролевую модель управления доступом
• Многоуровневая система обеспечения безопасности (Multi-Level Security, MLS) с реализацией иерархической политики маркировки Bell-LaPadula.

Субъекты и объекты в Linux – это обычные процессы и потоки ядра. Они оба представляются структурой task_struct. Потоки ядра исполняются только в привилегированном режиме и не ограничиваются политикой MAC. Все именованные объекты, такие как обычные файлы, текстовые и блочные файлы, каталоги, сокеты и объекты IPC находятся под контролем политики MAC. Политика MAC может управлять не только именованными объектами, но также доступом к определенным структурам данных ядра, таким как дескрипторы файла, сообщения IPC и файловые системы, чтобы позволить определять политику безопасности системы на более детальном уровне.

Атрибуты безопасности субъекта и объекта, также называемые контекстом безопасности SELinux, имеют тот же самый формат. Во внешнем формате, удобном для восприятия пользователем, контекст безопасности - последовательность символов ASCII. Из соображений производительности, ядро преобразовывает эту последовательность в 32-битное целое число на этапе исполнения; однако, при описании механизма осуществления и политики безопасности контекст безопасности представлен в формате ASCII. Контекст безопасности состоит из четырех разделенных двоеточиями компонентов. Они соответствуют пользователю, роли, типу и диапазону MLS субъекта или объекта/

• Пользователь: компонент пользователя – имя пользователя SELinux.
• Роль: компонент роли – роль SELinux, соответствующая субъекту или объекту. Для субъектов роль используется, чтобы осуществить ролевую модель управления доступом, позволяя роли управлять доступом к доменам. Для объектов ролевой компонент не используется и является всем object_r.
• Тип: поле типа представляет тип объекта или домен субъекта. Домены и типы - эквивалентные классы для процессов и ресурсов, соответственно. Предоставление доступа в ядре осуществляется на основании на типа объекта и домена субъекта.
• Диапазон маркеров MLS: диапазон маркеров MLS содержит два полных маркера MLS. Они размещены так, что нижний маркер располагается слева, а верхний маркер, который является преобладающим над нижним маркером, – справа. Два маркера разделены длинным тире и формируют диапазон маркеров. Для субъектов нижний маркер диапазона соответствует действующему маркеру MLS субъекта, в то время как верхний маркер соответствует разрешениям на доступ для субъекта. Уровень доступа субъекта соответствует полномочиям пользователя, от имени которого действует субъект.

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

• L1 равен L2 (уровни равны, наборы категорий совпадают),
• L1 переопределяет L2 (уровень L1 >= уровню L2, набор категорий L2 совпадает или является подмножеством набора категорий L1),
• L1 переопределяется L2 (уровень L2 >= уровню L1, набор категорий L1 совпадает или является подмножеством набора категории L2),
• L1 несравним с L2 (L1 и L2 не равны, и ни один из них не переопределяет другой).

Хранение атрибутов Атрибуты SELinux хранятся:

• в структуре процесса task_struct для субъектов;
• в структуре данных, размещенной на диске и в ядре, для объектов файловой системы;
• в структуре данных kern_ipc_perm для объектов IPC системы System V;
• в структуре данных sock для сокетов;
• в структуре xfrm_state для сокетов netlink;
• в структуре данных key для ключей.

SELinux приводит недействительные или неправильные контексты к контексту system_u:object_r:unlabeled_t:s0.
Правила контроля доступа Реализация управления доступом MAC основана на принудительном присвоении типов (Type Enforcement, TE). TE обеспечивает определяемое на более детальном уровне управление доступом к субъектам и объектам.
TE и правила политики MLS определяются с политикой SELinux. Правила TE определяются как проверки управления доступом, тогда как политика MLS определяется как ограничение, накладываемое поверх TE. Поэтому полная проверка управления доступом выполняется за три логических шага, следующим образом:

1. Первой выполняется проверка DAC, использующая атрибуты DAC, за которой следует
2. проверка TE, использующая домены и типы контекста безопасности SELinux, за которой следует
3. проверка политики MLS Bell-LaPadula, использующая диапазон маркеров MLS контекста безопасности SELinux.

Каждая из выполняемых проверок неавторитетная. Таким образом, права доступа только сильнее ограничиваются на каждой следующей стадии; отказ в праве доступа, установленный политикой DAC, не может быть переопределен TE, а отказ в праве доступа, установленный TE, не может быть переопределен MLS.
Привилегии, связанные с программным обеспечением для политики MAC реализуются с использованием домена защиты процесса и правил политики безопасности, связанных с этим доменом. Например, процессам, исполняющимся в домене init_t, предоставлен доступ на чтение к объектам, маркер контекста безопасности которых преобладает над маркером контекста безопасности процесса. Это переопределение определяется атрибутами домена. Правило политики устанавливает доступ домена к типу с переопределением, привязанным к атрибуту домена. Например, следующее правило политики может использоваться, чтобы разрешить процессу переопределять ограничение Bell-LaPadula, запрещающее доступ на чтение, когда этот процесс выполняет попытку прочитать обычный файл:

Листинг 3.1: ограничение политики MLS SELinux
mlsconstrain { file } { read } (( l1 dom l2) or (t1 == mlsfileread ))
Приведенный выше оператор устанавливает политику безопасности, при которой маркер l1 (принадлежащий субъекту), должен преобладать над над маркером l2 (принадлежащим объекту) для операции чтения данных, чтобы разрешить доступ на чтение, если у домена процесса нет атрибута mlsfileread.
Политика безопасности системы для различных типов субъектов и объектов приводится в функциональных описаниях данных субъектов и объектов.
В дополнение к атрибутам процесса, которые могут переопределять права доступа, ядро Linux обладает следующей возможностью: CAP_MAC_OVERRIDE. Если процесс обладает этой возможностью, он может обойти принудительное выполнение всех политик SELinux.

DAC

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

Субъекты и объекты в Linux  — это регулярные процессы и потоки ядра. Они представлены структурой task_struct. Потоки ядра исполняются только в привилегированном режиме, и не ограничены политикой DAC. Все объекты-хранилища, такие как обычные файлы, символьные и блочные файлы, каталоги, сокеты, объекты IPC и кольца ключей ядра, находятся под контролем политики DAC.
Атрибуты субъектов, используемые для реализации политики DAC, включают в себя UID процесса, GID, дополнительные группы, и полномочия процессов. Эти атрибуты хранятся в структуре task_structure процесса; к ним выполняются системные вызовы. Атрибуты объектов, используемые для реализации политики DAC, включают в себя следующее: владелец, владелец группы, биты полномочий и списки управления доступом POSIX.1e (Access Control Lists, ACLs) для объектов файловой системы. Эти атрибуты хранятся в ядре и, для размещенных на диске файловых систем, в индексном дескрипторе файла, находящемся на диске.
Правила контроля доступа DAC определяют, каким образом определенный процесс с соответствующими атрибутами безопасности DAC может получить доступ к объекту с набором атрибутов безопасности DAC. Кроме того, правила управления доступом DAC также определяют, как и при каких условиях происходит изменение значений атрибутов безопасности для субъектов и объектов.
Привилегии, связанные с программным обеспечением для политики DAC основываются на возможностях CAP_DAC_OVERRIDE, CAP_DAC_READ_SEARCH, которые могут быть присвоены процессу. Процессу, обладающему этими возможностями, предоставляют привилегии, связанные с программным обеспечением применительно к DAC, поскольку при этом предоставляются возможности обойти политики контроля доступа системы.

Привилегии, связанные с программным обеспечением Linux

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

• Дискретное управление доступом, осуществляемое с использованием объектов-хранилищ.
• Механизмы проверки безопасности на основе полномочий, ограничивающие выполнение системных вызовов или подмножеств системных вызовов только вызывающими сторонами, имеющими соответствующую возможность.
• Проверки прав доступа модулем обеспечения защиты Linux (Linux Security Module, LSM)  — политики DAC реализованы с использованием модулей LSM. При доступе к именованным объектам, вначале применяются политики DAC, а проверки прав доступа LSM применяются только в том случае, если DAC разрешает доступ. Ядро реализует привилегии, связанные с программным обеспечением, для политики DAC.

Кроме того, модуль SELinux LSM и его политика MLS совместно реализуют привилегии, связанные с программным обеспечением. Помимо управления доступом, у привилегий, связанных с программным обеспечением, имеются другие функции: а именно, возможности предоставить их определенным программным приложениям (эти функции называются полномочиями).
На рисунке ниже показана схема доступа к объекту файловой системы, а также объекту IPC, и реализация управления доступом. Только ядро может соединить приложения пространства пользователя с объектами файловой системы или с объектами IPC, поскольку у пространства пользователя отсутствует прямой доступ к ячейкам запоминающего устройства.

Eправление доступом используется каждый раз, когда субъект пытается получить доступ к объекту-хранилищу. И субъекты, и объекты имеют атрибуты безопасности, которые используются политикой DAC и политикой управления доступом, реализуемыми LSM. Ядро определяет существующие права доступа на основании этих атрибутов и правил контроля доступа. Если доступ предоставлен политикой DAC, вызывается специальный обработчик прерываний LSM, чтобы оценить доступ на основе загруженного модуля LSM. То, какой LSM загружен, определяется конфигурацией исследуемой системы.

Режим виртуализации Linux

Если исследуемая система используется в качестве хост-системы для виртуализации Kilobyte Virtual Machine (KVM), в дополнение к двум упомянутым выше режимам используется третье состояние привилегий: режим гипервизора. Режим гипервизора использует дополнительную поддержку аппаратных средств, обеспеченную процессором. С режимом гипервизора доступны регистры процессора, которые не доступны в других двух состояниях. При помощи этих регистров реализован другой уровень трансляции адресов памяти. Кроме того, при существовании такой возможности, используется виртуализация адресного пространства ввода-вывода. Ядро Linux использует этот режим, когда включен режим виртуализации KVM. В этом случае все ядро Linux работает в режиме гипервизора.

Обычные процессы при этом все еще работают в непривилегированном режиме. Для процессов непривилегированного режима ядро Linux ведет себя так же, как если бы ядро работало в привилегированном режиме. Кроме того, процессы могут также использовать привилегированный режим, реализованный посредством KVM, чтобы реализовать гостевую операционную систему. С точки зрения ядра Linux гостевая система  — не что иное как регулярный процесс, в котором части этого процесса выполняются, добавляя функциональные возможности виртуализации процессора.

Уровни привилегий связанных с аппаратными средствами Linux

Понятие привилегии на примере процессоров на базе Intel или AMD реализуется таким образом: ключевым объектам, распознанным процессором, присваиваются значения от 0 до 3. Это значение называют уровнем привилегий. Следующие объекты, распознанные процессором, содержат уровни привилегий:

• Дескрипторы содержат поле, названное уровнем привилегий дескриптора (Descriptor Privilege Level, DPL).
• Селекторы содержат поле, названное уровнем привилегий инициатора запросов (Requestor Privilege Level, RPL). RPL предназначен для того, чтобы представлять уровень полномочий процедуры, которая порождает селектор.
• Внутренний регистр процессора записывает текущий уровень полномочий (CPL). Обычно CPL равен DPL сегмента, который в настоящее время выполняется процессором. CPL изменяется, когда управление передается сегментам с другими значениями DPL. Рисунок ниже показывает, каким образом данные уровни привилегий могут быть интерпретированы как уровни защиты. В центре расположены сегменты, содержащие наиболее критичное программное обеспечение, обычно это ядро операционной системы. Внешние уровни предназначены для сегментов менее критичного программного обеспечения.

Ядро Linux, как и большинство других ядер операционных систем, подобных UNIX, использует только два из этих режимов выполнения. Режим с самым высоким уровнем привилегий, с уровнем привилегий процессора 0, соответствует привилегированному режиму; режим с самым низким уровнем привилегий, с уровнем привилегий процессора 3, соответствует непривилегированному режиму. Непривилегированный и привилегированный режимы, которые поддерживаются всеми процессорами, реализуют привилегии, связанные с аппаратными средствами, следующим образом:

• Когда процессор находится в привилегированном режиме, у программы есть привилегии, связанные с аппаратными средствами, потому что она может получить доступ и изменить любые адресуемые ресурсы, такие как память, таблицы состояний страниц, адресное пространство ввода-вывода и регистры управления памятью. Это не возможно в непривилегированном режиме.
• Когда процессор находится в привилегированном режиме, у программы есть привилегии, связанные с аппаратными средствами, потому что она может выполнить определенные привилегированные инструкции, которые не доступны в непривилегированном режиме. Таким образом любой код, который работает в привилегированном режиме, выполняется с привилегиями, связанными с аппаратными средствами. Программное обеспечение, которое работает с привилегиями, связанными с аппаратными средствами, включает:
  1. Часть ядра Linux, загружаемая в память целиком. Оно составляет значительную часть программного обеспечения, которое осуществляет управление памятью, файловый ввод-вывод и управление процессами.
  2. Отдельно загружаемые модули ядра, такие как различные модули драйверов устройства. Модуль ядра  — объектный файл, код которого может быть соединен (прилинкован) и отсоединен (отлинкован) от ядра на этапе исполнения. Код модуля ядра выполняется в ядре, как любая другая статически скомпонованная функция ядра.

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

1. PowerPC. Эта архитектура процессора поддерживает три режима исполнения, идентифицированные битом PR (бит 49) и битом HV (бит 3) регистра состояния машины (Machine State Register, MSR) процессора. Значения 0 и для битов PR и HV указывают режим выполнения гипервизора. Битовое значение HV, равное 1 и битовое значение PR, равное 0, задают режим исполнения супервизора, или ядра. Битовое значение HV, равное 1, и битовое значение PR, равное 1, задают пользовательский режим исполнения.
2. SystemZ Системы System Z также поддерживают два режима исполнения, идентифицированные битом задачного режима (бит 15) регистра состояния программы (Program Status Word, PSW) процессора. Значение 0 указывает режим выполнения супервизора, или ядра, значение 1 указывает задачный режим, или пользовательский режим исполнения.
3. Процессоры ARM работают в различных режимах: пользовательском, режиме быстрого прерывания, режиме прерывания, режиме супервизора, режиме аварийного прерывания и системном режиме. У каждого режима есть свой собственный стек и среда, в которой он существует. В руководствах ARM эти режимы указаны как различные, однако эти различия касаются не области, связанной с их уровнями привилегий, а их целей. В ARM есть по существу два уровня полномочий: в руководствах они называются привилегированные режимы и непривилегированные режимы. Из упомянутых выше режимов, пользовательский режим - единственный непривилегированный режим, в то время как все остальные - привилегированные режимы для данной архитектуры. Эти режимы  — просто состояния, в котором находится процессор, в случае определенного типа исключения, или определенного типа прерывания (IRQ).

• Режим супервизора  — стандартный режим работы ядра, в котором, как ожидается, он будет работать.
• Системный режим не переключается на ни на какой общедоступный вектор. Он похож (на основании описания, приведенного в руководстве, и факта, что ни одно из определенных прерываний фактически не переключается в системный режим) на прерывание системного управления #SMI (System Management Interrupt), которое переключается в режим системного управления на персональном компьютере. После переключения в системный режим ядро будет обрабатывать программное прерывание (SWI), затем переключится в пользовательский режим.
• В режим аварийного прерывания процессор переключается в случае, аналогичном случаю ошибки страницы в архитектуре x86. Процессор переключается в привилегированный режим, а именно в режим аварийного прерывания, упомянутый выше. Большинство ядер ARM просто принимает во внимание факт, что процессор находился в режиме аварийного прерывания при входе в ядро, затем переключаются на режим супервизора и обрабатывают исключение.
• Режимы прерывания и быстрого прерывания  — почти одно и то же, за исключением того, что режиму быстрого прерывания FIQ назначается его собственный набор регистров (регистры фактически переключаются с вызывающей стороны, однако, их имена все еще сохраняются (r8, например, все еще будет называться r8 в вашей сборке; однако вы должны принимать во внимание, что если в регистре r8 в непривилегированном режиме содержалась информация, вы не сможете считать те же самые данные из регистра r8 в режиме FIQ); таким образом, обеспечивается возможность выполнения обработчиков IRQ, без необходимости полного сохранения контекста. По существу, как и в x86, в рассматриваемой архитектуре есть часть аппаратных средств, которые могут быть сконфигурированы ядром. Ядро, у которого есть только 7 векторов и два из них выделены только для прерываний IRQ, выдаст номер IRQ одного из двух векторов IRQ (векторов прерываний IRQ или быстрых прерываний FIQ). Для устройства, сконфигурированного таким образом, что оно отправляет сигналы IRQ на вектор IRQ, процессор, получив сигнал прерывания на векторе IRQ, переключится в привилегированный режим в состоянии режима IRQ. Для прерывания, полученного на векторе быстрых прерываний (FIQ), процессор переключится в привилегированный режим, но в состоянии режима FIQ.
• В неопределенный режим процессор переключается при возникновении на ЦПУ неопределенного исключения.

Принципы идентификации TSF

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

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

Файл может быть включен в TSF как следствие одной или нескольких из следующих причин:

• Он содержит код, такой как ядро, модуль ядра и драйверы устройств, который работает в привилегированном аппаратном состоянии процессора.
• Он относится к реализации политики безопасности системы.
• Он предоставляет разрешение на SUID или SGID привилегированному пользователю (например, учетной записи root) или группе пользователей.
• Он предоставляет одну или несколько возможностей переопределить установленные системой правила безопасности для пользователя, осуществляющего вызов.
• Он запущен как демон, выполняющийся с полномочиями пользователя root или с системным UID / GID (например, процесс, запущенный как /etc/rc.d/init.d).
• Он представляет собой программное обеспечение, которое должно функционировать определенным образом, чтобы поддерживать механизмы безопасности системы.
• Он требуется для выполнения функций системного администрирования.
• В его состав входят данные TSF или конфигурационные файлы.
• В его состав входят библиотеки, связанные с программами TSF.
• Он запущен как приложение с полномочиями, отличными от полномочий вызвавшего его пользователя; например, с использованием таких механизмов как udev, PolicyKit, modprobe, или даже ядра.
• Он предоставляет одну или более возможностей переопределения MLS для вызвавшего его пользователя.

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

• Добавление модулей ядра не разрешено.
• Устанавливаемое программное обеспечение может изменить конфигурацию (например, биты режима) таким образом, чтобы программа не могла нарушить политику безопасности.
• Добавление программ с включенным битом SUID с UID пользователя root или системным UID.
• Добавление программ с включенным битом SGID с GUID пользователя root или системным GUID.
• Дополнение битов, отвечающих за возможности программ, включено.
• Добавление демонов, выполняющихся под учетной записью root или системным UID / GID.
• Изменения набора правил для платформ, которые позволяют порождать процессы с различными полномочиями, такими как udev или PolicyKit.
• Добавление программ с возможностями переопределения MLS.

Техническое собеседование

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

Работа и администрирование системы Linux

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

В исследуемой системе имеются команды, которые могут использоваться для добавления, изменения и удаления учетной записи пользователя. Кроме того, в исследуемой системе существуют команды для добавления, изменения, и удаления группы пользователей из системы, или для настройки элементов политики безопасности системы. Эти команды используют параметры для того, чтобы установить или изменить различные значения параметров для учетных записей, групп и политики безопасности. Команды изменяют соответствующие базы данных TSF; это гораздо более безопасный способ, чем обновление базы данных аутентификации вручную. Обратитесь к соответствующим страницам справочника по командам системы, чтобы получить подробную информацию о том, как создать, настроить права и поддерживать пользователей и группы.

Интерфейсы TSF

Интерфейсы TSF включают локальные интерфейсы, предоставляемые каждым узловым компьютером и сетевыми клиент-серверными интерфейсами, предоставляемыми парами узловых компьютеров. Локальные интерфейсы, предоставляемые каждым отдельным узловым компьютером, включают следующие интерфейсы ядра:

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

2. Несмотря на то, что с технической точки зрения следующие интерфейсы ядра представляют собой семантическое расширение системных вызовов open, ioctl или системных вызовов, связанных с сокетами, их нужно считать независимыми интерфейсами во время анализа безопасности:

• Файлы устройства: файлы устройства разрешают прямой доступ к аппаратным ресурсам. Доступ устанавливается на чтение, запись и/или исполнение функции mmap, или вызов ioctls для реализации более определенных механизмов доступа. Кроме того, некоторое ограниченное число файлов устройства предоставляют доступ к внутренним структурам данных ядра, используя семантику файловой системы, а также ioctls.
• Виртуальные файловые системы: виртуальные файловые системы обеспечивают доступ к внутренним структурам данных ядра, используя семантику файловой системы. Доступ ограничен следующими операциями: чтение, запись и/или вызов функции mmap.
• Сетевые сокеты, использующие протокол AF_NETLINK: сокеты netlink обеспечивают доступ к внутренним структурам данных ядра используя сетевую семантику. Доступ ограничен операциями отправки и/или получения информации.
• Сетевые сокеты, использующие протокол PF_KEY: сокеты PF_KEY используются для взаимодействия с логикой преобразования сетевых пакетов внутри ядра.
3. Все анализаторы/синтаксические анализаторы сетевых протоколов, реализованные ядром.

Следующий список содержит протоколы, доступные в исследуемой конфигурации:
 — Ethernet
 — ARP
 — Семейство протоколов TCP/IP
 — Маркированная передача с использованием протоколов IPSec
 — CIPSO

Следующие интерфейсы реализованы доверенными процессами в пространстве пользователя:

• Сетевые интерфейсы, предоставляемые парами узлов вычислительной сети SSHv2 и IKEv1
• Символьные массивы argv и envp, которые являются параметрами системного вызова execve. Эти два массива могут быть определены выполняемым приложением. Обратите внимание на то, что ряд переменных окружения, которым можно предоставить использование envp, реализованы библиотеками, которые обычно загружаются большинством, если не всеми, приложениями (например, библиотека C).
• Файлы, являющиеся частью базы данных TSF, которые определяют параметры конфигурации, используемые функциями безопасности.
• Интерфейсы межпроцессного взаимодействия, экспортированные приложением.
• Вызовы гипервизора, а также имитация и эмуляция инструкции, реализованная ядром Linux для поддержки среды виртуализации KVM. Это включает имтиацию и эмуляцию аппаратных средств, поддерживаемые ядром Linux.

Интерфейсы, которые не рассматриваются как интерфейсы TSF:

1. Интерфейсы между процессами, не относящимися к TSF, и используемыми аппаратными средствами. Как правило, пользовательские процессы не взаимодействуют через интерфейс непосредственно с аппаратными средствами; исключения составляют процессор, USB, соединения с параллельным портом, соединения с последовательным портом и аппаратное обеспечение машинной графики.

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

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

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

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

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

4. В случае, если вычислительная среда обеспечивает среду виртуализации, такую как z/VM или PR/СМ в системах s390x или POWER LPAR в системах IBM POWER, спроектированные интерфейсы гипервизора среды виртуализации (как вызовы гипервизора) не рассматривают как интерфейсы TSF, т.к. они недоступны непривилегированным процессам в задачном режиме работы вычислительной системы и не реализуют функции безопасности. Следует особо отметить, что функциональные возможности гипервизора, реализованные ядром Linux и его интерфейсами, не относится к рассматриваемому здесь случаю.

5.Состояние режима системного управления (SMM, System Management Mode) процессоров, основанных на архитектуре Intel, не относится к области безопасности, поскольку программное обеспечение, выполняющееся в этом состоянии, не реализует функции безопасности. Кроме того, непривилегированный код не может получить доступ или изменить программное обеспечение, выполняющееся в этом состоянии процессора.

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

Политика безопасности Linux

Пользователь  — авторизованное лицо, обладающее учетной записью. Пользователи могут использовать систему одним из следующих способов:

• Взаимодействуя непосредственно с системой через сеанс в консоли (в этом случае пользователь может использовать дисплей, предоставленный в качестве физической консоли).
• Взаимодействуя непосредственно с системой через сеанс в терминале с последовательным доступом.
• Посредством отложенного выполнения заданий, используя механизм cron.
• При помощи служб различных приложений, получая доступ к этим службам локально или удаленно.
• Используя среды виртуальных машин, получая доступ к этим средам локально или удаленно.

Пользователь должен выполнить вход в локальной системе, чтобы получить доступ к защищенным ресурсам системы. После аутентификации пользователь может получить доступ к файлам или выполнить программы на локальном компьютере, либо выполнить сетевые запросы к другим компьютерам в системе. Единственные субъекты в системе  — процессы. Процесс состоит из адресного пространства и контекста исполнения. Процесс ограничен компьютером; не существует никакого механизма, позволяющего диспетчеризировать процесс, чтобы запустить его удаленно (по TCP/IP) на другом узле. У каждого процесса есть идентификатор процесса (PID), который уникален на локальном компьютере, где выполняется процесс, однако идентификатора процессов не уникальны в пределах всех систем. Например, у каждого узла в системе есть процесс init, идентификатор которого PID=1. Далее в этой статье объясняется, как родительский процесс создает дочерний процесс, создавая его клон с помощью системного вызова clone, fork или vfork; дочерний элемент тогда может использовать системный вызов execve, чтобы загрузить новую программу.

Объекты  — пассивные хранилища данных. В исследуемой системе определены три типа объектов: именованные объекты, которые являются ресурсами, например файлы и объекты IPC, которыми могут управлять многочисленные пользователи, использующие соглашение о присвоении имен, определенное в интерфейсе TSF;

• объекты-хранилища  — объекты, которые поддерживают доступ на чтение и на запись для многих субъектов, не являющихся доверенными
• общедоступные объекты, которые являются объектами, к которым предоставлен публичный доступ на чтение для субъектов, не являющихся доверенными, предоставлен доступ на запись только для доверенных субъектов.

Согласно этим определениям, все именованные объекты также могут быть классифицированы как объекты-хранилища, но не все объекты-хранилища являются именованными объектами.

Система Linux реализует политику дискретного контроля доступа (DAC) для всех именованных объектов и политику повторного использования объектов для всех объектов-хранилищ. Реализация политики DAC означает ее различное применение к различным классам объектов, во всех случаях в основе этой политики лежат идентификационная информация пользователя (пользовательский идентификатор) и членство пользователя в группах, связанное с иднтифиатором пользователя.

В дополнение к политике DAC, Linux также осуществляет политику MAC для всех именованных объектов. Политика DAC осуществляется первой, а политика MAC применяется, только если DAC не запрещает разрешенные ею операции. Политика MAC не авторитетная, т.е. отказ в доступе, определенный политикой DAC, не может быть переопределен политикой MAC. Реализация политики MAC, означает ее различное применение к различным классам объектов; во всех случаях в основе этой политики лежат данные о домене пользователя и типе объекта.

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

Исследуемая система использует как аппаратный, так и программный механизмы защиты данных.

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

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

Пользователи должны войти в систему на локальном узле, прежде чем они смогут получить доступ к любым именованным объектам на этом узле. Некоторые службы, такие как SSH, чтобы получить приглашение командного процессора на другом узле или ftp, передать файлы между узлами в распределенной системе, требуют, чтобы пользователь повторно ввел данные аутентификации для доступа к удаленному узлу. Linux разрешает пользователю изменять пароли (при этом новые пароли должны соответствовать инструкциям усиленной защиты для пароля), изменять идентификационные данные, ставить в очередь на отложенное выполнение пакетные задания и выходить из системы.

Архитектура системы обеспечивает самозащиту TSF и механизмы изоляции процессов.

Сервисы системы Linux

Каждый компьютер в системе может предоставлять следующие службы:

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

Существуют различие между локальными службами, которые имеются на каждом локальном компьютере, и сетевыми службами.

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

Сетевые службы, такие как SSH или ftp, включают клиент-серверную архитектуру и сетевой протокол уровня служб. Клиент-серверная модель разделяет программное обеспечение, которое предоставляет службы, на клиентскую часть, которая отправляет запрос к серверу, и серверную часть, которая выполняет запрос, обычно на другом компьютере. Протокол обслуживания служит интерфейсом между клиентом и сервером.

Например, пользователь А может войти в систему на узле 1, и затем использовать SSH, чтобы войти в систему на узле 2. На узле 2, пользователь А зарегистрирован с удаленного узла.

На узле 1, когда пользователь использует SSH, чтобы войти в систему узла 2, клиент SSH на узле 1 выполняет запросы протокола к серверному процессу SSH на узле 2. Серверный процесс использует запрос от имени пользователя А, запускает запрашиваемую службу, если это возможно, и возвращает результаты клиентскому процессу, отправившему запрос.

Кроме того, заметьте, что сетевой клиент и сервер могут быть размещены на одном и том же хосте. Например, когда пользователь В использует SSH, чтобы войти в систему, размещенную узле 2, клиентский процесс пользователя открывает SSH-соединение с серверным процессом SSH на том же узле. Несмотря на то, что этот процесс запущен на локальном узле, он отличается от локальных служб, потому что использует сетевые протоколы.