# Лекция 5. Безопасность в операционных системах. Методы обеспечения безопасности. Учетные записи. Права доступа > *Operatsion tizimlarda xavfsizlik. Xavfsizlikni ta’minlash usullari. Hisob qaydnomalari. Kirish huquqlari.* --- ## План лекции 1. Понятие безопасности ОС и основные термины 2. Угрозы, уязвимости и модель нарушителя 3. Фундаментальные принципы построения защищенных систем 4. Методы обеспечения безопасности ОС 5. Модели управления доступом (DAC, MAC, RBAC, ABAC) 6. Формальные модели безопасности (матрица доступа, Белл–ЛаПадула, Биба) 7. Идентификация, аутентификация, авторизация, аудит 8. Учетные записи в Linux 9. Учетные записи в Windows 10. Права доступа в Linux: биты прав, специальные биты, umask, ACL, capabilities 11. Права доступа в Windows: дескриптор безопасности, DACL, ACE, NTFS-разрешения 12. Повышение привилегий: sudo и UAC 13. Мандатные механизмы: SELinux, AppArmor, уровни целостности Windows 14. Практические задания 15. Контрольные вопросы и глоссарий --- # 1. Понятие безопасности операционной системы **Безопасность операционной системы** — это свойство ОС защищать хранимую и обрабатываемую информацию, а также собственные ресурсы (процессор, память, файлы, устройства, сетевые соединения) от несанкционированного доступа, изменения, уничтожения и от нарушения нормальной работы. Операционная система занимает особое место в защите информации: * все прикладные программы работают **поверх** ОС и пользуются ее механизмами; * если скомпрометирована ОС, то никакая прикладная защита (антивирус, шифрование в приложении, пароль в базе данных) уже не гарантирует безопасность; * именно ОС решает, **какой субъект** и к **какому объекту** может получить доступ. ### Субъекты и объекты В теории защиты информации все сущности системы делятся на две категории. | Понятие | Определение | Примеры | |---|---|---| | **Субъект** | Активная сущность, которая инициирует действия | Пользователь, процесс, поток, служба | | **Объект** | Пассивная сущность, к которой обращаются | Файл, каталог, устройство, сегмент памяти, сокет, ключ реестра, канал | | **Операция (право)** | Действие субъекта над объектом | Чтение, запись, выполнение, удаление, изменение владельца | На практике **субъект в ОС — это процесс**, выполняющийся от имени некоторой учетной записи. Пользователь сам по себе не обращается к файлам — это делает запущенная им программа, которой ОС передает его идентификатор и полномочия. ### Триада CIA Основные свойства защищаемой информации: * **Конфиденциальность (Confidentiality)** — информация доступна только тем, кому она разрешена. *Пример: другой пользователь не может прочитать файл `/home/ali/diplom.docx`.* * **Целостность (Integrity)** — информация не может быть изменена несанкционированно. *Пример: обычный пользователь не может изменить `/etc/passwd` или `C:\Windows\System32\kernel32.dll`.* * **Доступность (Availability)** — авторизованный пользователь получает доступ к информации и сервисам в нужный момент. *Пример: один процесс не может занять всю память и «повесить» систему для остальных.* Часто к триаде добавляют: * **Подотчетность (Accountability)** — каждое действие можно связать с конкретным субъектом; * **Неотказуемость (Non-repudiation)** — субъект не может отрицать совершенное действие; * **Аутентичность (Authenticity)** — подлинность субъекта или данных подтверждена. --- # 2. Угрозы, уязвимости и модель нарушителя ### Основные термины * **Угроза** — потенциально возможное событие или действие, которое может нарушить безопасность. * **Уязвимость** — слабое место системы, через которое угроза может реализоваться (ошибка в коде, неправильная настройка, слабый пароль). * **Атака** — реализованная попытка использовать уязвимость. * **Риск** — сочетание вероятности реализации угрозы и тяжести последствий. ``` Угроза + Уязвимость → Атака → Ущерб ``` ### Классификация угроз для ОС | Категория | Примеры | |---|---| | Несанкционированный доступ | Подбор пароля, кража сессии, использование чужой учетной записи | | Повышение привилегий | Эксплуатация ошибки в ядре или setuid-программе для получения прав root | | Вредоносное ПО | Вирусы, черви, трояны, руткиты, программы-вымогатели | | Отказ в обслуживании (DoS) | Fork-бомба, заполнение диска, исчерпание памяти | | Утечка информации | Чтение чужой памяти, остаточные данные на диске, побочные каналы | | Нарушение целостности | Подмена системных файлов, изменение журналов | | Социальная инженерия | Фишинг, обман пользователя для запуска программы | ### Пример классической уязвимости — fork-бомба ```bash :(){ :|:& };: ``` Функция `:` рекурсивно запускает две свои копии в фоне. Количество процессов растет экспоненциально, и таблица процессов переполняется. Защита средствами ОС — **ограничение ресурсов** (`ulimit -u`, `/etc/security/limits.conf`, cgroups): ```bash ulimit -u 200 # не более 200 процессов для текущего пользователя ``` ### Модель нарушителя При проектировании защиты определяют, **от кого** защищаемся: * **внешний нарушитель** — не имеет учетной записи, атакует через сеть; * **внутренний непривилегированный** — имеет обычную учетную запись (студент в компьютерном классе); * **внутренний привилегированный** — администратор, злоупотребляющий правами; * **вредоносная программа**, запущенная от имени законного пользователя. Последний случай особенно важен: программа, запущенная пользователем, получает **все** его права. Поэтому ограничение прав учетной записи напрямую ограничивает ущерб от вредоносного ПО. --- # 3. Принципы построения защищенных систем В 1975 году Дж. Зальцер и М. Шрёдер (J. Saltzer, M. Schroeder) сформулировали принципы, которые до сих пор лежат в основе проектирования защищенных ОС. | № | Принцип | Смысл | Пример в ОС | |---|---|---|---| | 1 | **Экономия механизма** (Economy of mechanism) | Защитный механизм должен быть простым и небольшим | Микроядро, небольшой код проверки прав | | 2 | **Безопасность по умолчанию** (Fail-safe defaults) | Если явного разрешения нет — доступ запрещен | Пустой DACL в Windows = доступ запрещен всем | | 3 | **Полное посредничество** (Complete mediation) | Каждое обращение к объекту проверяется | Проверка прав при каждом `open()` | | 4 | **Открытый дизайн** (Open design) | Безопасность не должна зависеть от секретности алгоритма | Открытые алгоритмы хэширования паролей | | 5 | **Разделение привилегий** (Separation of privilege) | Для критичного действия нужны несколько условий | Пароль + второй фактор; две подписи | | 6 | **Минимальные привилегии** (Least privilege) | Субъект получает только необходимые права | Веб-сервер работает от `www-data`, а не от `root` | | 7 | **Минимум общих механизмов** (Least common mechanism) | Минимизировать общие для пользователей ресурсы | Отдельный `/tmp` для каждого пользователя | | 8 | **Психологическая приемлемость** (Psychological acceptability) | Защита должна быть удобной, иначе ее обойдут | Биометрия, единый вход (SSO) | ### Монитор обращений (Reference Monitor) Концепция, лежащая в основе контроля доступа в любой ОС. **Монитор обращений** — компонент ядра, через который проходят *все* обращения субъектов к объектам. ``` ┌──────────┐ запрос (субъект, объект, операция) ┌──────────────────┐ │ Субъект │ ─────────────────────────────────────▶ │ Монитор обращений│ │ (процесс)│ │ (ядро ОС) │ └──────────┘ └────────┬─────────┘ │ проверка по ▼ политике ┌───────────────┐ ┌───────────┐ │ База правил │ │ Журнал │ │ (права, ACL) │ │ аудита │ └───────────────┘ └───────────┘ │ разрешить / запретить ▼ ┌──────────┐ │ Объект │ └──────────┘ ``` Требования к монитору обращений: 1. **Неминуемость** — его невозможно обойти; 2. **Защищенность** — его нельзя изменить из пользовательского режима; 3. **Проверяемость** — он достаточно мал, чтобы его можно было проверить и протестировать. В Linux роль монитора выполняют проверки прав в VFS и фреймворк **LSM** (Linux Security Modules); в Windows — **Security Reference Monitor (SRM)** в составе исполнительной системы ядра. ### Доверенная вычислительная база (TCB) **TCB (Trusted Computing Base)** — совокупность всех аппаратных и программных компонентов, от правильной работы которых зависит безопасность системы: ядро, загрузчик, монитор обращений, процесс входа в систему, программы с правами root/SYSTEM. Чем меньше TCB, тем легче ее проверить и тем надежнее система. --- # 4. Методы обеспечения безопасности ОС Методы защиты принято делить на несколько групп. Ни один метод не достаточен сам по себе — применяется **эшелонированная защита (Defense in Depth)**. ### 4.1. Аппаратные методы * **Режимы процессора** (кольца защиты): ядро работает в кольце 0, приложения — в кольце 3. Привилегированные инструкции из пользовательского режима вызывают исключение. * **MMU и виртуальная память** — каждый процесс имеет собственное адресное пространство и не видит память других процессов. * **Бит NX/XD** — запрет выполнения кода из страниц данных (стек, куча). * **SMEP/SMAP** — запрет ядру выполнять/читать код пользовательского пространства. * **TPM** (Trusted Platform Module) — хранение ключей, измеряемая загрузка. * **Secure Boot** — загрузка только подписанного загрузчика и ядра. ### 4.2. Программные (системные) методы * **Идентификация и аутентификация** пользователей; * **Разграничение доступа** (права, ACL, мандатные метки); * **Изоляция процессов** (адресные пространства, namespaces, контейнеры, песочницы); * **Аудит и журналирование** (`journald`, `auditd`, журнал событий Windows); * **Криптографическая защита** (шифрование дисков LUKS/BitLocker, хэширование паролей); * **Защита от эксплуатации** (ASLR, стековые канарейки, DEP, CFG); * **Контроль целостности** (подписи пакетов, `dm-verity`, Windows Resource Protection); * **Обновление ПО** — устранение известных уязвимостей. ### 4.3. Административные (организационные) методы * политика паролей и блокировки учетных записей; * принцип минимальных привилегий при выдаче прав; * регулярный аудит учетных записей и прав; * резервное копирование (правило 3-2-1); * обучение пользователей. ### 4.4. Схема эшелонированной защиты ``` ┌──────────────────────────────────────────────────────────┐ │ Физическая защита (доступ в серверную, замок корпуса) │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Сеть (межсетевой экран, закрытые порты) │ │ │ │ ┌──────────────────────────────────────────────────┐ │ │ │ │ │ ОС (учетные записи, аутентификация, обновления) │ │ │ │ │ │ ┌──────────────────────────────────────────────┐ │ │ │ │ │ │ │ Права доступа (DAC, ACL, MAC) │ │ │ │ │ │ │ │ ┌──────────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ Приложение (проверка ввода, песочница) │ │ │ │ │ │ │ │ │ │ ┌──────────────────────────────────────┐ │ │ │ │ │ │ │ │ │ │ │ Данные (шифрование, резервные копии) │ │ │ │ │ │ │ │ │ │ │ └──────────────────────────────────────┘ │ │ │ │ │ │ │ │ │ └──────────────────────────────────────────┘ │ │ │ │ │ │ │ └──────────────────────────────────────────────┘ │ │ │ │ │ └──────────────────────────────────────────────────┘ │ │ │ └──────────────────────────────────────────────────────┘ │ └──────────────────────────────────────────────────────────┘ ``` --- # 5. Модели управления доступом **Управление доступом (Access Control)** — механизм, определяющий, может ли субъект выполнить операцию над объектом. Выделяют четыре основные модели. ### 5.1. Дискреционное управление доступом (DAC) **DAC (Discretionary Access Control)** — права на объект определяет его **владелец** по своему усмотрению (*discretion* — усмотрение). * Владелец файла может выдать или отобрать права у других пользователей. * Используется в классических Unix/Linux (биты `rwx`, ACL) и Windows (NTFS DACL). * **Недостаток:** если пользователь запустил вредоносную программу, она от его имени может раздать права на его файлы кому угодно. Нет контроля над распространением информации: пользователь, имеющий право чтения, может скопировать файл и сделать копию общедоступной. ### 5.2. Мандатное управление доступом (MAC) **MAC (Mandatory Access Control)** — права определяются **политикой системы**, а не владельцем. Каждому субъекту и объекту присваивается **метка безопасности** (уровень секретности, категория, тип). Пользователь, даже владелец, не может изменить политику. * Примеры: SELinux, AppArmor, уровни целостности Windows (MIC), специализированные защищенные ОС (Astra Linux). * Применяется в военных и государственных системах, а также для изоляции служб. ### 5.3. Ролевое управление доступом (RBAC) **RBAC (Role-Based Access Control)** — права назначаются не пользователям напрямую, а **ролям**; пользователям назначаются роли. ``` Пользователь ──▶ Роль ──▶ Набор прав Ali Бухгалтер читать/писать /data/finance Vali Бухгалтер Sardor Админ БД управлять службой postgresql ``` * Упрощает администрирование: при переходе сотрудника на другую должность меняется только его роль. * Упрощенным аналогом RBAC в ОС являются **группы** (Linux-группы, группы Windows, Active Directory). ### 5.4. Управление доступом на основе атрибутов (ABAC) **ABAC (Attribute-Based Access Control)** — решение принимается по атрибутам субъекта, объекта и окружения. *Пример правила:* «сотрудник отдела кадров может читать личные дела **только в рабочее время** и **только из корпоративной сети**». Применяется в облачных системах (AWS IAM, Azure), в Windows — Dynamic Access Control. ### Сравнение моделей | Характеристика | DAC | MAC | RBAC | ABAC | |---|---|---|---|---| | Кто задает права | Владелец объекта | Администратор безопасности (политика) | Администратор через роли | Политика на атрибутах | | Гибкость | Высокая | Низкая | Средняя | Очень высокая | | Устойчивость к троянам | Низкая | Высокая | Средняя | Зависит от политики | | Сложность администрирования | Низкая | Высокая | Средняя | Высокая | | Пример | `chmod`, NTFS | SELinux | Группы, AD | AWS IAM | --- # 6. Формальные модели безопасности ### 6.1. Матрица доступа (модель Лэмпсона, 1971) Состояние системы защиты описывается матрицей **M**, где строки — субъекты, столбцы — объекты, а в ячейке `M[s, o]` записан набор прав субъекта `s` на объект `o`. | Субъект \ Объект | `report.txt` | `/usr/bin/gcc` | `printer` | Процесс `P2` | |---|---|---|---|---| | **ali** | own, r, w | r, x | write | — | | **vali** | r | r, x | — | — | | **root** | r, w | r, w, x | write | kill | Матрица на практике очень большая и разреженная, поэтому хранится одним из двух способов: * **по столбцам → списки управления доступом (ACL)**: с каждым **объектом** связан список «кто и что может с ним делать». Так устроены Linux и Windows. * **по строкам → списки возможностей (Capability lists)**: с каждым **субъектом** связан список «к чему и как он имеет доступ» (мандаты, «билеты»). Примеры: файловые дескрипторы Unix (открытый дескриптор — это фактически capability), Capsicum во FreeBSD, микроядро seL4. | | ACL | Capabilities | |---|---|---| | Хранится | При объекте | При субъекте | | Вопрос «кто имеет доступ к файлу?» | Легко | Трудно | | Отзыв прав у всех | Легко | Трудно | | Передача прав другому процессу | Через администратора/владельца | Передачей мандата | ### 6.2. Модель Белла–ЛаПадулы (1973) — защита конфиденциальности Уровни секретности упорядочены: `Несекретно < Конфиденциально < Секретно < Совершенно секретно`. Правила: 1. **No Read Up (NRU)** — простое свойство безопасности: субъект не может **читать** объект с уровнем выше своего. 2. **No Write Down (NWD)** — *-свойство (star property): субъект не может **записывать** в объект с уровнем ниже своего. Второе правило предотвращает утечку: даже если троян работает с допуском «Секретно», он не сможет записать секретные данные в несекретный файл. ``` Совершенно секретно ▲ запись разрешена (write up) Секретно ◀── субъект Конфиденциально ▼ чтение разрешено (read down) Несекретно ``` ### 6.3. Модель Биба (1977) — защита целостности Двойственна модели Белла–ЛаПадулы, но защищает **целостность**: 1. **No Read Down** — субъект с высоким уровнем целостности не читает «грязные» данные с низким уровнем; 2. **No Write Up** — субъект с низким уровнем целостности не может изменять данные с высоким уровнем. **Практический пример — Windows MIC (Mandatory Integrity Control).** Процесс браузера, открывшего страницу из Интернета, работает с уровнем **Low**. Даже если вредоносный код захватит процесс, он не сможет записать в файлы пользователя (уровень **Medium**), т. е. действует правило *No Write Up*. ### 6.4. Модель Кларка–Уилсона Ориентирована на коммерческие системы: данные можно изменять **только через проверенные процедуры** (транзакции), а обязанности разделены между сотрудниками (один создает платеж, другой утверждает). --- # 7. Идентификация, аутентификация, авторизация, аудит Доступ к системе проходит последовательность этапов (модель **IAAA**): ``` Идентификация → Аутентификация → Авторизация → Аудит (учет) «Кто ты?» «Докажи» «Что тебе можно?» «Что ты сделал?» логин: ali пароль, ключ права, группы журнал событий ``` | Этап | Вопрос | Механизм в Linux | Механизм в Windows | |---|---|---|---| | Идентификация | Кто ты? | Имя пользователя → UID | Имя пользователя → SID | | Аутентификация | Действительно ли ты тот, за кого себя выдаешь? | PAM, `/etc/shadow`, SSH-ключи | LSASS, SAM, Kerberos, Windows Hello | | Авторизация | Что тебе разрешено? | UID/GID, права, ACL, capabilities, SELinux | Маркер доступа, DACL, привилегии | | Аудит | Что ты сделал? | `journald`, `auditd`, `/var/log/auth.log` | Журнал «Безопасность» (Event Viewer) | ### Факторы аутентификации | Фактор | Описание | Примеры | |---|---|---| | **Знание** (something you know) | То, что пользователь знает | Пароль, PIN-код, ответ на секретный вопрос | | **Владение** (something you have) | То, что у пользователя есть | Смарт-карта, токен, телефон с TOTP, ключ FIDO2 | | **Свойство** (something you are) | Биометрия | Отпечаток пальца, лицо, радужка | **Многофакторная аутентификация (MFA)** — использование факторов **разных** типов. Пароль + PIN-код — это не MFA (оба фактора — «знание»). Пароль + код из приложения на телефоне — MFA. ### Хранение паролей ОС **никогда не должна хранить пароль в открытом виде**. Хранится результат **хэш-функции** с **солью**: ``` хранимое_значение = Hash(соль + пароль) ``` * **Соль (salt)** — случайная строка, уникальная для каждого пользователя. Благодаря ей одинаковые пароли дают разные хэши, и заранее вычисленные «радужные таблицы» становятся бесполезными. * Для паролей используются **медленные** функции (SHA-512-crypt с тысячами раундов, bcrypt, yescrypt, Argon2), чтобы перебор был дорогим. При входе ОС вычисляет хэш от введенного пароля с той же солью и сравнивает с сохраненным значением. --- # 8. Учетные записи в Linux **Учетная запись (account, hisob qaydnomasi)** — совокупность данных о пользователе, на основании которых ОС идентифицирует его, аутентифицирует и определяет его права. ### 8.1. Идентификаторы Ядро Linux **не знает имен пользователей** — оно работает только с числами: * **UID** (User ID) — идентификатор пользователя; * **GID** (Group ID) — идентификатор группы. Имена хранятся в файлах и используются только для удобства человека. Если удалить пользователя, но не его файлы, команда `ls -l` покажет вместо имени число — «осиротевший» UID. | Диапазон UID | Назначение | |---|---| | `0` | **root** — суперпользователь | | `1–999` | Системные учетные записи (службы: `daemon`, `www-data`, `sshd`, `postgres`) | | `1000+` | Обычные пользователи | | `65534` | `nobody` — непривилегированный пользователь «никто» | > Права root определяются **не именем**, а значением **UID = 0**. Если создать пользователя `admin` с UID 0, он будет суперпользователем. Поэтому аудит `/etc/passwd` на наличие лишних записей с UID 0 — обязательная проверка. ### 8.2. Типы учетных записей 1. **Суперпользователь (root)** — неограниченные права, проверки DAC для него не выполняются. 2. **Системные (служебные)** — для запуска демонов; обычно без пароля и с оболочкой `/usr/sbin/nologin`, вход в систему невозможен. 3. **Обычные пользователи** — работа людей; права ограничены своими файлами и выданными разрешениями. ### 8.3. Файл `/etc/passwd` Доступен на чтение всем (нужен программам для перевода UID ↔ имя). ``` ali:x:1001:1001:Ali Valiyev,,,:/home/ali:/bin/bash ``` | Поле | Значение | Описание | |---|---|---| | 1 | `ali` | Имя пользователя (логин) | | 2 | `x` | Пароль хранится в `/etc/shadow` | | 3 | `1001` | UID | | 4 | `1001` | GID основной (первичной) группы | | 5 | `Ali Valiyev,,,` | GECOS — комментарий (полное имя, телефон) | | 6 | `/home/ali` | Домашний каталог | | 7 | `/bin/bash` | Командная оболочка при входе | ### 8.4. Файл `/etc/shadow` Доступен только root (права `640`, группа `shadow`, или `000`). ``` ali:$y$j9T$Fh3k...$Qx9...:20001:0:90:7:14:: ``` | Поле | Пример | Описание | |---|---|---| | 1 | `ali` | Имя пользователя | | 2 | `$y$j9T$...` | Хэш пароля в формате `$id$соль$хэш` | | 3 | `20001` | Дата последней смены пароля (дней от 01.01.1970) | | 4 | `0` | Минимальный срок между сменами пароля (дней) | | 5 | `90` | Максимальный срок действия пароля | | 6 | `7` | За сколько дней предупреждать об истечении | | 7 | `14` | Через сколько дней после истечения блокировать | | 8 | (пусто) | Дата блокировки учетной записи | | 9 | (пусто) | Зарезервировано | **Идентификатор алгоритма** во втором поле: | `$id$` | Алгоритм | |---|---| | `$1$` | MD5-crypt (устарел, небезопасен) | | `$5$` | SHA-256-crypt | | `$6$` | SHA-512-crypt | | `$2b$` | bcrypt | | `$y$` | yescrypt (по умолчанию в Debian 11+, Ubuntu 22.04+, Fedora) | Специальные значения поля пароля: * `!` или `*` — вход по паролю запрещен (учетная запись заблокирована или служебная); * `!$6$...` — пароль есть, но учетная запись заблокирована (`passwd -l`); * пустое поле — вход **без пароля** (опасно!). ### 8.5. Группы: `/etc/group` и `/etc/gshadow` ``` developers:x:1050:ali,vali,sardor ``` Поля: имя группы, пароль группы (`x` → `/etc/gshadow`), GID, список **дополнительных** членов. У каждого пользователя: * **одна основная (первичная) группа** — указана в `/etc/passwd`, она назначается новым файлам; * **несколько дополнительных групп** — указаны в `/etc/group`. ```bash $ id ali uid=1001(ali) gid=1001(ali) groups=1001(ali),27(sudo),1050(developers) ``` Важные системные группы: `sudo`/`wheel` (право использовать sudo), `adm` (чтение журналов), `docker` (управление Docker — фактически эквивалент root!), `dialout` (последовательные порты), `video`, `audio`. ### 8.6. Учетные данные процесса У каждого процесса Linux есть несколько идентификаторов: | Идентификатор | Назначение | |---|---| | **RUID** (real UID) | Кто реально запустил процесс | | **EUID** (effective UID) | От чьего имени проверяются права доступа | | **SUID** (saved UID) | Сохраненный UID — позволяет временно сбросить и вернуть привилегии | | **FSUID** | UID для проверок файловой системы (обычно равен EUID) | | **RGID / EGID / SGID** | Аналоги для группы | | **Дополнительные группы** | Список GID из `/etc/group` | Обычно RUID = EUID. Различаются они при запуске программ с битом **setuid** (раздел 10.4): например, при запуске `passwd` обычным пользователем RUID = 1001, а EUID = 0. ```bash $ cat /proc/self/status | grep -E 'Uid|Gid|Groups' Uid: 1001 1001 1001 1001 # real effective saved fs Gid: 1001 1001 1001 1001 Groups: 27 1001 1050 ``` ### 8.7. Процесс входа в систему и PAM ``` login/sshd/gdm ──▶ PAM ──▶ проверка пароля (/etc/shadow), 2FA, ограничения │ ▼ успех setgid(GID) → initgroups() → setuid(UID) → запуск оболочки ``` **PAM (Pluggable Authentication Modules)** — подключаемые модули аутентификации. Позволяют менять способ аутентификации без изменения программ. Настройки — в `/etc/pam.d/`. ``` # /etc/pam.d/common-auth (фрагмент) auth required pam_faillock.so preauth deny=5 unlock_time=900 auth [success=1 default=ignore] pam_unix.so nullok auth requisite pam_deny.so ``` Типы модулей: `auth` (проверка личности), `account` (разрешен ли вход: срок действия, время), `password` (смена пароля), `session` (действия при открытии/закрытии сеанса). Полезные модули: `pam_unix` (классические пароли), `pam_pwquality` (сложность пароля), `pam_faillock` (блокировка после неудачных попыток), `pam_google_authenticator` (TOTP), `pam_limits` (ограничения ресурсов). ### 8.8. Управление учетными записями — команды | Действие | Команда | |---|---| | Создать пользователя с домашним каталогом | `sudo useradd -m -s /bin/bash -c "Ali Valiyev" ali` | | Интерактивное создание (Debian/Ubuntu) | `sudo adduser ali` | | Установить/сменить пароль | `sudo passwd ali` | | Добавить в дополнительную группу | `sudo usermod -aG developers ali` | | Сменить оболочку | `sudo usermod -s /usr/sbin/nologin ali` | | Заблокировать / разблокировать | `sudo usermod -L ali` / `sudo usermod -U ali` | | Установить срок действия учетной записи | `sudo usermod -e 2026-12-31 ali` | | Политика срока пароля | `sudo chage -M 90 -m 1 -W 7 ali` | | Просмотр политики пароля | `sudo chage -l ali` | | Удалить пользователя вместе с домашним каталогом | `sudo userdel -r ali` | | Создать группу | `sudo groupadd developers` | | Удалить из группы | `sudo gpasswd -d ali developers` | | Кто я | `whoami`, `id` | | Кто сейчас в системе | `who`, `w` | | История входов | `last`, `lastb` (неудачные) | | Неудачные попытки / блокировки | `faillock --user ali` | > **Частая ошибка:** `usermod -G developers ali` без ключа `-a` **заменяет** весь список дополнительных групп. Пользователь может потерять членство в `sudo`. > Изменения групп вступают в силу только в **новом сеансе** — нужно перелогиниться или выполнить `newgrp developers`. Значения по умолчанию для новых учетных записей задаются в `/etc/login.defs` (диапазоны UID, `PASS_MAX_DAYS`, `UMASK`, `ENCRYPT_METHOD`) и шаблоном домашнего каталога `/etc/skel/`. --- # 9. Учетные записи в Windows ### 9.1. Идентификатор безопасности (SID) Как Linux работает с UID, так Windows работает с **SID (Security Identifier)** — уникальной строкой переменной длины. ``` S-1-5-21-3623811015-3361044348-30300820-1013 │ │ │ │ └──────── идентификатор домена/компьютера ┘ └─ RID │ │ │ └─ подавторитет (21 = локальная машина/домен) │ │ └─ авторитет (5 = NT Authority) │ └─ версия └─ «SID» ``` **RID (Relative ID)** — последняя часть, номер учетной записи внутри домена или компьютера. Хорошо известные (well-known) SID: | SID | Учетная запись / группа | |---|---| | `S-1-5-18` | **LocalSystem (SYSTEM)** — высшие права в системе | | `S-1-5-19` | LocalService | | `S-1-5-20` | NetworkService | | `S-1-5-21-…-500` | Встроенный **Administrator** | | `S-1-5-21-…-501` | **Guest** (Гость) | | `S-1-5-21-…-1000+` | Обычные созданные пользователи | | `S-1-5-32-544` | Группа **Administrators** | | `S-1-5-32-545` | Группа **Users** | | `S-1-1-0` | **Everyone** (Все) | | `S-1-5-11` | **Authenticated Users** | > Если удалить пользователя и создать нового с тем же именем, он получит **новый SID** и **не** получит доступ к файлам старого пользователя. В Linux при совпадении UID — получит. ### 9.2. Где хранятся учетные записи * **Локальные учетные записи** — в базе **SAM** (Security Account Manager), файл `%SystemRoot%\System32\config\SAM`. Пароли хранятся в виде NT-хэшей; файл заблокирован системой во время работы. * **Доменные учетные записи** — в **Active Directory** на контроллере домена (`NTDS.dit`), аутентификация по протоколу **Kerberos**. * **Учетные записи Microsoft / Microsoft Entra ID** — облачная аутентификация. Процесс **LSASS** (`lsass.exe`, Local Security Authority Subsystem Service) проверяет учетные данные, создает маркер доступа и применяет локальную политику безопасности. Поэтому кража памяти LSASS (инструменты типа Mimikatz) — одна из главных целей атакующих; защита — **Credential Guard** и режим защищенного процесса LSA. ### 9.3. Типы учетных записей Windows | Тип | Описание | |---|---| | **Administrator** (встроенный) | Полные права; по умолчанию **отключен** в Windows 10/11 | | **Пользователь в группе Administrators** | Права администратора, но с UAC (раздел 12.2) | | **Стандартный пользователь** (группа Users) | Не может устанавливать ПО для всех, менять системные настройки | | **Guest** | Минимальные права, по умолчанию отключен | | **SYSTEM, LocalService, NetworkService** | Служебные учетные записи для служб | | **Виртуальные учетные записи / gMSA** | `NT SERVICE\<имя_службы>` — отдельная учетная запись для каждой службы | ### 9.4. Маркер доступа (Access Token) При успешном входе LSASS создает **маркер доступа** — аналог учетных данных процесса в Linux. Каждый процесс, запущенный пользователем, получает копию маркера. Маркер содержит: * SID пользователя; * SID всех групп, в которые он входит; * список **привилегий** (например, `SeShutdownPrivilege`, `SeBackupPrivilege`, `SeDebugPrivilege`); * **уровень целостности** (Low / Medium / High / System); * SID сеанса входа, тип маркера (первичный или маркер олицетворения). ```powershell PS> whoami /all # показать SID, группы, привилегии и уровень целостности PS> whoami /priv # только привилегии ``` > **Права** (permissions) относятся к **объектам** (файл, ключ реестра) и записываются в ACL объекта. **Привилегии** (privileges) относятся к **учетной записи** и разрешают действия в масштабе системы (выключить компьютер, изменить системное время, отлаживать чужие процессы). Привилегии назначаются через «Локальную политику безопасности» (`secpol.msc` → «Назначение прав пользователя»). ### 9.5. Управление учетными записями Windows — команды | Действие | cmd | PowerShell | |---|---|---| | Список пользователей | `net user` | `Get-LocalUser` | | Создать пользователя | `net user ali P@ssw0rd /add` | `New-LocalUser -Name ali -Password (Read-Host -AsSecureString)` | | Добавить в группу | `net localgroup Administrators ali /add` | `Add-LocalGroupMember -Group Users -Member ali` | | Отключить | `net user ali /active:no` | `Disable-LocalUser ali` | | Удалить | `net user ali /delete` | `Remove-LocalUser ali` | | Политика паролей | `net accounts /maxpwage:90 /minpwlen:12` | — | | Список групп | `net localgroup` | `Get-LocalGroup` | Графические средства: `lusrmgr.msc` (локальные пользователи и группы), `secpol.msc` (локальная политика безопасности), `gpedit.msc` (групповые политики). ### 9.6. Сравнение учетных записей Linux и Windows | Аспект | Linux | Windows | |---|---|---| | Идентификатор | UID/GID (целое число) | SID (структурированная строка) | | Суперпользователь | root (UID 0) | SYSTEM, Administrator, группа Administrators | | Хранилище | `/etc/passwd`, `/etc/shadow`, `/etc/group` (или LDAP/SSSD) | SAM, Active Directory | | Аутентификация | PAM | LSASS + пакеты аутентификации (NTLM, Kerberos) | | Удостоверение процесса | `struct cred` (UID, GID, группы, capabilities) | Маркер доступа (SID, группы, привилегии, уровень целостности) | | Временное повышение прав | `sudo`, `su`, setuid | UAC, «Запуск от имени администратора», `runas` | | Разделение полномочий root | capabilities | привилегии | --- # 10. Права доступа в Linux **Право доступа (kirish huquqi)** — разрешение субъекту выполнять определенную операцию над объектом. ### 10.1. Классическая модель Unix: владелец, группа, остальные Каждый файл (inode) хранит: * **UID владельца**; * **GID группы-владельца**; * **12 бит режима**: 9 бит прав + 3 специальных бита. ``` $ ls -l report.txt -rw-r----- 1 ali developers 2048 Oct 5 10:00 report.txt │└┬┘└┬┘└┬┘ │ │ │ │ │ │ │ └─ группа-владелец │ │ │ │ └─ пользователь-владелец │ │ │ └─ others (остальные): --- │ │ └─ group (группа): r-- │ └─ user/owner (владелец): rw- └─ тип файла: - обычный, d каталог, l ссылка, c/b устройство, s сокет, p канал ``` ### 10.2. Значение прав для файлов и каталогов | Право | Для файла | Для каталога | |---|---|---| | **r** (4) | Читать содержимое | Получать список имен файлов (`ls`) | | **w** (2) | Изменять содержимое | Создавать, удалять, переименовывать файлы **в каталоге** | | **x** (1) | Выполнять как программу | «Проходить» через каталог: `cd`, обращаться к файлам по имени | Важные следствия: * **Удаление файла определяется правами на каталог, а не на файл.** Если у пользователя есть `w` и `x` на каталог, он может удалить из него чужой файл, даже доступный только для чтения (защита — sticky bit). * Каталог с правами `--x` (без `r`) — «слепой»: войти можно, содержимое не видно, но файл с известным именем открыть можно. * Каталог с `r--` (без `x`) — видны имена, но нельзя открыть ни один файл и узнать его атрибуты. * Для доступа к `/home/ali/docs/a.txt` нужно право `x` на **каждый** каталог пути: `/`, `/home`, `/home/ali`, `/home/ali/docs`. ### 10.3. Числовая и символьная запись | Восьмеричная | Двоичная | Права | |---|---|---| | 0 | 000 | `---` | | 1 | 001 | `--x` | | 2 | 010 | `-w-` | | 3 | 011 | `-wx` | | 4 | 100 | `r--` | | 5 | 101 | `r-x` | | 6 | 110 | `rw-` | | 7 | 111 | `rwx` | Типичные комбинации: | Режим | Символьно | Применение | |---|---|---| | `600` | `rw-------` | Личные файлы, `~/.ssh/id_ed25519` | | `644` | `rw-r--r--` | Обычные файлы, конфигурация без секретов | | `640` | `rw-r-----` | Конфигурация с секретами, доступная группе службы | | `700` | `rwx------` | Личный каталог, `~/.ssh` | | `755` | `rwxr-xr-x` | Программы, общедоступные каталоги | | `750` | `rwxr-x---` | Каталог проекта для группы | | `777` | `rwxrwxrwx` | **Опасно**: все могут всё | Команды: ```bash chmod 640 report.txt # числовая форма chmod u+x script.sh # добавить владельцу выполнение chmod g-w,o= report.txt # убрать у группы запись, у остальных — все права chmod -R u=rwX,g=rX,o= project/ # X — выполнение только для каталогов (и уже исполняемых файлов) chown ali report.txt # сменить владельца (только root) chown ali:developers report.txt chgrp developers report.txt # сменить группу (владелец — только на группу, в которой состоит) ``` > Сменить владельца файла может **только root**. Иначе пользователь мог бы «подарить» файл другому и обойти дисковые квоты, или создать файл от чужого имени. ### 10.4. Специальные биты: setuid, setgid, sticky | Бит | Число | На файле | На каталоге | Вид в `ls` | |---|---|---|---|---| | **setuid** | 4000 | Программа выполняется с **EUID владельца** файла | Не используется | `rws` в правах владельца | | **setgid** | 2000 | Программа выполняется с **EGID группы** файла | Новые файлы наследуют **группу каталога** | `rws` в правах группы | | **sticky** | 1000 | Не используется | Удалять/переименовывать файл может только его владелец, владелец каталога или root | `rwt` в правах остальных | Заглавная буква (`S`, `T`) означает: специальный бит установлен, а соответствующий бит `x` — нет. **Пример setuid.** Обычный пользователь должен иметь возможность сменить свой пароль, но `/etc/shadow` доступен на запись только root: ```bash $ ls -l /usr/bin/passwd /etc/shadow -rwsr-xr-x 1 root root 68208 ... /usr/bin/passwd -rw-r----- 1 root shadow 1520 ... /etc/shadow ``` Программа `passwd` запускается с EUID = 0, изменяет `/etc/shadow`, но сама проверяет, что пользователь меняет **только свой** пароль. > setuid-программы, принадлежащие root, — одна из главных целей атак на повышение привилегий. Любая ошибка в такой программе дает атакующему root. Список таких программ нужно знать и минимизировать: > ```bash > find / -perm -4000 -type f 2>/dev/null > ``` **Пример sticky bit:** ```bash $ ls -ld /tmp drwxrwxrwt 20 root root 4096 ... /tmp ``` Все могут создавать файлы в `/tmp`, но никто не может удалить чужой файл. **Пример setgid на каталоге — общая папка проекта:** ```bash sudo mkdir /srv/project sudo chgrp developers /srv/project sudo chmod 2770 /srv/project # rwxrws--- ``` Все файлы, создаваемые участниками в `/srv/project`, автоматически получают группу `developers`. ### 10.5. umask — права по умолчанию При создании файла программа запрашивает права (обычно `666` для файлов и `777` для каталогов), а ядро **убирает** из них биты, указанные в **umask**: ``` итоговые_права = запрошенные_права AND (NOT umask) ``` | umask | Файл (из 666) | Каталог (из 777) | Применение | |---|---|---|---| | `022` | `644` | `755` | Стандарт для большинства систем | | `002` | `664` | `775` | Совместная работа в группах | | `027` | `640` | `750` | Серверы: остальные не видят ничего | | `077` | `600` | `700` | Максимальная приватность | ```bash $ umask 0022 $ umask 027 # для текущего сеанса; постоянно — в ~/.bashrc или /etc/login.defs ``` ### 10.6. Алгоритм проверки прав в Linux Когда процесс вызывает `open("file", O_RDONLY)`, ядро выполняет: ``` 1. Если EUID процесса = 0 (точнее — есть CAP_DAC_OVERRIDE): → разрешить (для выполнения нужен хотя бы один бит x) 2. Иначе, если EUID = UID владельца файла: → проверять ТОЛЬКО права владельца (u) 3. Иначе, если EGID или одна из дополнительных групп = GID файла: → проверять ТОЛЬКО права группы (g) 4. Иначе: → проверять права остальных (o) 5. (дополнительно) проверка LSM: SELinux / AppArmor могут запретить ``` Проверки **не суммируются**: выбирается **первая подходящая** категория. **Задача-ловушка:** ```bash $ ls -l secret.txt ----r--r-- 1 ali ali 10 ... secret.txt $ whoami ali $ cat secret.txt cat: secret.txt: Permission denied ``` Пользователь `ali` — владелец, поэтому проверяются **только** права владельца (`---`), хотя «остальным» чтение разрешено. Однако `ali` как владелец может выполнить `chmod u+r secret.txt` и вернуть себе доступ — менять права может владелец, независимо от текущих битов. ### 10.7. Списки управления доступом POSIX ACL Классическая модель позволяет задать права только для **одного** пользователя и **одной** группы. **ACL** позволяет назначать права любому числу пользователей и групп. ```bash # дать пользователю vali право чтения и записи setfacl -m u:vali:rw report.txt # дать группе teachers право чтения setfacl -m g:teachers:r report.txt # права по умолчанию для новых файлов в каталоге (наследование) setfacl -d -m g:developers:rwX /srv/project # просмотр getfacl report.txt # удалить запись / все ACL setfacl -x u:vali report.txt setfacl -b report.txt ``` Вывод `getfacl`: ``` # file: report.txt # owner: ali # group: developers user::rw- user:vali:rw- group::r-- group:teachers:r-- mask::rw- other::--- ``` * `ls -l` показывает знак `+` после прав: `-rw-rw----+`. * **mask** — максимальные права для всех именованных пользователей, групп и группы-владельца. Эффективные права = запись ACL **AND** mask. Команда `chmod g=...` на файле с ACL меняет именно mask. Алгоритм проверки с ACL: владелец → именованные пользователи (`& mask`) → группа-владелец и именованные группы (`& mask`; доступ, если подходит хотя бы одна) → остальные. ### 10.8. Linux capabilities — разделение полномочий root Традиционно в Unix была дихотомия: либо root (всё), либо обычный пользователь. С версии ядра 2.2 полномочия root разделены на ~40 отдельных **capabilities**: | Capability | Что позволяет | |---|---| | `CAP_NET_BIND_SERVICE` | Занимать порты < 1024 | | `CAP_NET_RAW` | Использовать «сырые» сокеты (`ping`) | | `CAP_DAC_OVERRIDE` | Игнорировать проверки прав rwx | | `CAP_DAC_READ_SEARCH` | Игнорировать проверки чтения файлов и поиска в каталогах | | `CAP_CHOWN` | Менять владельца файлов | | `CAP_KILL` | Посылать сигналы чужим процессам | | `CAP_SYS_PTRACE` | Отлаживать чужие процессы | | `CAP_SYS_TIME` | Менять системное время | | `CAP_SYS_ADMIN` | Множество административных операций («новый root») | Пример — веб-сервер может слушать порт 80 без прав root: ```bash sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/myserver getcap /usr/local/bin/myserver # /usr/local/bin/myserver cap_net_bind_service=ep # capabilities текущего процесса grep Cap /proc/self/status capsh --print ``` Это прямое применение **принципа минимальных привилегий**: вместо полного root программа получает ровно одно нужное полномочие. Аналог в Windows — **привилегии** маркера доступа. ### 10.9. Атрибуты файлов ext4 Дополнительный уровень защиты, действующий **даже для root**: ```bash sudo chattr +i /etc/resolv.conf # immutable: нельзя изменить, удалить, переименовать sudo chattr +a /var/log/app.log # append-only: только дописывать в конец lsattr /etc/resolv.conf # ----i---------e------- /etc/resolv.conf ``` Атрибут `+a` полезен для журналов: злоумышленник не сможет стереть следы, не сняв сначала атрибут (а это требует `CAP_LINUX_IMMUTABLE`). --- # 11. Права доступа в Windows ### 11.1. Дескриптор безопасности Каждый защищаемый объект Windows (файл, каталог, ключ реестра, служба, процесс, принтер, общая папка) имеет **дескриптор безопасности (Security Descriptor)**: ``` Дескриптор безопасности ├── Owner SID — владелец объекта ├── Group SID — основная группа (для совместимости с POSIX) ├── DACL — дискреционный список управления доступом: КТО и ЧТО может │ ├── ACE: Allow ali Modify │ ├── ACE: Deny Guest Read │ └── ACE: Allow Administrators Full Control └── SACL — системный список: какие обращения ЗАПИСЫВАТЬ в журнал аудита └── ACE: Audit Failure Everyone Write + метка обязательной целостности (Mandatory Label) ``` **ACE (Access Control Entry)** — запись в списке: тип (Allow / Deny / Audit), SID, маска прав, флаги наследования. ### 11.2. Стандартные разрешения NTFS | Разрешение | Файл | Каталог | |---|---|---| | **Полный доступ (Full Control)** | Всё, включая смену прав и владельца | Всё, включая удаление вложенных объектов | | **Изменение (Modify)** | Чтение, запись, удаление | + создание и удаление файлов | | **Чтение и выполнение (Read & Execute)** | Чтение, запуск программ | Просмотр и переход по каталогам | | **Список содержимого папки** | — | Просмотр списка файлов | | **Чтение (Read)** | Чтение содержимого и атрибутов | Чтение списка и атрибутов | | **Запись (Write)** | Изменение содержимого | Создание файлов и подкаталогов | | **Особые разрешения** | 14 детальных прав: удаление, смена разрешений, смена владельца и т. д. | | ### 11.3. Наследование По умолчанию разрешения **наследуются** от родительского каталога к вложенным объектам. Флаги наследования ACE: | Флаг `icacls` | Значение | |---|---| | `(OI)` | Object Inherit — наследуется файлами | | `(CI)` | Container Inherit — наследуется подкаталогами | | `(IO)` | Inherit Only — применяется только к потомкам, не к самому каталогу | | `(NP)` | No Propagate — наследуется только на один уровень | | `(I)` | Запись унаследована от родителя | Унаследованные права можно **отключить** для объекта («Отключить наследование» в свойствах), превратив их в явные или удалив. ### 11.4. Алгоритм проверки доступа в Windows Когда процесс открывает объект, **Security Reference Monitor** сравнивает **маркер доступа** процесса с **дескриптором безопасности** объекта: ``` 1. Проверка уровня целостности (MIC): если уровень процесса ниже уровня объекта — запрет записи (No Write Up). 2. Если DACL отсутствует (NULL DACL) → полный доступ ВСЕМ (опасно!). 3. Если DACL пустой (нет ни одной ACE) → доступ ЗАПРЕЩЕН всем. 4. Владелец объекта неявно получает права READ_CONTROL и WRITE_DAC (может читать и менять разрешения). 5. ACE просматриваются ПО ПОРЯДКУ: • если ACE Deny совпадает с SID из маркера и запрещает хотя бы одно запрошенное право → ОТКАЗ; • если ACE Allow совпадает → добавить разрешенные права; • как только все запрошенные права набраны → РАЗРЕШИТЬ. 6. Если список закончился, а права набраны не все → ОТКАЗ. ``` **Канонический порядок ACE** (Windows поддерживает его автоматически): 1. Явные запрещающие (explicit Deny) 2. Явные разрешающие (explicit Allow) 3. Унаследованные запрещающие (inherited Deny) 4. Унаследованные разрешающие (inherited Allow) Следствие: **явное разрешение сильнее унаследованного запрета**, а явный запрет сильнее любого разрешения. В отличие от Linux, в Windows **права суммируются** по всем группам пользователя: если `ali` в группе `Users` имеет Read, а в группе `Developers` — Modify, итог — Modify (если нет Deny). ### 11.5. Сетевые папки: Share + NTFS При доступе к папке по сети (`\\server\share`) действуют **два** набора прав: разрешения общего ресурса (Share) и разрешения NTFS. Итоговые права — **наиболее строгие** из двух. | Share | NTFS | Итог по сети | |---|---|---| | Full Control | Read | Read | | Read | Modify | Read | | Change | Modify | Modify | ### 11.6. Команда `icacls` ```cmd :: просмотр прав icacls C:\Data\report.docx :: дать пользователю ali права на изменение с наследованием для файлов и подкаталогов icacls C:\Data /grant ali:(OI)(CI)M :: дать группе только чтение и выполнение icacls C:\Data /grant "Students":(OI)(CI)RX :: явный запрет записи icacls C:\Data\exam /deny Students:(W) :: отозвать все записи пользователя icacls C:\Data /remove ali :: отключить наследование, скопировав унаследованные права в явные icacls C:\Data /inheritance:d :: сменить владельца icacls C:\Data /setowner Administrators /T :: сброс к унаследованным правам icacls C:\Data /reset /T ``` Обозначения прав: `F` — полный доступ, `M` — изменение, `RX` — чтение и выполнение, `R` — чтение, `W` — запись, `D` — удаление. В PowerShell: `Get-Acl`, `Set-Acl`. ### 11.7. Сравнение прав доступа Linux и Windows | Аспект | Linux | Windows | |---|---|---| | Базовая модель | 9 бит rwx (owner/group/other) + POSIX ACL | DACL из произвольного числа ACE | | Явный запрет | Нет (кроме «пустых» прав владельца/ACL) | Есть (Deny ACE) | | Комбинирование прав групп | Первая подходящая категория | Суммирование по всем группам | | Наследование | Только через default ACL, setgid каталога | Встроено, с флагами OI/CI/IO/NP | | Право удаления файла | Определяется правами каталога | Отдельное право Delete на файле или Delete Child на каталоге | | Аудит доступа | `auditd` (правила `-w`) | SACL на объекте | | Суперпользователь обходит проверки | Да (root / CAP_DAC_OVERRIDE) | Частично: администратор может **стать владельцем** и затем изменить DACL; SeBackupPrivilege позволяет читать всё | --- # 12. Повышение привилегий: sudo и UAC Работать постоянно с правами администратора опасно: любая ошибка или вредоносная программа получит полный контроль над системой. Поэтому современные ОС используют **временное повышение привилегий**. ### 12.1. sudo в Linux `sudo` (superuser do) позволяет разрешенным пользователям выполнять отдельные команды от имени root (или другого пользователя) с вводом **своего** пароля. Преимущества перед `su` (вход под root): * не нужно сообщать пароль root; * можно ограничить набор разрешенных команд; * каждое использование записывается в журнал (`/var/log/auth.log`, `journalctl _COMM=sudo`). Файл `/etc/sudoers` редактируется **только** через `visudo` (проверка синтаксиса — ошибка может лишить доступа к sudo). ``` # пользователь хосты=(от_имени_кого:группы) команды root ALL=(ALL:ALL) ALL %sudo ALL=(ALL:ALL) ALL # оператор может только перезапускать веб-сервер, без пароля operator ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx # преподаватель может управлять учетными записями студентов %teachers ALL=(root) /usr/sbin/useradd, /usr/sbin/usermod, /usr/bin/passwd [a-z]* ``` Дополнительные правила лучше выносить в отдельные файлы `/etc/sudoers.d/`. ```bash sudo -l # какие команды мне разрешены sudo -i # интерактивная оболочка root (с журналированием входа) sudo -u postgres psql # выполнить от имени другого пользователя ``` > **Опасность:** разрешение запускать через sudo редакторы (`vim`, `less`), интерпретаторы (`python`, `find -exec`, `awk`) фактически дает полный root, так как из них можно запустить оболочку. Примеры таких обходов собраны в проекте GTFOBins. ### 12.2. UAC в Windows **UAC (User Account Control)** — контроль учетных записей. Когда администратор входит в систему, LSASS создает **два маркера**: * **отфильтрованный маркер** — без административных привилегий, уровень целостности **Medium**; с ним запускаются все обычные программы, включая Проводник; * **полный маркер** — со всеми правами, уровень **High**; используется только после подтверждения. ``` Вход администратора │ ├─▶ Отфильтрованный маркер (Medium) ──▶ explorer.exe, браузер, Word ... │ └─▶ Полный маркер (High) ──▶ только после запроса UAC («Разрешить этому приложению вносить изменения?») ``` Запрос UAC отображается на **защищенном рабочем столе** (Secure Desktop), чтобы вредоносная программа не могла сама нажать кнопку «Да». Для стандартного пользователя UAC запрашивает **логин и пароль администратора** (*over-the-shoulder elevation*). > UAC — **не граница безопасности** в строгом смысле (Microsoft официально так его не позиционирует), а механизм, который заставляет программы работать без лишних прав по умолчанию. Надежнее работать под учетной записью **стандартного пользователя**. --- # 13. Мандатные механизмы в современных ОС ### 13.1. SELinux **SELinux (Security-Enhanced Linux)** — реализация MAC, разработанная АНБ США, включена в ядро Linux через LSM. Используется по умолчанию в RHEL, Fedora, CentOS, Android. Каждому процессу и файлу присваивается **контекст безопасности**: ``` user:role:type:level system_u:system_r:httpd_t:s0 ← процесс веб-сервера system_u:object_r:httpd_sys_content_t:s0 ← файлы сайта ``` Политика (Type Enforcement) разрешает, например, процессам типа `httpd_t` читать только файлы типа `httpd_sys_content_t`. Даже если веб-сервер будет взломан и атакующий получит root **внутри этого процесса**, он не сможет прочитать `/etc/shadow` (тип `shadow_t`) или домашние каталоги. ```bash getenforce # Enforcing / Permissive / Disabled ls -Z /var/www/html # контексты файлов ps -eZ | grep httpd # контексты процессов sudo restorecon -Rv /var/www/html # восстановить контексты по умолчанию sudo ausearch -m avc -ts recent # просмотр отказов SELinux ``` Порядок проверки: **сначала DAC, затем MAC**. Доступ разрешен, только если разрешили **оба** механизма. ### 13.2. AppArmor Альтернативная реализация MAC (Ubuntu, Debian, SUSE). Вместо меток использует **профили на основе путей**: ``` # /etc/apparmor.d/usr.sbin.nginx (фрагмент) /usr/sbin/nginx { /var/www/** r, /var/log/nginx/** w, network inet tcp, deny /etc/shadow r, } ``` ```bash sudo aa-status # загруженные профили и их режим sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx sudo aa-complain /etc/apparmor.d/usr.sbin.nginx # режим обучения: только журналировать ``` | | SELinux | AppArmor | |---|---|---| | Основа | Метки (контексты) на объектах | Пути к файлам | | Сложность | Высокая | Средняя | | Гранулярность | Очень высокая | Высокая | | Дистрибутивы | RHEL, Fedora, Android | Ubuntu, Debian, SUSE | ### 13.3. Уровни целостности Windows (MIC) | Уровень | Кто использует | |---|---| | **Untrusted** | Анонимные процессы | | **Low** | Песочницы браузеров, Internet Explorer в защищенном режиме, AppContainer | | **Medium** | Обычные программы пользователя | | **High** | Программы, запущенные «от имени администратора» | | **System** | Службы ОС, ядро | Правило по умолчанию — **No Write Up** (модель Биба): процесс не может изменять объекты с более высоким уровнем и не может внедряться в процессы с более высоким уровнем. ```cmd whoami /groups | find "Mandatory Label" icacls file.txt /setintegritylevel low ``` --- # 14. Практические задания ### Задание 1. Исследование учетной записи (Linux) ```bash whoami id grep "^$(whoami):" /etc/passwd sudo grep "^$(whoami):" /etc/shadow sudo chage -l $(whoami) awk -F: '$3 == 0 {print $1}' /etc/passwd # все учетные записи с UID 0 awk -F: '$3 >= 1000 && $3 < 65534 {print $1, $3, $7}' /etc/passwd # обычные пользователи ``` **Ответьте:** какой алгоритм хэширования используется? Когда истекает ваш пароль? Сколько учетных записей с UID 0? ### Задание 2. Создание пользователей и группы для проекта ```bash sudo groupadd project sudo useradd -m -s /bin/bash -G project student1 sudo useradd -m -s /bin/bash -G project student2 sudo useradd -m -s /bin/bash student3 sudo passwd student1; sudo passwd student2; sudo passwd student3 sudo mkdir /srv/project sudo chown root:project /srv/project sudo chmod 2770 /srv/project ``` Проверьте: 1. Может ли `student1` создать файл в `/srv/project`? Какая группа у созданного файла? 2. Может ли `student2` его изменить? (Подсказка: umask.) 3. Может ли `student3` выполнить `ls /srv/project`? 4. Установите `chmod 3770` (добавьте sticky bit). Может ли теперь `student2` удалить файл `student1`? ### Задание 3. umask ```bash umask touch a.txt; mkdir dirA; ls -ld a.txt dirA umask 077 touch b.txt; mkdir dirB; ls -ld b.txt dirB ``` Объясните полученные права расчетом. ### Задание 4. ACL ```bash echo "baholar" > grades.txt chmod 600 grades.txt setfacl -m u:student3:r grades.txt getfacl grades.txt ls -l grades.txt # обратите внимание на «+» chmod g-r grades.txt # что произошло с mask? getfacl grades.txt ``` Может ли `student3` прочитать файл после изменения mask? Почему? ### Задание 5. Поиск небезопасных настроек ```bash # setuid/setgid-программы find / -perm /6000 -type f 2>/dev/null # файлы, доступные на запись всем (кроме /proc, /sys) find / -xdev -type f -perm -0002 2>/dev/null # каталоги, доступные на запись всем, без sticky bit find / -xdev -type d -perm -0002 ! -perm -1000 2>/dev/null # файлы без владельца (осиротевшие UID) find / -xdev \( -nouser -o -nogroup \) 2>/dev/null # учетные записи с пустым паролем sudo awk -F: '$2 == "" {print $1}' /etc/shadow ``` ### Задание 6. Capabilities ```bash cp /usr/bin/python3 /tmp/py /tmp/py -m http.server 80 # ошибка: Permission denied sudo setcap cap_net_bind_service=+ep /tmp/py /tmp/py -m http.server 80 # работает без root getcap /tmp/py sudo rm /tmp/py ``` ### Задание 7. Windows ```powershell whoami /all Get-LocalUser Get-LocalGroupMember Administrators New-Item -ItemType Directory C:\Lab icacls C:\Lab icacls C:\Lab /inheritance:r icacls C:\Lab /grant "${env:USERNAME}:(OI)(CI)F" icacls C:\Lab /grant "Users:(OI)(CI)RX" icacls C:\Lab ``` **Ответьте:** какой уровень целостности у PowerShell, запущенной обычно и «от имени администратора»? Какие привилегии появляются в повышенном режиме? --- # 15. Типичные ошибки и рекомендации | Ошибка | Последствие | Правильно | |---|---|---| | `chmod -R 777` «чтобы заработало» | Любой пользователь и любая служба могут изменить файлы | Найти, какому субъекту нужен доступ, и дать минимальные права | | Работа под root / администратором постоянно | Любая ошибка или вирус получают полный контроль | Обычная учетная запись + `sudo` / UAC | | Одна общая учетная запись на несколько человек | Невозможно установить, кто что сделал | Персональные учетные записи | | Не удаляются учетные записи уволенных | Бывший сотрудник сохраняет доступ | Регулярный аудит, срок действия учетных записей | | `usermod -G` без `-a` | Потеря членства в группах | `usermod -aG` | | Служба работает от root | Взлом службы = взлом системы | Отдельный системный пользователь, capabilities, MAC-профиль | | Пользователь в группе `docker` «для удобства» | Фактически root без пароля | Rootless-Docker или sudo | | Отключение SELinux при первой ошибке | Потеря уровня защиты | Анализ `ausearch`, исправление контекстов | | NULL DACL на объекте Windows | Полный доступ всем | Явный DACL с минимальными правами | | Секреты в файлах с правами `644` | Чтение паролей любым пользователем | `600` / `640` с группой службы | --- # 16. Что необходимо запомнить 1. Безопасность ОС обеспечивает **конфиденциальность, целостность и доступность** ресурсов. 2. В ОС **субъект — это процесс**, действующий от имени учетной записи; **объект** — файл, устройство, память и т. д. 3. Все обращения проходят через **монитор обращений** ядра, который нельзя обойти. 4. Модели доступа: **DAC** (решает владелец), **MAC** (решает политика), **RBAC** (через роли), **ABAC** (через атрибуты). 5. Белл–ЛаПадула защищает **конфиденциальность** (no read up, no write down); Биба — **целостность** (no read down, no write up). 6. Linux идентифицирует пользователей по **UID/GID**, Windows — по **SID**. root — это **UID 0**. 7. Пароли хранятся только в виде **хэша с солью** (`/etc/shadow`, SAM). 8. В Linux проверка прав выбирает **одну** категорию (владелец → группа → остальные); в Windows права групп **суммируются**, а **Deny** имеет приоритет. 9. Удаление файла в Linux определяется правами **на каталог**; sticky bit защищает чужие файлы в общих каталогах. 10. setuid позволяет программе работать с правами владельца — это мощно и опасно. 11. ACL расширяет модель rwx; capabilities и привилегии разделяют всемогущество администратора. 12. Главный принцип — **минимальные привилегии**: каждый субъект получает только то, что ему действительно необходимо. --- # 17. Контрольные вопросы 1. Дайте определение безопасности ОС. Чем угроза отличается от уязвимости? 2. Объясните понятия «субъект», «объект», «право доступа». Приведите примеры для Linux и Windows. 3. Перечислите принципы Зальцера–Шрёдера. Какие из них нарушает команда `chmod 777`? 4. Что такое монитор обращений? Каким трем требованиям он должен удовлетворять? 5. Чем дискреционная модель доступа отличается от мандатной? Почему DAC уязвима к троянским программам? 6. Сформулируйте правила моделей Белла–ЛаПадулы и Биба. Какое свойство информации защищает каждая? 7. Чем ACL отличается от списка возможностей (capability list)? 8. Чем отличаются идентификация, аутентификация и авторизация? 9. Почему пароль + PIN-код не является многофакторной аутентификацией? 10. Зачем при хэшировании паролей используется соль? 11. Опишите поля файла `/etc/passwd` и `/etc/shadow`. Почему хэши вынесены в отдельный файл? 12. Что определяет права суперпользователя в Linux — имя `root` или что-то другое? 13. Чем отличаются real UID и effective UID? Когда они различны? 14. Что такое SID? Чем отличается поведение Linux и Windows при пересоздании пользователя с тем же именем? 15. Что содержит маркер доступа Windows? Чем привилегии отличаются от разрешений? 16. Что означают права `r`, `w`, `x` для каталога? Может ли пользователь удалить чужой файл, доступный ему только на чтение? 17. Вычислите права нового файла и каталога при `umask 027`. 18. Объясните назначение битов setuid, setgid и sticky. Приведите пример для каждого. 19. Владелец файла имеет права `---`, а остальные — `r--`. Может ли владелец прочитать файл? Почему? 20. Для чего нужна запись `mask` в POSIX ACL? 21. Что такое Linux capabilities? Приведите пример их использования. 22. Опишите структуру дескриптора безопасности Windows. Чем DACL отличается от SACL? 23. В чем разница между NULL DACL и пустым DACL? 24. Опишите канонический порядок ACE и алгоритм проверки доступа в Windows. 25. Пользователь имеет по сети Share-право «Чтение», а NTFS-право «Изменение». Каковы итоговые права? 26. Почему `sudo` предпочтительнее входа под root? Почему опасно разрешать через sudo запуск `vim`? 27. Как работает UAC? Что такое отфильтрованный маркер? 28. Чем SELinux отличается от AppArmor? В каком порядке проверяются DAC и MAC? 29. Что такое уровни целостности Windows и какое правило модели Биба они реализуют? 30. Предложите набор мер для защиты учетных записей в компьютерном классе университета. --- # 18. Глоссарий | Русский | O‘zbekcha | English | |---|---|---| | Безопасность ОС | OT xavfsizligi | OS security | | Учетная запись | Hisob qaydnomasi | User account | | Права доступа | Kirish huquqlari | Access rights / permissions | | Привилегия | Imtiyoz | Privilege | | Идентификация | Identifikatsiya | Identification | | Аутентификация | Autentifikatsiya | Authentication | | Авторизация | Avtorizatsiya | Authorization | | Субъект / объект | Subyekt / obyekt | Subject / object | | Владелец | Egasi | Owner | | Группа | Guruh | Group | | Список управления доступом | Kirishni boshqarish ro‘yxati | Access Control List (ACL) | | Дискреционное управление доступом | Diskretsion kirishni boshqarish | Discretionary Access Control (DAC) | | Мандатное управление доступом | Mandatli kirishni boshqarish | Mandatory Access Control (MAC) | | Ролевое управление доступом | Rolga asoslangan kirishni boshqarish | Role-Based Access Control (RBAC) | | Принцип минимальных привилегий | Minimal imtiyozlar tamoyili | Principle of least privilege | | Хэш-функция, соль | Xesh funksiyasi, tuz | Hash function, salt | | Угроза / уязвимость / атака | Tahdid / zaiflik / hujum | Threat / vulnerability / attack | | Монитор обращений | Murojaatlar monitori | Reference monitor | | Маркер доступа | Kirish markeri | Access token | | Дескриптор безопасности | Xavfsizlik deskriptori | Security descriptor | | Повышение привилегий | Imtiyozlarni oshirish | Privilege escalation | | Журнал аудита | Audit jurnali | Audit log | | Многофакторная аутентификация | Ko‘p faktorli autentifikatsiya | Multi-factor authentication (MFA) | --- # 19. Литература 1. Таненбаум Э., Бос Х. *Современные операционные системы.* 4-е изд. — СПб.: Питер, 2015. — Гл. 9 «Безопасность». 2. Silberschatz A., Galvin P., Gagne G. *Operating System Concepts.* 10th ed. — Wiley, 2018. — Ch. 16–17 (Security, Protection). 3. Stallings W. *Operating Systems: Internals and Design Principles.* 9th ed. — Pearson, 2017. — Ch. 15. 4. Russinovich M., Solomon D., Ionescu A., Yosifovich P. *Windows Internals.* 7th ed., Part 1. — Microsoft Press, 2017. — Ch. 7 «Security». 5. Kerrisk M. *The Linux Programming Interface.* — No Starch Press, 2010. — Ch. 8, 9, 15, 17, 39. 6. Saltzer J., Schroeder M. *The Protection of Information in Computer Systems.* Proc. IEEE, 1975. 7. Документация: `man 5 passwd`, `man 5 shadow`, `man 1 chmod`, `man 5 acl`, `man 7 capabilities`, `man 5 sudoers`, `man 8 pam`. 8. Microsoft Learn: *Access Control*, *Security Identifiers*, *How User Account Control works*.