Модель безопасности UID

Модель безопасности UID — это концепция управления доступом и идентификации, основанная на использовании уникальных идентификаторов (UID, от англ. Unique Identifier) для каждого субъекта (пользователя, процесса, устройства) и объекта (файла, ресурса, сессии) в компьютерной системе. Модель предполагает, что каждому элементу системы присваивается уникальный числовой или символьный код, который служит основой для принятия решений о разрешении или запрете операций. UID-модель является фундаментальным элементом дискреционного управления доступом (DAC) и обязательного управления доступом (MAC) в операционных системах, базах данных и сетевых протоколах.

История и происхождение

Концепция уникальных идентификаторов восходит к ранним многопользовательским операционным системам, таким как Unix, разработанная в AT&T Bell Laboratories в 1970-х годах. В Unix каждому пользователю присваивался числовой UID (например, 0 для суперпользователя root), который хранился в файле /etc/passwd. Это позволяло системе разграничивать права доступа к файлам и процессам на основе идентификатора владельца. Позднее модель была расширена до групп (GID) и сессий (SID).

В 1980-х годах модель UID была адаптирована для сетевых протоколов, таких как NFS (Network File System), где UID использовался для аутентификации удалённых пользователей. С развитием Windows NT корпорация Microsoft внедрила аналогичную концепцию — Security Identifier (SID), которая выполняет ту же функцию, но имеет более сложную структуру, включающую домен и относительный идентификатор (RID).

Классификация UID

UID можно классифицировать по нескольким признакам:

По типу субъекта

• Пользовательские UID — присваиваются учётным записям людей или сервисов. В Unix-системах диапазон 0—99 зарезервирован для системных учётных записей, а 100—65535 (или до 2^32-1 в современных ядрах) — для обычных пользователей.
• Групповые UID (GID) — идентифицируют группы пользователей для коллективного управления доступом.
• Процессные UID — присваиваются запущенным программам (например, в Linux — эффективный UID процесса, определяющий его права).
• Устройственные UID — используются в сетях (MAC-адреса) или в системах Интернета вещей (IoT) для идентификации датчиков и контроллеров.

По способу генерации

• Статические UID — назначаются администратором вручную или при установке системы (например, UID=0 для root).
• Динамические UID — генерируются автоматически при создании учётной записи или сессии (например, SID в Windows).
• Случайные UID — создаются с помощью криптостойких генераторов псевдослучайных чисел для повышения безопасности (например, UUID в распределённых системах).

По области применения

• Локальные UID — действуют в пределах одной системы (например, UID в файловой системе ext4).
• Глобальные UID — уникальны в масштабах сети или организации (например, UID в LDAP-каталогах или OAuth-токены).

Принципы работы модели

Модель безопасности UID базируется на трёх ключевых принципах:

1. Идентификация: Каждый субъект и объект получает уникальный идентификатор при создании. Повторное использование UID возможно только после удаления предыдущего владельца, но это считается небезопасной практикой (риск путаницы прав).
2. Аутентификация: Субъект доказывает свою принадлежность к UID через пароль, сертификат или биометрию. В Unix это реализовано через проверку хэша пароля в /etc/shadow.
3. Авторизация: Система сравнивает UID субъекта с UID объекта (владельцем файла) и списком разрешённых операций (чтение, запись, выполнение). В Unix это осуществляется через биты прав (rwx) и ACL (Access Control Lists).

Пример в Unix-системе

При попытке пользователя с UID=1001 открыть файл, принадлежащий UID=1001 с правами rw-r--r--, система разрешает чтение и запись. Если файл принадлежит UID=1002, доступ предоставляется только на чтение (для «других»), если не настроены группы или ACL.

Применение в операционных системах

Unix и Linux

• Ядро: UID хранится в структуре task_struct для каждого процесса. Системные вызовы setuid(), getuid(), setgid() управляют идентификаторами.
• Файловые системы: Каждый inode содержит поля uid и gid владельца. Команда chown изменяет владельца.
• Безопасность: Модель предотвращает несанкционированный доступ, но уязвима к атакам через SUID-бит (Set User ID), который позволяет процессу временно получить права владельца файла.

Windows

• SID: Структура S-1-5-21-... включает версию, идентификатор уполномоченного органа (например, 5 для NT Authority) и RID. SID не может быть изменён после создания.
• ACL: Каждый объект имеет discretionary ACL (DACL) и system ACL (SACL), где записи содержат SID субъекта и маску доступа.
• Особенности: В Windows UID (SID) может быть привязан к домену Active Directory, что позволяет централизованно управлять доступом в корпоративных сетях.

Применение в базах данных

В реляционных СУБД (например, PostgreSQL, MySQL) UID используется как первичный ключ (PRIMARY KEY) для таблиц пользователей. Например: ``sql CREATE TABLE users ( uid SERIAL PRIMARY KEY, username VARCHAR(50) UNIQUE, password_hash VARCHAR(255) ); ` Модель безопасности базы данных проверяет UID при выполнении запросов: пользователь с UID=1 может иметь права на чтение таблицы orders, а UID=2 — только на products`. В PostgreSQL это реализовано через роли (ROLE), которые также имеют UID.

Применение в сетевых протоколах

NFS (Network File System)

• UID mapping: При монтировании удалённой файловой системы UID клиента сопоставляется с UID на сервере. Если UID не совпадают, доступ может быть запрещён.
• Проблемы: В версиях NFSv3 UID передавался в открытом виде, что позволяло атакующему подменить идентификатор. В NFSv4 используется Kerberos для аутентификации.

OAuth 2.0 и OpenID Connect

• UID: В протоколах аутентификации UID (sub claim) представляет собой уникальный идентификатор пользователя в системе провайдера (например, Google или VK). Он используется для связывания учётных записей между сервисами.

Уязвимости и критика

Модель безопасности UID имеет ряд недостатков:

• Повторное использование UID: Если учётная запись удалена, а затем создана новая с тем же UID, новый пользователь может получить доступ к старым файлам. В современных системах это решается через запрет повторного использования UID в течение определённого времени (grace period).
• SUID-атаки: Злоумышленник может использовать SUID-бит на исполняемом файле (например, /usr/bin/passwd) для эскалации привилегий. В Linux это частично блокируется через no_new_privs и capabilities.
• Отсутствие контекста: UID не учитывает временные или пространственные ограничения (например, доступ с определённого IP-адреса). Для этого требуются дополнительные механизмы (например, RBAC или ABAC).
• Масштабируемость: В распределённых системах с миллионами пользователей глобальная уникальность UID сложна. Решение — использование UUID (128-битных идентификаторов) или GUID.

Интересные факты

• В Unix-системах UID=0 (root) имеет неограниченные права, что делает его критической точкой атаки. В некоторых дистрибутивах (например, OpenBSD) root-доступ по умолчанию отключён.
• В Windows SID для локальной системы (Local System) имеет вид S-1-5-18, а для сети (Network Service) — S-1-5-20.
• В контейнерных технологиях (Docker, Kubernetes) используется механизм user namespace, который отображает UID внутри контейнера на UID хоста, предотвращая эскалацию привилегий.

Источники

1. Bach, M. J. (1986). The Design of the UNIX Operating System. Prentice Hall.
2. Solomon, D. A., & Russinovich, M. E. (2005). Windows Internals. Microsoft Press.
3. Sandhu, R. S., & Samarati, P. (1994). Access Control: Principle and Practice. IEEE Communications Magazine.
4. RFC 5531 — Network File System (NFS) Version 4 Protocol.
5. RFC 6749 — The OAuth 2.0 Authorization Framework.