мета-данные страницы
  •  

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

Предыдущая версия справа и слеваПредыдущая версия
Следующая версия		Предыдущая версия
notes:howlinuxworks:vol7 [2026/05/18 15:40] – radi0devnotes:howlinuxworks:vol7 [2026/05/18 16:18] (текущий) – radi0dev
Строка 453: Строка 453:
 Команда **systemd-run** создаёт таймеры без юнит-файлов, но многие предпочитают cron Команда **systemd-run** создаёт таймеры без юнит-файлов, но многие предпочитают cron
  
 +===== 7.7 Планирование разовых задач с помощью службы at =====
  
 +Выполнить задачу **один раз в будущем** без cron:
 +
 +<code bash>
 +$ at 22:30
 +at> myjob
 +# Ctrl+D для завершения
 +</code>
 +
 +^ Команда ^ Действие ^
 +| atq | Список запланированных задач |
 +| atrm | Удалить задачу |
 +| at 22:30 30.09.15 | Запланировать на дату и время |
 +
 +==== 7.7.1 Аналоги таймера ====
 +
 +Замена **at** на **systemd-run**:
 +
 +<code bash>
 +# systemd-run --on-calendar='2022-08-14 18:00' /bin/echo this is a test
 +Running timer as unit: run-rbd000cc6ee6f45b69cb87ca0839c12de.timer
 +Will run service as unit: run-rbd000cc6ee6f45b69cb87ca0839c12de.service
 +
 +# Смещение по времени (выполнить через 30 минут)
 +# systemd-run --on-active=30m /bin/command
 +
 +# Просмотр таймеров
 +systemctl list-timers
 +</code>
 +
 +**--on-calendar** требует **будущую дату и время**, иначе таймер запустится ежедневно
 +
 +===== 7.8. Юниты таймера обычных пользователей =====
 +
 +Создать таймер от имени обычного пользователя:
 +
 +<code bash>
 +$ systemd-run --user --on-calendar='2022-08-14 18:00' /bin/echo test
 +</code>
 +
 +**Проблема:** таймер не запустится, если пользователь вышел из системы
 +
 +**Решение - сохранить менеджер пользователя:**
 +
 +<code bash>
 +# Для текущего пользователя
 +$ loginctl enable-linger
 +
 +# Для другого пользователя (от root)
 +# loginctl enable-linger user
 +</code>
 +
 +===== 7.9 Доступ пользователя =====
 +
 +Управление входом, переключением пользователей и защитой. **Продвинутый уровень.**
 +
 +==== 7.9.1 ID пользователей и переключение пользователей ====
 +
 +**Переключение = смена идентификатора пользователя (UID)** через:
 +  1. Исполняемый файл **setuid** (пример: sudo, su)
 +  2. Системные вызовы **setuid()**
 +
 +=== Правила ядра (основные) ===
 +
 +  1. Процесс может запустить setuid файл, если **имеет права доступа** на него
 +  2. **Суперпользователь (UID 0)** может вызвать setuid() и **стать любым пользователем**
 +  3. **Обычный пользователь** практически **не может использовать setuid()**
 +
 +**Следствие:** sudo имеет права setuid от root → может вызвать setuid() и переключиться на другого пользователя
 +
 +Переключение пользователей независимо от паролей и имён - чисто концепция пользовательского пространства (как /etc/passwd)
 +
 +==== 7.9.2 Владельцы процессов, действующий UID, реальный UID и сохраненный UID ====
 +
 +Каждый процесс имеет **несколько UID идентификаторов**:
 +
 +^ UID ^ Назначение ^ Пример ^
 +| **euid** (effective) | Определяет **права доступа** к файлам (исполнитель) | Setuid программа меняет на владельца файла |
 +| **ruid** (real) | **Кто инициировал** процесс (владелец) | Обычный пользователь, запустивший sudo |
 +| **saved UID** | Процесс может переключиться между euid и ruid | Позволяет вернуться к исходному UID |
 +| **fsuid** | Редко: доступ к файловой системе | Практически не используется |
 +
 +**Аналогия:** euid = исполнитель, ruid = владелец
 +
 +**ruid определяет, кто может завершить/контролировать процесс**
 +
 +Пример: пользователь A запускает setuid программу от B → A остаётся владельцем (ruid) и может убить процесс
 +
 +=== Просмотр UID ===
 +
 +<code bash>
 +$ ps -eo pid,euser,ruser,comm
 +</code>
 +
 +Для большинства процессов euid = ruid (поэтому они совпадают в выводе по умолчанию)
 +
 +=== Типичное поведение setuid программ ===
 +
 +**sudo, su и похожие программы явно меняют оба UID (euid и ruid)** чтобы избежать побочных эффектов и проблем с доступом
 +
 +Если нужно запретить sudo менять ruid - добавить в **/etc/sudoers**:
 +<code bash>
 +Defaults stay_setuid
 +</code>
 +
 +**Осторожно**: может повлиять на другие setuid программы
 +
 +=== Последствия для безопасности ===
 +
 +Setuid программы - **основной путь взлома систем**
 +
 +**Критические риски:**
 +  * Setuid копия bash → **любой локальный пользователь = полный контроль**
 +  * Баги в setuid программах = вторжение
 +  * Большое количество setuid файлов = большой риск
 +
 +**Защита:**
 +  * **Минимизировать** количество setuid программ
 +  * **Проверять качество** setuid кода
 +  * **Идентифицировать пользователей** надёжными паролями
 +
 +==== 7.9.3 Идентификация пользователя, аутентификация и авторизация ==== 
 +
 +Система безопасности включает три области:
 +  * **Идентификация** - определение, кем является пользователь
 +  * **Аутентификация** - доказательство личности
 +  * **Авторизация** - определение разрешенных действий
 +
 +Ядро Linux оперирует только числовыми UID. Вся аутентификация (имена, пароли) реализована в userspace.
 +
 +**Упрощенный процесс получения имени пользователя:**
 +  1. Вызов getuid() для получения euid
 +  2. Открыть /etc/passwd
 +  3. Прочитать строку, разобрать по полям (разделитель ':')
 +  4. Сравнить UID из файла с полученным
 +  5. При совпадении - найдено имя пользователя
 +
 +==== 7.9.4 Применение библиотек для получения информации о пользователе ==== 
 +
 +**Стандартные библиотеки** упрощают работу. Вместо ручной реализации используется getpwuid() после geteuid().
 +
 +**Преимущества:** Изменение источника данных (с /etc/passwd на LDAP) не требует изменения программ.
 +
 +**Недостатки традиционного подхода с паролями в /etc/passwd:**
 +  * Отсутствие единого стандарта шифрования
 +  * Требует доступа к зашифрованному паролю
 +  * Запрос пароля при каждой аутентификации
 +  * Не поддерживает альтернативные методы (токены, смарт-карты, биометрия)
 +
 +===== 7.10 Подключаемые модули аутентификации (PAM) =====
 +
 +**PAM** (Pluggable Authentication Module) - стандарт от Sun Microsystems (1995) для гибкой аутентификации. Система разделяемых библиотек позволяет добавлять методы аутентификации (двухфакторная, ключи) без изменения приложений.
 +
 +Модули - динамически загружаемые объекты (.so). Пример: pam_unix.so проверяет пароль.
 +
 +==== 7.10.1 Конфигурация PAM ====
 +
 +Файлы конфигурации: **/etc/pam.d/** (старые системы: /etc/pam.conf)
 +
 +**Структура строки конфигурации (3 поля):**
 +
 +^ Поле ^ Описание ^ Пример ^
 +| **Тип функции** | Операция, запрашиваемая приложением | auth, account, session, password |
 +| **Аргумент управления** | Поведение при успехе/неудаче | sufficient, requisite, required |
 +| **Модуль** | Модуль аутентификации | pam_shells.so |
 +
 +**Типы функции:**
 +  * **auth** - аутентификация (кто ты?)
 +  * **account** - проверка статуса учетной записи
 +  * **session** - действия только для текущего сеанса (motd)
 +  * **password** - изменение пароля
 +
 +**Управляющие аргументы (стек правил):**
 +  * **sufficient** - успех → немедленный успех, пропустить остальные; неудача → далее
 +  * **requisite** - успех → далее; неудача → немедленный отказ
 +  * **required** - успех → далее; неудача → далее, но всегда отказ в конце
 +
 +**Пример стека (функции аутентификации chsh):**
 +<code>
 +auth sufficient pam_rootok.so
 +auth requisite pam_shells.so
 +auth sufficient pam_unix.so
 +auth required pam_deny.so
 +</code>
 +
 +++++При такой конфигурации, когда команда chsh запрашивает у PAM функцию аутентификации, PAM выполняет следующее|
 +  - Модуль pam_rootok.so проверяет, не пытается ли суперпользователь пройти аутентификацию. Если это так, процесс немедленно выполнится успешно и не будет пытаться выполнить дальнейшую аутентификацию. Это сработает, потому что аргумент управления имеет значение sufficient, что означает: выполнения этого действия достаточно для того, чтобы модуль PAM немедленно сообщил об успехе chsh. В противном случае он переходит к шагу 2.
 +  - Модуль pam_shells.so проверяет, указана ли оболочка пользователя в файле /etc/shells. Если ее там нет, модуль возвращает ошибку и аргумент управления requisite указывает, что модуль PAM должен немедленно сообщить об этом сбое chsh и не пытаться выполнить аутентификацию. В противном случае модуль успешно завершит выполнение и в соответствии с требованиями аргумента управления requisite перейдет к шагу 3.
 +  - Модуль pam_unix.so запрашивает у пользователя пароль и проверяет его. Аргументу управления присвоено значение sufficient, поэтому успеха данного модуля (правильного пароля) достаточно, чтобы PAM сообщил об этом оболочке chsh. Если пароль неверен, PAM переходит к шагу 4.
 +  - Модуль pam_deny.so никогда не выполняется, и поскольку аргумент управления установлен в значение required, PAM сообщает об ошибке в оболочку chsh. Это значение используется по умолчанию для случаев, когда больше нет вариантов действий. (Обратите внимание, что аргумент управления required не приводит к немедленному сбою функции PAM: он будет запускать все строки, оставшиеся в его стеке, но при этом модуль всегда будет сообщать приложению о сбое.)
 +
 +{{:notes:howlinuxworks:pic_7.4.png}}
 +++++
 +
 +**Аргументы модулей:** После имени модуля (пример: `pam_unix.so nullok` - пароль может отсутствовать)
 +
 +==== 7.10.2 Советы по синтаксису конфигурации PAM ====
 +
 +  * Список модулей: `man -k pam_`
 +  * Локализация: `locate pam_unix.so`
 +  * Комментарии в /etc/pam.d указывают на источник генерации
 +  * **/etc/pam.d/other** - конфигурация по умолчанию (обычно запрещает всё)
 +  * Включение файлов: `@include` или управляющие аргументы
 +  * Дополнительные настройки в **/etc/security**
 +
 +==== 7.10.3 Модули PAM и пароли ====
 +
 +**/etc/login.defs** - конфигурация shadow-паролей (алгоритм шифрования). Используется редко при наличии PAM.
 +
 +**Установка пароля (функция password):**
 +<code>
 +password sufficient pam_unix.so obscure sha512
 +</code>
 +
 +Аргументы: obscure (проверка надежности), sha512 (алгоритм).
 +
 +**Проверка пароля (функция auth):** pam_unix.so автоматически определяет алгоритм через libcrypt (перебор), нет аргументов шифрования.
 +
 +**Поиск конфига:** `grep password.*unix /etc/pam.d/*`