POSIX.1e

POSIX.1e — это проект стандарта интерфейса переносимой операционной системы (POSIX), разрабатывавшийся комитетом IEEE 1003.1e для расширения базового стандарта POSIX.1 механизмами безопасности, в первую очередь — списками контроля доступа (ACL) и возможностями (capabilities). Проект был официально отозван в 1997 году, однако его спецификации и идеи легли в основу реализаций в большинстве современных Unix-подобных операционных систем, включая Linux, FreeBSD и Solaris.

История

Предпосылки создания

К началу 1990-х годов базовый стандарт POSIX.1 (IEEE 1003.1) определял минимальный набор системных вызовов и утилит для обеспечения переносимости приложений между Unix-системами. Однако модель безопасности в этом стандарте оставалась примитивной: она основывалась исключительно на классической дискреционной модели (DAC — Discretionary Access Control), где каждый файл имеет владельца, группу и три набора прав (чтение, запись, выполнение) для владельца, группы и всех остальных. Эта модель не позволяла гибко настраивать доступ для нескольких пользователей или групп, что стало критичным для многопользовательских систем и корпоративных сред.

Разработка проекта

В 1992 году рабочая группа IEEE P1003.1e начала разработку расширений безопасности. Параллельно велась работа над проектом POSIX.1f (дополнительные функции для работы с файловыми системами) и POSIX.1g (сетевые протоколы). К 1997 году проект POSIX.1e достиг стадии черновика (Draft 17), но так и не был принят как окончательный стандарт. Причинами отзыва стали:

• Сложность и противоречивость спецификаций;
• Отсутствие консенсуса среди производителей Unix (в частности, Sun Microsystems и IBM продвигали собственные реализации);
• Появление альтернативных моделей безопасности (например, SELinux от NSA).

Наследие

Несмотря на отзыв, спецификации POSIX.1e были опубликованы как «неофициальный стандарт» и широко цитировались. В 2000-х годах большинство Unix-систем внедрили подмножества этих расширений. В Linux ACL и capabilities были добавлены в ядро версии 2.6 (2003 год), а полная поддержка POSIX.1e-совместимых возможностей появилась в glibc 2.3.

Основные компоненты POSIX.1e

Списки контроля доступа (ACL)

ACL позволяют задавать права доступа для произвольного числа пользователей и групп, а не только для одного владельца и одной группы. В POSIX.1e определены два класса ACL:

• Минимальные ACL — содержат три записи: владелец, группа, остальные (аналог классических прав);
• Расширенные ACL — могут включать записи для конкретных пользователей (user), конкретных групп (group), маску (mask) для ограничения прав, а также записи для всех остальных (other).

Каждая запись ACL имеет формат: [тип]:[идентификатор]:[права], где тип — user, group, mask или other. Идентификатор — имя пользователя или группы (или пустое поле для other). Права — трёхсимвольная комбинация rwx.

Пример ACL для файла: `` user::rw- user:alice:r-- group::r-- group:developers:rw- mask::rw- other::--- `` В этом примере владелец имеет чтение и запись, пользователь alice — только чтение, группа developers — чтение и запись, остальные — нет доступа. Маска ограничивает максимальные права для именованных пользователей и групп.

Возможности (Capabilities)

Возможности — это механизм разграничения привилегий, позволяющий предоставить процессу отдельные права суперпользователя (root) без передачи всех полномочий. В POSIX.1e определены три набора возможностей:

• Allowed — максимальный набор возможностей, который может получить процесс;
• Effective — реально активные возможности в данный момент;
• Inheritable — возможности, передаваемые дочерним процессам.

Стандарт включает около 30 возможностей, таких как:

• CAP_CHOWN — изменение владельца файла;
• CAP_NET_BIND_SERVICE — привязка к привилегированным портам (ниже 1024);
• CAP_SYS_ADMIN — широкий набор административных операций.

Дополнительные механизмы

• Trusted I/O (TIO) — механизм для безопасного ввода-вывода, позволяющий приложениям гарантировать, что данные не были подменены;
• Security Labels — метки безопасности для файлов и процессов (предшественник мандатного контроля доступа, MAC);
• Audit — система аудита событий безопасности.

Реализации

Linux

В Linux поддержка ACL на основе POSIX.1e появилась в ядре 2.6 (2003). Для работы с ACL используются утилиты getfacl и setfacl из пакета acl. Возможности реализованы через системные вызовы capget/capset и утилиты getcap/setcap. Однако реализация в Linux не полностью соответствует проекту POSIX.1e: например, отсутствует механизм Trusted I/O, а возможности имеют несколько иной набор (расширенный).

FreeBSD

FreeBSD реализовала ACL на основе POSIX.1e начиная с версии 5.0 (2003). Поддержка возможностей (Capsicum) в FreeBSD отличается от стандарта и ориентирована на изоляцию процессов.

Solaris

Solaris (ныне illumos) реализовал ACL и возможности в полном объёме, близком к проекту POSIX.1e. Система Solaris стала эталонной для многих разработчиков.

Критика и ограничения

• Незавершённость стандарта — проект был отозван, поэтому реализации в разных системах несовместимы;
• Сложность управления — ACL и возможности требуют дополнительных инструментов и обучения администраторов;
• Противоречивость — некоторые спецификации были неоднозначными, что привело к разным интерпретациям;
• Устаревание — в современных системах (например, с SELinux или AppArmor) используются более мощные модели мандатного контроля доступа, которые частично вытесняют дискреционные ACL.

Влияние

POSIX.1e оказал значительное влияние на развитие безопасности в Unix-подобных системах. Его идеи были заимствованы в стандарте NFSv4 ACL, а также в механизмах Windows NTFS. Несмотря на формальную отмену, проект остаётся важным историческим документом, описывающим первую попытку унифицировать расширенные модели доступа в открытых операционных системах.

Источники

• IEEE Std 1003.1e — Draft 17 (1997). «POSIX.1e: Protection, Audit, and Control».
• «POSIX.1e: A Standard for Security Extensions» — статья в журнале ;login:, 1998.
• Документация ядра Linux: Documentation/filesystems/acl.txt.
• FreeBSD Handbook: Chapter 12 — Security.
• «Understanding and Using ACLs in Linux» — IBM DeveloperWorks, 2003.