Загрузил nurdilda1998

Bosy

Реклама
1.Основные св-в безопасной ОС. Основные принципы построения безопасных ОС.
ОС – сов-ть управляемых программ, которые связывают устройства вычислит. системы и
прикладные программы, а также позволяют управлять устройствами и вычислительными
процессами, распределяя в т.ч. ресурсы между ними.
Базовое требование безопасной ОС – обеспечение без-ти инф-ции. Безопасная ОС
должна гарантировать безопасное или доверенное выполнение небезопасных компонент
(программ); Стороннее ПО по опр-ю небезопасно; Функционал ядра – доверенный.
Построение безопасной ОС: 1. Надстройка существующих ОС (Ядро не меняется; Безть вносится через доп. модули + ПО; Доступ через ядро не защищен); 2. Изменение
существующих ядер; 3. Создание нового безопасного ядра
Принципы без-ти ОС: Иерархич. структура ОС; Контроль и аудит всех действий пользля; Резервирование состояний процессов ядра; Исп-е принципов ООП
2.Стандарты ИБ в обл. ОС. Оценка и сертификация ОС по треб-ям без-ти инф-ции
Cертификация продукции – деят-ть по подтверждению соотв-я продукции установл.
требованиям. Cертификат соотв-я – док-т, удостоверяющий соотв-е объекта
требованиям технич. регламентов, положениям стандартов, сводов правил или усл-ям
договоров. Сертифицир. ПО – ПО, ранее прошедшее сертификацию, установленное,
настроенное и сопровождаемое в соотв-и с требов-ями, прошедшими сертиф-ю
Закон РФ от 21.07.1993 N 5485-1 «О гос. тайне» регулирует отн-я, возникающие в связи
с отнесением сведений к гос. тайне, их засекречиванием или рассекречиванием и
защитой в интересах обеспечения без-ти РФ.
Уровни секретности и соответств-е
им грифы секретности: особой
важности, совершенно секретные,
секретные.
ФСТЭК – главный в области ОС
(назначает испытат. лабораторию)
РД ГТК (Руководящий док-т
Гостехкомиссии России) – док-т,
устанавливающий классификацию АС, подлежащих защите
от несанкционир. доступа к инф-ции, и требования по
защите инф-ции в АС разл. классов.
4 уровня контроля отсутствия НДВ:
 Первый (самый высокий уровень), достаточен для ПО,
используемого при защите инф-ции с грифом «ОВ».
 Второй: достаточен для ПО, используемого при защите инф-ции с грифом «CC».
 Третий: достаточен для ПО, используемого при защите инф-ции с грифом «C».
 Четвертый: достаточен для ПО, используемого при защите конфиденц. инф-ции
«Оранжевая книга» (TCSEC): (разработано Мин. Обороной США в 1983-85 гг), как
оценочный стандарт поясняет понятие безопасной системы, которая «управляет, с
помощью соответств. средств, доступом к инф-ции так, что только должным образом
авторизованные лица или процессы, действующие от их имени, получают право читать,
записывать, создавать и удалять инф-цию».
Классы защищенности компьютерных систем по TCSEC:
 Группа А. Верифицир. защита: хар-ся применением формальных методов
верификации корректности работы механизмов упр-я доступом (дискреционный и
мандатный). Требуется, чтобы было формально показано
соотв-е архитектуры и реализации ТСВ треб-ям без-ти.
 Группа В. Мандатное упр-е доступом (В1,В2,В3): Осн. требовя группы: мандатное (полномочное) упр-е доступом с исп-ем
меток без-ти, реализация некоторой формальной модели
политики без-ти, наличие спецификаций на функции ТСВ.
 Группа С. Дискрец. защита (С1,С2): наличие дискрец. упр-я
доступом и аудит действий субъектов
 Группа D. Миним. защита: зарезервирован для тех систем,
которые были представлены на сертификацию (оценку), но по
какой-либо причине ее не прошли.
DAC – дискрец. модель доступа – комбинация произвольного упря доступом (субъект-субъектная модель) и доступа на основе списков (ACL).
MAC – мандатное упр-е доступом
3. Упр-е доступом в ОС. Дискрец. упр-е дост. Особ-ти реал-ции в ОС UNIX и Linux
Механизмы упр-я доступом в ОС Linux:
 Механизм дискреционного упр-я доступом (DAC): все процессы запускаются от
имени польз-ля и группы. Эти процессы имеют доступ ко всем файлам и каталогам,
доступ к которым могут получить польз-ль и группа. Т.о. ошибочный процесс может
разрушить все файлы, кот. принадлежат польз-лю.
 Механизм, реализующий списки контроля доступа (ACL): позволяет расширять
привилегии для не администраторов при доступе к файлам, но все же только root
имеет полную свободу действий над файловой системой.
 Сущ-ют доп. средства разграничения доступа, позволяющие реализовать механизм
мандатного упр-я доступом (MAC): позволяет установить разрешения на то, как
процессы взаимодействуют с др. частями системы: файлами, устройствами, портами,
др, процессами. Это осущ-ся с помощью политик, установленных администратором и
полностью определяющих доступ польз-ля. Напр, SELinux.
DAC реализуется в виде прав доступа для файлов. При этом права разделяются на
права владельца файла, права группы владельцев и права остальных. Суперпольз-ль
может изменить права доступа к любым файлам и каталогам.
Пример: $ ls –al
drwxr-xr-x 2 dale other …
-rw-r----- 1 dale admin …
Изменение прав доступа: chmod [u/g/o/a] [=+-] [r/w/x] файлы
[u/g/o/a] – кому [польз-ль/группа/остальные/всем (=ugo)]
[=+-] – [установить/добавить/удалить]
[r/w/x] – право на [чтение/запись/выполнение]
Пример: chmod ug=rw files
Изменение владельца: chown {-R} владелец[:группа] файл
Права, устанавливаемые на директорию:
r – можно просмотреть список файлов в дир-и (не подразумевает доступ к самим файлам)
w – можно создать, переименовать, удалить файлы в директории;
x – можно переходить в директорию и иметь доступ к файлам в ней.
Чтобы создать файл в директории:
--x – разрешение на все папки в директории;
-wx – разрешение на последнюю папку в указанном пути.
Чтобы прочитать файл в директории:
--x – разрешение на все папки в указанном пути;
r-- – разрешение на файл.
Чтобы писать в файл:
--x – разрешение на все папки в пути
-w- – разрешение на файл
Так же есть такие биты как SetUID, SetGID, sticky-bit.
File
directory
с правами
u + s Запуск
В большинстве версий игнорируется
владельца файла
с правами группы При создании папок (файлов) в этой директории
g + s Запуск
файла
группа владельца наследуется от группы каталога
основном исп-ся для
o + t (в
Удалять файлы может только владелец и root
каталогов)
4.Упр-е дост. в ОС. Принудит. упр-е дост. Особ-ти реализации в ОС UNIX и Linux.
Сущ-ет 3 основных подхода к упр-ю доступом:
 Дискреционный метод (избирательный/произвольный) разграничения доступа к
объектам (файлам) основан на учете личности субъекта (польз-ля) или группы, в
которую субъект входит. Произвольность упр-я состоит в том, что некоторое лицо
(обычно владелец объекта) может по своему усмотрению предоставлять другим
субъектам или отбирать у них права доступа к объекту.
 Ролевой метод предполагает наличие вместо субъекта ролей (абстрактных сущностей,
с которыми связаны наборы ограниченных и непротиворечивых полномочий) и
польз-лей, которые обладают одной или несколькими ролями.
 Принудительный метод (мандатный) представляет собой ассоциацию с субъектами и
объектами меток без-ти. Как правило, метки без-ти образуют иерархию. Напр,
совершенно секретно -> секретно -> конфиденциально -> не секретно.
Рассмотрим подробнее принудит. метод. Субъект может читать инф-цию из объекта,
если уровень секретности субъекта не ниже, чем у объекта (читать можно только то, что
положено). Субъект может записывать инф-цию в объект, если метка без-ти объекта
доминирует над меткой субъекта. Преимущества метода: отсутствие избыточной
детализации отн-я субъект-объект, невозм-ть полного упр-я польз-лем доступом к
создаваемым им ресурсам, возм-ть запрещать доступ польз-лям или процессам к
сущностям более высокого уровня. Недостатки метода: зачастую в пределах одного
уровня доступа происходит избыточность прав доступа субъекта. Несмотря на то, что в
ОС семейства UNIX в качестве основной исп-ся дискрец. модель доступа, для них сущ-ют
реализации систем упр-я принудит. доступом (напр, SELinix, AppArmor, TOMOYO
Linux). Система принудит. контроля доступа SELinux включена в ядро Linux. SELinux
существенно расширяет ядро Linux, делая ОС, построенные на его основе, пригодными к
исп-ю в сферах, где доступ к инф-ции д.б. строго разграничен, а приложения, запускаемые
польз-лями, должны иметь опр. набор прав, который не выходит за рамки минимально
необходимого. При этом SELinux позволяет параллельно работать с классической
дискреционной моделью доступа.
5. Суб. и объекты доступа в ОС. Атр. без-ти файла в ОС Linux. Хранение атр. без-ти.
Объект доступа – часть информац. системы, доступ к которой м.б. ограничен политикой
без-ти. Каждый объект имеет уникальное имя, отличающее его от других объектов в
системе. Как правило, объекты доступа имеют составную структуру. С файлом
ассоциированы дескриптор, указатель позиции, файловый буфер, режим доступа.
Мультимедийный объект состоит из одного или нескольких файлов, а также связанных
настроек исп-я. Субъект доступа – любая сущность, способная инициировать
выполнение операций над объектами. В случае ПО субъектом доступа считается
логический польз-ль, от имени которого выполняются программные процессы.
Конкретному физич. польз-лю может соответствовать несколько субъектов доступа с
разными уровнями доступа. Также сущ-ют субъекты доступа, не соответствующие
конкретным физич. польз-лям, от имени которых выполняются системные процессы.
Атрибуты без-ти файла в ОС Linux. Unix каждому файлу соотв-ет набор прав доступа,
представленный в виде 9-ти битов режима. Он определяет, какие польз-ли имеют право
читать файл, записывать в него данные или выполнять его. Вместе с др. 3мя битами,
влияющими на запуск исполняемых файлов, этот набор образует код режима доступа к
файлу. 12 битов режима хранятся в 16-битовом поле индексного дескриптора вместе с 4мя
доп. битами, определяющими тип файла. Последние 4 бита устанавливаются при создании
файлов и не подлежат изменению. Флаг исп-я трактуется по-разному в зависимости от
типа файла. В случае простого файла он задаёт возм-ть исполнения файла, т.е. запуска
программы, содержащейся в этом файле. Для директории – это возм-ть доступа к файлам
в этой директории. Т.о. из своего каталога польз-ль может удалить любой файл. А если
запись в каталог разрешена всем, то любой польз-ль сможет удалить в нём любой файл.
Для избежания этой проблемы был добавлен ещё один бит в права доступа каталога: бит
навязчивости (sticky, t-бит). При его установке польз-ль, имеющий доступ на запись в этот
каталог, может изменять только собственные файлы. Для разрешения подмены
идентификатора польз-ля применяется бит подмены идентификатора пользова теля (set
user id, suid-бит, s). Этот бит применяется совместно с битом исполнения (x) для обычных
файлов. При установке этого бита на исполняемый файл процесс запускается от имени
владельца, а не от имени запускаеющего польз-ля
Хранение атрибутов без-ти. Атрибуты файла + расширенные атрибуты хранятся в
структуре inode. К расширенным атрибутам относятся списки контроля доступа ACL,
атрибуты SELinux и др. Атрибуты, для которых недостаточно места в структуре inode,
хранятся в отдельном блоке размером 4 KB.
6. Суб. и об. доступа в ОС. Атр. без-ти процесса. Хранение атр.в без-ти. Жиз. цикл
процесса. Сост-я процесса. Вып-е процесса в режиме ядра и в режиме польз-ля.
Объект доступа – эл-т ОС, к которому осущ-ся доступ (файлы). Субъект доступа –
сущность, которая осуществляет доступ (процессы). Процесс – экземпляр запущенной,
выполняемой программы. Состоит из адресного пространства выделенной памяти,
параметров без-ти, потоков выполнения программного кода, состояния.
Важные атрибуты процессов:
 Process ID (PID): число, которое однозначно определяет процесс в
системе (0, 1 и 2 – спец. системные процессы)
 Данные и сегменты стека: инф-ция о виртуальной памяти процесса
и сопоставление виртуальной памяти с физическим ресурсом.
 Идентификаторы польз-лей и групп (UID и GID): реальный и
эффективный UID и GID (обычно реальный = эффективный, но в
некоторых случаях различны).
 Терминал (TTY): терминал, с которого запущен процесс
В ядре процесс представлен в виде структуры (дескриптор процесса).
Жизненный цикл процесса. Все новые процессы в Linux порождаются клонированием
какого-то уже имеющегося процесса, с помощью вызова системных функций clone() и
fork(). Первый процесс запускается при инициализации ядра (процесс init, PID = 1).
Этапы запуска создания нового процесса:
1. Процесс /bin/bash клонирует себя системным вызовом fork()
2. При этом создается клон /bin/bash с новым PID и PPID
3. Клон
выполняет
системный вызов exec() с
указанием
на
исполняемый файл и
заменяет свой код кодом
исполняемого
файла
(родительский
процесс при этом ждет
завершения потомка wait)
4. Если процесс завершил
свою работу, а
родительский процесс не
смог получить об этом
сигнал, то процесс не
освобождает занятые
структуры ядра и
состояние процесса
становиться - zombie.
5. Состояния процесса
Название Флаг
Описание
Running
R процесс либо выполняется, либо ждет выполнения
S процесс ждет выпол-я некоторых усл-й и возвращается к Running
D процесс ждет опр. сигнала от аппаратной части (работа с диском)
Sleeping
K состоянию D + реагирует на сигнал завершения процесса
Stopped
T процесс остановлен польз-лем или трассируется
процесс, выполнение которого завершилось, но относящиеся к нему
Z структуры ядра не освобождены
Zombie
X процесс полностью уничтожается (освобождение ресурсов)
Выполнение процесса
 в режиме ядра процесс выполняет системные инструкции ядра
 в режиме польз-ля процесс выполняет прикладные инструкции польз-ля
ps – выводит инф-цию о процессах: PID, TTY, TIME, COMMAND ps -e – выводит инфцию обо всех процессах
ps j – выводит инф-цию о процессах: PPID, PID, TTY, STATE, UID, COMMAND и др.
7. Субъекты и объекты доступа в ОС. Взаимод-е процессов в ОС Linux. Механизм
сигналов. Реакция на получение сигнала. Игнорир-е и перехват сигналов.
Упр-е доступом – огр-е или искл-е несанкционир. доступа к инф-ции и программным
средствам. Объект системы – Ɐ её идентифицируемый ресурс (напр, файл / устройство).
Доступ к объекту системы – некоторая заданная в ней операция над этим объектом (чтение
/ запись). Субъект доступа – Ɐ сущность, способная инициировать выполн-е операций над
эл-тами ОС (польз-ли, процессы). Процесс – программа, выполняющаяся в операт. памяти
компьютера. Сигнал – асинхронное уведомление процесса о каком-либо событии с
терминала, нажатием спец. клавиш или комбинаций. Сигнал м.б. послан ядром системы
(при возникн-и аппаратных искл-й, ошибочных системных вызовах, для информирования
о событиях ввода-вывода), одним процессом другому (или самому себе), с помощью
системного вызова kill(), в т.ч. из шелла, утилитой kill. kill [-SIG] PID [PID..]
SIG – номер сигнала или наименование сигнала. PID – process ID.
Некоторые виды сигналов:
Номер сигнала Наименование сигнала (SIG) для kill
Что делает
3
SIGQUIT
Keyboard quit
9
SIGKILL
Убить процесс полностью
15
SIGTERM
М.б. обработан
18
SIGCONT
Продолжить
19
SIGSTOP
Не м.б. заблокирован
Чтобы посмотерь все возможные сигналы в консоли: kill -l
Каждый польз-ль может использовать kill для своих процессов, root – для всех.
Варианты реакции процесса на сигнал:
1. Принудительно проигнорировать сигнал.
2. Произвести обработку по умолчанию:
a. проигнорировать,
b. остановить процесс: перевести в состояние ожидания до получения др. спец. сигнала
c. завершить работу с образованием core файла или без него.
3. Выполнить обработку сигнала, специфицированную польз-лем.
В исполняемой программе м.б. определены обработчики ожидаемых к программе
сигналов, чтобы изменить действия обработчиков по умолчанию.
Игнорирование сигналов. В заголовочном файле <signal.h> определены 2 константы:
SIG_DFL означает выполнение действий по умолчанию – в большинстве случаев –
окончание процесса, а SIG_IGN – означает игнорировать сигнал. В программе можно
определить signal(SIGINT, SIG_IGN); Если теперь нажать на комбинацию клавиш
CTRL+C, ничего не произойдет, так как сигнал SIGINT игнорируется.
Перехват сигналов. Сигнал перехватывается, если установлено правило перехвата с
помощью команды trap, которая опр-ет действия (команды) при перехвате сигналов.
trap [COMMANDS] [SIGNALS]
command– что именно необходимо выполнить при перехвате сигнала; signals– список
сигналов, которые необходимо перехватывать. Сигналы можно указывать как в полном
виде –SIGTERM, так и в виде кода – 1, 2 и т.д.
Пример: trap 'echo "Exit"; exit 1' 1 2 3 15
Когда во время ожидания завершения команды Bash принимает сигнал, для которого была
установлена команда trap, команда trap не будет выполняться до завершения
исполняемой команды. Когда Bash с помощью встроенной команды wait ожидает
выполнение асинхронной команды, прием сигнала, для которого была задана команда
trap, вызовет немедленный выход из встроенной команды wait с кодом возврата, большим
128, а затем сразу будет выполнена команда trap.
8.Упр-е доступом польз-лей к файлам в ОС Linux. 3 категории польз-лей.
Суперпольз-ль root. Назначение владельца файла и группы-владельца файла при
создании файла. Изменение владельца файла и группы-владельца файла.
Каждый польз-ль в системе имеет свой уникальный ID (user-ID, или UID). Также польз-ли
могут объединяться в группы, которые в свою очередь имеют group-ID, или GID. Чтобы
узнать свой UID и GID, необходимо ввести команду id.
У каждого файла есть индивидуальные права доступа, хранящиеся в inode, которые
разбиты на 3 группы: Доступ для польз-ля-владельца файла (owner); Доступ для группывладельца файла (group); Доступ для остальных польз-лей (others).
$ ls –l
drwxr-xr-x 6 hp hp 4096 апр 24 19:52 vm
root – суперпольз-ль системы (польз-ль с идентификатором 0). Это польз-ль обладает
наивысшими привилегиями в ОС.
В индексном дескрипторе (inode) каждого файла записаны имя владельца файла и группы,
которая имеет права на этот файл. При создании файла его владельцем объявляется тот
польз-ль, от чьего имени запущен процесс, создающий файл. Группа назначается – по
идентификатору группы процесса, создающего файл.
Владельца и группу файла можно поменять в ходе дальнейшей работы с помощью команд
chown и chgrp
chown польз-ль[:группа] файл…
chgrp группа файл… (меняет только группу)
Например: chown root foofile
Теперь файл foofile принадлежит к польз-лю root
chown : admins foofile
Теперь файл foofile принадлежит к группе admins
Чтобы изменить польз-ля или польз-ля и группу для всей директории исп-ся флаг -R (для
chgrp также)
chown - R student foodir
Теперь папка foodir и файлы в ней принадлежат польз-лю student.
Важно! Только root может менять владельца файла! Группу владельца файла может также
изменять и сам владелец файла.
9. Упр-е дост. польз-лей к файлам в ОС Linux. Права доступа к файлам и кат-гам в
ОС Linux. Кодир-е прав доступа. Влия-е прав доступа на вып-е операций над ф и к.
Просмотреть текущие права доступа можно по команде:
 ls -l filename – для файла
 ls -ld /dirname – для каталога
Результат выполнения команды:
 user – имя владельца файла
 users – имя группы владельца файла
Типы файлов: Обычный файл (-);
Каталог (d); Файл символьного устройства (с); Файл блочного устройства (b); Сокет (s);
Именованный канал (p); Символическая ссылка (l)
Выделяют 3 группы, которые могут иметь права доступа к файлам: user (u) – владелец
файла; group (g) – группа владельца файла; others (o) – все остальные; и 3 вида прав доступа
для каждой группы: право на чтение (r); право на запись (w); право на исполн-е (x)
Спец. права доступа к файлам в Linux.
 SUID (Set User ID): если этот бит установлен, то при выполнении программы, id пользля, от которого она запущена заменяется на id владельца файла. Т.е. это позволяет
обычным польз-лям запускать программы от имени суперпольз-ля
 SGID (Set Group ID): аналогичен SUID, но относится к группе (польз-ль считается
членом группы, с которой связан файл, а не групп, к которым он действительно
принадлежит). Если бит SGID установлен для каталога, то создаваемые в нем объекты
будут получать группу владельца каталога, а не польз-ля;
 Sticky-bit: исп-ся в основном для каталогов. Если он установлен, то польз-ли могут
только создавать, читать и выполнять файлы, но не могут удалять файлы,
принадлежащие другим польз-лям.
Спец. права исп-ся довольно редко, поэтому при выводе команды ls -l
символ, обозначающий указанные атрибуты, закрывает символ
стандартных прав доступа.
В приведенном примере не понятно, rwt – это rw- или rwx? Если t
маленькое, значит x установлен. Если T большое, значит x не
установлен. То же самое правило распространяется и на s.
Влияние прав доступа на выполнение операций над файлами и каталогами.
Разрешение
Влияние на файлы
Влияние на каталоги
прочитать
Можно просмотреть содержимое каталога
r (read) Можно
содержимое файла
(имена файлов в каталоге)
Можно
изменить
Можно создать или удалить любой файл в
w (write) содержимое файла
каталоге
м.б. выполнен как Можно обращаться к содержимому каталога
x (execute) Файл
команда
(зависит от разрешений файлов в каталоге)
10. Упр-е доступом польз-лей к файлам в ОС Linux. Назначение прав доступа к
файлам и каталогам при создании файла. Маска доступа. Изменение прав доступа.
Являясь владельцем файла, вы можете воспользоваться утилитой chmod для изменения
прав доступа к этому файлу.
Символьные аргументы: chmod [ключи] кто оператор право список_файлов
Аргумент кто: u – польз-ль, g – группа, o – все остальные, a – все. Аргумент оператор: “+”
– добавление прав, “-” – удаление прав, “=” – установка прав переустанавливает все права)
r – право на чтение;
X – превращение файла в исполняемый,
только если он является каталогом или если
w – право на запись;
у класса польз-лей «все остальные» есть
x – право на выполнение;
s – установка ID польз-ля или ID группы права на выполнение;
в качестве владельца выполняемого u – установка тех же прав, как у владельца
g – установка таких же прав, как у группы
файла (setuid, setgid);
t – установка бита флажка огр-я прав на o – установка тех же прав, как у всех
остальных.
удаление (sticky bit);
Пример: chmod a=rw temp (изменить режимы доступа для всех польз-лей, давая им право
на чтение файла и запись в него)
Числовые аргументы:
chmod [ключи] режим список_файлов
Для указания режима нужно использовать восьмеричное число. Первое число определяет
права доступа для владельца, второе – для группы, а третье – для всех остальных, при этом
r – заменяют на 4; w – заменяют на 2; x – заменяют на 1.
Для получения числа, представляющего права доступа для владельца, для группы или для
всех остальных, нужно сложить соответствующие числа.
Пример: chmod 640 temp
(число 6 – дает владельцу права на чтение и запись (4+2), число 4 дает группе право на
чтение, число 0 удаляет все права для остальных польз-лей)
Атрибуты setuid, setgid и sticky bit устанавливаются следующим образом:
Режим
Значение
4000 Установка ID польз-ля при выполнении программы (setuid)
2000 Установка ID группы при выполнении программы (setgid)
1000 Бит флажка ограничения прав на удаление (sticky bit)
Назначение прав доступа к файлам и каталогам при создании файла. Маска доступа.
Установка маски прав доступа: umask [маска], где маска – трехзначное восьмеричное
число (или символьное значение).
Цифры соответствуют правам для владельца файла, для группы, и для всех остальных.
Маска определяет непредоставляемые права, поэтому система вычитает каждую из этих
цифр из 7. Получившиеся 3 восьмеричных числа определяют права доступа к файлу (это
те самые числа, которые исп-ся при работе с утилитой chmod).
Большинство утилит и приложений не предпринимают попыток создания файлов с
правами на их выполнение независимо от того значения, которое указано в маске; они
заранее предполагают, что исполняемый файл создавать не нужно. В результате этого,
когда утилита или приложение, напр, утилита touch, создает файл, система вычитает
каждую цифру в маске из числа 6.
Исключение составляет утилита mkdir, которая предполагает, что вам нужен
установленный бит выполнения (доступ в случае работы с каталогом).
Пример: umask 022 (маска, имеющая значение 022, после вычитания из 777 дает права
доступа (rw–r––r––) для файла и 755 (rwxr–xr–x) для каталога)
11.Упр-е доступом к файлам в linux. Списки прав доступа ACL: формат, хранение,
создание, удаление, права по умолчанию для каталогов.
Списки упр-я доступом ACL – механизм расширения прав.
Права доступа в ACL могут даваться как именованным польз-лям и группам, так и по
UID и GID в дополнение к стандартным категориям, т.е. к польз-лю-создателю, его группе
и другим польз-лям. Применяются списки прав к файлам и директориям. Новые файлы и
поддиректории могут автоматически наследовать свои списки ACL от списка директорииродителя - default ACL, если он есть.
Просмотр некоторых(не всех!) деталей списков ACL:
$ ls -l myfile.txt
-rwxrw----+ 1 student mygroup 130 Mar 19 20:36 myfile.txt
Знак + здесь в конце строки битов указывает на то, что есть список ACL для этого файла.
Тройки битов здесь интерпретируются так:
User – настройки user ACL, которые совпадают со стандартными правами
Group – текущие ACL mask настройки; это не group из стандартных прав!
Other – other ACL настройки, так же как и в стандартных правах
Просмотр и структура ACL файла и директорий:
$ getfacl myfile.txt
# file: myfile.txt
//инф-ция о файле
# owner: student
//о владельце,
# group: mygroup//о группе владельца
//на 4-ой строчке – setuid, setgid, если они есть(#flags)
//настр. user
user::rwx
//права для student – rwx
user::james:--// права для james
user::1005::rwx
#effective:rw- //для uid=1005 права rwx, но маска ограничивает их
только до rw-(a.k.a. effective permissions )
//настройки group - аналогично
group::rwx
#effective:rwgroup:sodor:r-//настройки mask
mask::rw//настройки other
other::--Кроме того, также в ACL директорий имеются настройки по умолчанию:
default:user::rwx
default:group:sodor:r-x
default:mask::rwx
default:other::--Mask – задает максимально возможные права доступа для именован. user, group-owner и
именован. group. Но она не задает ограничения для владельца и other!
Установка, удаление, модификация ACL:
setfacl <опции> <ключ> <список правил> <объект>
Ключи: -m
модификация указанных правил
-x
удаление указанных правил
--set
полная перезапись правил
Опции: -b
удаляет все права, сохраняя основные правила
-k
удаляет права default
-d
устанавливает права default
-restore=file
восстанавливает права на объекты из указанного файла
-R
применить рекурсивно
Формирование списка правил:
u:<uid>:<perms>*
права для user
g:<gid>:<perms>*
права для group
m:<perms>*
задает маску для effective permissions
o:<perms>*
права для other
Примеры:
Назначить пользов-лю alex права на чтение и запись: $ setfacl -m u:alex:rw myfile.txt
Назначить группе право на чтение: $ setfacl -m g:teachers:r myfile.txt
12. Упр-е польз-лями в ОС Linux. Хар-и бюджета польз-ля. Формат файла /etc/passwd.
3 типа польз-лей в ОС Linux: Польз-ль root; Системные польз-ли; Обычные польз-ли.
Инф-ция о польз-лях хранится в файлах: Доп. инф-ция располагается в файлах:
по умолчанию для
/etc/passwd польз-ли
/etc/default/useradd св-в
новых польз-лей
настройки новых польз/etc/group
группы польз-лей
/etc/login.defs
лей
зашифрованные
пароли
каталог, файлы из
/etc/shadow польз-лей
которого копируются в
/etc/skel/
домашний каталог
зашифрованные
пароли
/etc/gshadow групп
нового польз-ля
 Файл /etc/passwd имеет след. текстовый формат: login:X:UID:GID:name:home:shell.
 В случае, если пароль хранится в зашифрованном виде в файле /etc/shadow, то вместо
пароля указывается символ x (икс).
 Файл /etc/group имеет след. текст. формат: group_name:password:GID:user1,user2,user3
 К файлам /etc/passwd и /etc/group д.б. заданы права доступа: чтение и запись для
польз-ля root и только чтение - для всех остальных
Для упр-я польз-лями служат команды:
Для упр-я группами служат команды:
useradd добавить нового польз-ля
groupadd создать новую группу
passwd установить пароль польз-ля
gpasswd установить пароль группы
параметры уч.
usermod изменить
groupmod изменить параметры группы
записи польз-ля
userdel удалить уч. запись польз-ля
groupdel удалить группу
Характ-ки бюджета польз-ля. Команда useradd заводит бюджет нового польз-ля,
создает для него домашний каталог, копирует в него файлы конфигурации из каталога
/etc/skel. В качестве аргумента команде д.б. указано имя польз-ля, которое потом будет
использоваться им для входа в систему. Кроме того, с помощью доп. опций можно задать:
 данные о польз-ле, записываемые в поле комментария в файле /etc/passwd (опция -c);
 имя или номер группы, к которой будет отнесен польз-ль (опция – g);
 список групп, в которые будет включен данный польз-ль (опция – G);
 UID польз-ля, назначаемый вместо UID, задаваемого системой (опция –u);
 какая оболочка назначается польз-лю (опция –s)
Команда usermod имеет те же опции, что и useradd, только исп-ся для изменения
параметров существующего польз-ля, причем на момент применения этой команды
суперпольз-лем данный польз-ль не д.б. логирован в системе.
Формат файла /etc/passwd
login:X:UID:GID:name:home:shell
В некоторых системах имеются «теневые пароли» (shadow passwords), когда инф-ция о
пароле хранится в файле /etc/shadow. Третье поле UID. Это число д.б. уникальным. UID ≤
1000 – системные польз-ли. Четвёртое поле GID, т.е. польз-ль принадлежит к группе с
данным номером. Инф-ция о группах хранится в файле /etc/group. Пятое поле – реальное
имя польз-ля, в данном случае. Последние 2 поля – домашний каталог польз-ля и
начальная оболочка.
13. Идт-я, аут. и авт. польз-ля. Вход польз. в сист. Вып-е команд от им. др. польз
Идентификация – процедура распознавания польз-ля по его идентификатору. Каждый
польз-ль имеет 2 идентификатора: UID и GID, которые предназначены для опр-я его прав
доступа к файлам в системе. Они представляют собой неотрицат. целые числа. UID – user
id – идентификатор польз-ля. GID – group id – идентификатор первичной группы польз-ля.
Каждый польз-ль м. б. одновременно в нескольких группах, но только одна из них
устанавливается на вновь создаваемые польз-лем файлы и каталоги – первичная группа.
Получить GID, UID можно с помощью команды id: $ id
Авторизация – процедура предоставления польз-лю определенных прав, а также
подтверждения и проверки этих прав. Методы авторизации: Дискреционное упр-е
доступом; Мандатное упр. доступом; Упр. доступом на основе ролей.
Аутентификация польз-ля - процедура проверки подлинности польз-ля. Наиболее
распространена схема аут-ции, основанная на паролях: после загрузки системы
предлагается ввести имя польз-ля и пароль. Напр, раньше аут-ция обеспечивалась
утилитой login, задача которой – проверить, действительно ли есть такой польз-ль и такой
ли у него пароль, просматривая БД польз-лей – /etc/passw. Если введенные данные верны,
то утилита впускала польз-ля в систему. Сейчас исп-ся такие системы аут-ции, как PAM.
Вып-е команд от имени другого польз-ля. Для этого сущ-ет команда sudo. Если имя или
идентифиактор пользов-ля не указаны, то выполняться будет от root’а. Польз-ль, от имени
которого надо запустить программу, д.б. зарегистрирован в файле sudoers! Требуется
ввести пароль по умолчанию (в конфигурации по умолчанию это пользовательский
пароль), если вызываемый польз-ль не root и не текущий!
Для этой команды сущ-ет мн-во параметров: -u, --user=user - выполнить команду от
имени указанного польз-ля; -E – сохранить пользовательское окружение при выполнении
команды; -e, --edit – редактировать файлы вместо выполнения команды; -g, --group=group
– выполнить команду от имени или ID группы; -i, --login – запустить оболочку входа в
систему от имени указанного польз-ля, также можно задать команду
Примеры:
Редактировать файл от имени user1: $ sudo -u user1 vi ~www/htdocs/index.html
Получить список файлов в домашнем каталоге польз-ля user2: $ sudo -u user2 ls ~
Также выполнять команды от имени др. польз-ля можно через команду su. Она
позволяет начать сеанс от имени др. польз-ля и выполнить несколько команд от имени
нужного польз-ля в отличие от sudo.
Пример: $ su user2 //начало сеанса от имени user2
//какие- то действия
$ exit // завершение сеанса
14.Упр-е польз-лями в ОС Linux. Создание, модиф-ция, удаление бюджета польз-ля
useradd [опции] {имя польз-ля} – создание нового польз-ля
После выполнения данной команды, новый польз-ль будет создан в заблокированном
состоянии. Чтобы разблокировать пользовательский аккаунт, необходимо задать его
пароль с помощью команды "passwd". Сразу после установки стандартные значения для
различных параметров указаны в файле /etc/default/useradd.
Основные опции команды useradd: -b - базовый каталог для размещения домашнего
каталога польз-ля, по умолчанию /home; -c - комментарий к учетной записи; -e - дата, когда
уч. запись польз-ля будет заблокирована, в формате ГГГГ-ММ-ДД; -f - заблокировать уч.
запись сразу после создания; -g - основная группа польз-ля; -G - список доп. групп; -k каталог с шаблонами конфигурационных файлов; -m - создавать домашний каталог пользля, если он не сущ-ет; -M - не создавать домашнюю папку; -N - не создавать группу с именем
польз-ля; -p - задать пароль польз-ля; -s - командная оболочка для польз-ля; u идентификатор для польз-ля
usermod [опции] {имя польз-ля} – изменение учетной записи. Изменять можно любые
атрибуты, но имя польз-ля и код UID изменять нужно лишь в случае крайней
необходимости, т.к. такое изм-е может иметь общесистемные последствия.
userdel [опции] {имя польз-ля} – удаление польз-ля. Команда userdel не м.б. выполнена
при нахождении в системе удаляемого польз-ля и запущенных им процессов. Команда
userdel удаляет пользовательские данные из всех системных файлов (/etc/passwd,
/etc/shadow, /etc/group) не трогая личные файлы.
Опции команды userdel:
 -f – удаление уч. записи, даже если польз-ль в этот момент работает в системе. Она
также заставляет userdel удалить домашний каталог польз-ля и почтовый ящик, даже
если др. польз-ль исп-ет тот же домашний каталог или если почтовый ящик не
принадлежит данному польз-лю;
 -h - показать краткую справку и закончить работу;
 -r - файлы в домашнем каталоге польз-ля будут удалены вместе с самим домашним
каталогом и почтовым ящиком. Пользовательские файлы, расположенные в других
файловых системах, нужно искать и удалять вручную.
15.Упр-е польз. в ОС Linux. Гр. польз. Перв. гр., PUG. Формат файла /etc/group.
Как и у польз-лей у групп есть имя и номер (GID). Инф-ция о группах хранится в файле
/etc/group. Для упр-я группами служат команды: groupadd – создать новую группу;
gpasswd – установить пароль группы; groupmod – изменить параметры группы; groupdel
– удалить группу
Первичная группа: У каждого польз-ля есть только одна первичная группа (primary
group). Она определяется по GID, который указан в файле /etc/passwd. Обычно,
первичная группа владеет новыми файлами, созданными польз-лем.
Концепция PUG: У Red Hat первичной группой только что созданного польз-ля явл-ся
только что созданная группа, того же имени, что и польз-ль. Данный польз-ль явл-ся
единственным членом этой группы. Такая группа и концепция наз-ся Private User Group.
Доп. группы: Польз-ль может состоять в 0 или более доп. группах (supplementary
group). Доп. польз-ли указаны в последнем поле строки группы в файле /etc/group.
Формат файла /etc/group: groupname:password:GID:user1,user2,user3
16.Упр-е польз-лями в ОС Linux. Создание, модиф-ция, удал-е группы польз-лей.
Упр-е польз-лями в ОС Linux. Каждый процесс в системе работает под опр. польз-лем.
Каждый файл принадлежит конкретн. польз-лю. Команда id исп-ся для отображения инфции о текущем вошедшем в систему польз-ле. Осн. инф-цию о др. польз-ле можно
получить передавая имя польз-ля в качестве первого аргум-та идентификатору команды.
Чтобы просмотреть польз-ля, связанного с файлом/каталогом, используйте команду ls -1.
Чтобы просмотреть инф-цию о процессе, используйте команду ps. Вывод предыдущих
команд отображает польз-лей по имени, но ОС отслеживает польз-лей по номеру UID.
Отображ-е имен в числа опр-ся в БД уч. записи. Системы исп-ют файл /etc/passwd, чтобы
хранить инф-цию о локальных польз-лях. Username – сопоставление UID с именем пользля. Password – где, исторически, пароли хранились в зашифров. виде. Сегодня они
хранятся в отдельном файле под названием /etc/shadow. UID – идентификатор польз-ля,
номер. GID – идентификац. номер первичной группы польз-ля. /Home/dir – местоположение
персон. данных и файлов конфигурации польз-ля. Создание, модификация, удаление
группы польз-лей. Группа должна существовать, прежде чем польз-ль м.б. добавлен в эту
группу. Создание группы польз-лей: Программой groupadd создаются группы:
 groupadd имя_группы использует следующий доступный GID из диапазона,
указанного в /etc/ login.defs файл.
 Опция -g GID исп-ся для указания конкретного GID.
$ sudo groupadd -g 5000 ateam
 Опция -r позволяет создать системную группу с помощью гид из диапазона
допустимых системе гид, указанным в /etc/login.defs файл.
$ sudo groupadd -r appusers
Удаление группы польз-лей: Команда groupdel удаляет группу $ sudo groupdel javaapp.
Группа не м.б. удалена, если она явл-ся осн. группой любого существующего польз-ля.
Проверьте все файл. системы, чтобы гарантировать, что никакие файлы не принадлежат группе.
Модификация группы польз-лей: Groupmod изменяет существующие группы:
 Команда groupmod исп-ся для изменения имени группы на сопоставление GID.
Опция -n исп-ся для указания нового имени. $ sudo groupmod -n javaapp appusers
 Опция -g исп-ся для указания нового GID: $ sudo groupmod -g 6000 ateam
 Состав группы контролируется с руководством польз-ля. Изменение основной группы
польз-ля: usermod -g имя_группы.
 Добавить польз-ля в доп. группу: usermod -aG имя_группы имя_польз-ля.
Пример: $ sudo usermod -aG wheel elvis
Исп-е опции -a переводит функцию usermod в режим «добавления». Без него польз-ль
будет удален из всех других дополнительных групп.
17. Упр-е польз-ми в ОС Linux. Хар-ки пароля польз-ля. Формат файла /etc/shadow
Одни системы настаивают на фиксированной минимальной длине пароля, другие – на
содержании в пароле хотя бы одного небуквенного символа.
Формат файла /etc/shadow. Пароли (или их зашифрованное представление) хранятся в
файле /etc/shadow, доступ к которому имеет только суперпольз-ль. Формат файла:
name:password:lastchange:minage:maxage:warning:inactive :expire:blank
name – имя пользов-ля для входа в систему password – зашифрованный пароль (хэш)
Если это поле пустое, то пароль отсутствует. Если ! или *, то учётная запись заблокирована
(вход никогда не осуществится)
 lastchange – дата последнего изм-я пароля (кол-во дней с 01.01.1970)
 minage – минимальное кол-во дней между изменениями пароля
 maxage – максимальное кол-во дней, когда пароль действителен
 warning – период предупреждения о том, что срок действия пароля истекает (в днях). 0
означает, что не надо предупреждать
 inactive – кол-во дн, когда уч. запись будет активна после истечения действия пароля
 expire – истекает абс. дата, после которой уч. запись будет отключена
 blank – пустое поле (резерв для будущего исп-я)
Хэш пароля. Современный хэш паролей файла /etc/shadow состоит из 3х частей ($ - знак
разделения): $1$gCjLa2/Z$6Pu0EK0AzfCjxjv2hoLOB/
1. 1 – алгоритм хэширования. Число 1 значит, что использовался MD5. Или, например,
число 6 означает, что использовался SHA-512.
2. gCjLa2/Z – соль, используемая для создания хэша (соль и незашифрованный пароль
объединяются и хэшируются).
3. 6Pu0EK0AzfCjxjv2hoLOB/ – итоговый хэш пароля.
Когда польз-ль пытается войти в систему, система просматривает запись для польз-ля в
/etc/shadow, объединяет соль для польз-ля с незашифрованным паролем, который был
введен, и шифрует их с исп-ем указанного алгоритма хэширования. Если результат соответ зашифрованному хэшу, польз-ль вводит правильный пароль. Если результат не соответ зашифрованному хэшу, польз-ль вводит неверный пароль и попытка входа в систему не
выполн-ся. Этот метод позволяет системе определить, набрал ли польз-ль правильный
пароль, не сохраняя этот пароль в форме, пригодной для входа в систему.
18. Упр-е польз-лями в ОС Linux.
Подгружаемые аутентификационные модули (Pluggable Authentication Modules) - набор
API для аутентификации польз-лей.
Файл /etc/pam.conf состоит из строк след. формата:
Имя_службы Тип_модуля Управляющий_флаг Модуль_PAM Аргументы
Имя службы (сервиса) – программа, к которой относится данная строчка. Т.е. при вызове
этой программы открывается файл /etc/pam.conf и выполняются все строчки, связанные с
этой программой. Все строчки, связанные с этой программой, образуют стек модулей,
который выполняется послед-но. Результат работы зависит от порядка команд (модулей).
Программы, использующие PAM (службы): login, su, sudo, passwd, screen и т.д.
Тип модуля (тип действия) – один из четырех вариантов (управляющие группы):
1. auth - подтверждение личности польз-ля. Обычно это имя польз-ля и пароль.
2. account - действия, определяющие, можно ли польз-лю зайти в систему. Напр,
ограничение входа польз-ля в систему в зав-ти от времени суток.
3. session - действия по выделению ресурсов, кот. могут потребоваться польз-лю во время
сессии, напр, установка лимитов на исп-е ресурсов системы, вывод ежедн. сообщ-я и т.д.
4. password - действия по обновлению «секрета» польз-ля (обычно пароля).
Управляющий флаг – как система реагирует на результат модуля. Варианты:
 requisite - если модуль завершается с ошибкой, PAM немедленно возвращает
приложению ошибку, другие модули стека не вызываются.
 required - если модуль завершается с ошибкой, PAM возвращает ошибку приложению,
но продолжает вызывать остальные модули стека.
 sufficient - если модуль завершается успешно, PAM возвращает приложению результат
«выполнен», и остальные модули стека не вызываются.
 optional - результат работы модуля (выполнен/ошибка) игнорируется.
 include - включает все строки из конфигурационного файла, переданного в качестве
аргумента (фактически вызов функции).
Основные модули PAM (далее расписано Модуль (действие): описание)
 pam_unix (auth, session, password): Выполняет аутентификацию, используя хэши паролей,
которые хранятся в /etc/shadow.
 pam_limits (session): Устанавливает огр-я на системные ресурсы, отпускаемые на время
пользовательского сеанса. Можно задать жесткие и мягкие границы для таких параметров,
как макс. число процессов, макс. размер файла, процессорное время и т.д.
 pam_rootok (auth): Завершается успешно, если вы – администратор системы, и возвращает
ошибку в противном случае
 pam_cracklib (password): Проверяет качество пароля, затем еще раз проверяет пароль по
системному словарю и ряду правил «плохого подбора пароля»
 pam_passwdqc (password): Альтернат. модуль для проверки качества пароля
 pam_permit (auth, account, session, password): Всегда говорит «да» и возвращает успешный
результат выполнения
 pam_deny (auth, account, session, password): Всегда говорит «нет» и возвращает ошибку
 pam_warn (auth, account, session, password): Просто отправляет сообщение (включая имя
сервиса, терминал, имя польз-ля и удаленный хост) службе журнала syslogd.
 pam_wheel (auth, account): Исп-ся программами типа su. Этот модуль разрешает
администраторский доступ только польз-лям, включенным в группу wheel.
Вообще-то /etc/pam.conf устарел и вместо него используют папку /etc/pam.d/, в кот. хранятся
файлы с именами служб (login, su, passwd и т. д.). Сами же модули PAM хранятся в папке
/lib64/security/ и наз-ся pam_rootok.so, pam_wheel.so и по аналогии.
19. Упр-е дисковыми разделами, ФС и простр-вом свопинга.
Файловая система (ФС) – организованная структура файлов и директорий,
располагающихся на накопителе, т.е. способ хранения данных. Виды ФС: дисковые;
сетевые; виртуальные. Виртуальная ФС обеспечивает единый интерфейс системных
вызовов (API) для различных типов ФС. Раздел – часть долговременной памяти жёсткого
диска или флеш-накопителя, выделенная для удобства работы, и состоящая из смежных
блоков. На одном устройстве хранения м.б. несколько разделов. Виды разделов
винчестера: основные, расширенные и логические. Непосредственно винчестер делится
на основные разделы, один из основных разделов м.б. назначен расширенным и разделён
на логические. При этом основных разделов м.б. максимум 4 (с учётом расширенного),
расширенный, если есть, то всегда один, а логических м.б. сколько угодно. Т.е. вы можете
разрезать винчестер максимум на 4 части, но одну из них вы можете спокойно поделить
на сколько угодно кусков. В Linux винчестеры наз-ся sda, sdb, sdc и т.д. (sda - первый
винчестер, sdb - второй и т.д.). Разделы на винчестерах называются так: sda1, sda2, sda3 и
т.д. Первые 4 цифры зарезервированы для осн. разделов, внутри расширенного раздела
нумерация логических начинается всегда с пяти.
Основные разделы Linux:

/ - Это корневой раздел (обязателен). Самый главный, к нему монтируются все
последующие разделы и в нем хранятся самые важные файлы ОС.

swap - Раздел подкачки.

/boot - Содержит ядро OC и файлы для загрузки.

/usr - Все важные программы и библиотеки польз-ля.

/tmp - Раздел содержит временные файлы.

/var - Хранит log, ceсh-файлы, а также почту, иногда web.

/opt - Туда устанавливаются дополнительные - сторонние программы.

/home - Сюда помещаются все домашние каталоги польз-лей.
Еще есть такие разделы, как /etc, /bin, /llib, /mnt и другие.
Не обязательно делить диск так подробно. Обязателен лишь корневой раздел.
Для работы с разделами можно использовать утилиту fdisk (от имени root). Вывод на экран
всех разделов: fdisk –l. Чтобы просмотреть разделы на опр. устройстве, необходимо
добавить имя устройства. Напр, fdisk -l /dev/sda
У каждого раздела есть: Вид (основной, расширенный, логический); Начало, конец,
размер; Поле Id, определяющее предполагаемое назначение раздела (Тип 82 означает
раздел подкачки Linux, а тип 83 – раздел для хранения данных. Сущ-ет приблизительно
100 различных типов); Файловая система; Точка монтирования.
Еще раздел м.б. помечен как загрузочный (активный), что позволяет загружать компьютер
с указанного раздела при помощи стандартной MBR-записи DOS.
20. Упр-е дисковыми разделами, ФС и пространством свопинга. Дисковые ФС.
Типы ФС. Формат ФС UNIX. Создание ФС. Монтир-еФС.
Файловая система (ФС) – организованная структура файлов и директорий,
располагающихся на накопителе, т.е. поддерево директорий на некоторой машине,
расположенных в одном разделе.
Cоздание ФС type на устройстве /dev/block_device
mkfs -t type /dev/block_device
Орг-ция ФС UNIX имеет древовидную структуру, вершина которой наз-ся корнем, а
сама структура называется файловым деревом. Каждая вершина в файловом дереве, за
исключением листьев, является каталогом, листья же в свою очередь являются либо
обычными файлами, либо файлами устройств
Типы ФС
 ext2 (second extended filesystem – вторая расширенная ФС). Она не является
журналируемой, т.е. не ведёт постоянный учёт всех операций записи на диск)
 ext3. Дополняет ext2 возм-тями журналирования. Она обладает достаточной
производительностью в большинстве ситуаций. Это сформировавшаяся и стабильная
ФС, и исп-ся по умолчанию в ряде дистрибутивов Linux.
 ReiserFS – ФС на основе B-дерева, обладающая очень хорошей общей
производительностью, в особенности при исп-и большого числа маленьких файлов.
Она хорошо масштабируется и является журналируемой. Она не поддерживает возмти SELinux.
 XFS – журналируемая ФС, обладающая надежной функциональностью и
оптимизированная для масштабирования. XFS активно кэширует в ОЗУ
передаваемые данные
 ФС раздела подкачки. Дисковое пространство, выделенное под раздел подкачки, д.б.
соответствующим образом отформатировано, но, как правило, раздел подкачки не
рассматривается в качестве файловой системы.
 vfat (иначе FAT32). Она не является журналируемой и не обладает многими возмтями, необходимыми для полноценной работы с ФС в Linux. Она м.б. доступна из
Windows и из Linux, что делает ее подходящей для обмена данными между этими ОС.
Дисковые ФС обычно являются поток-ориентированными. Файлы в таких ФС
представляются послед-тью битов, часто предоставляющие такие функции, как чтение,
запись, изменение данных и произвольный доступ.
Каждая ФС д.б. смонтирована, прежде чем к ней будет обеспечен доступ. ФС монтируется
в некоторую точку монтирования (mount point). Монтирование ФС – ее подсоединение
к узлу уже существующих, активных и используемых ФС (точке монтирования).
Монтирование файлового устройства device в каталог dir: mount device dir
Параметры: -a - монтирование всех ФС, указанных в /etc/fstab -t fstype - указание типа
файловой системы (ntfs, nfs, ext3 и т.п.) -ro - монтирование в режиме только чтения
Размонтирование ФС: umount dir/mount_point
21. Упр-е дисковыми разделами, ФС и простр-вом свопинга. Создание и форматире раздела свопинга. Подключение и отключение раздела свопинга.
Свопинг (процесс подкачки) – процесс, при котором система перемещает отдельные
блоки опер. памяти в заранее заготовленное место на жестком диске (swap-пространство)
в случае, когда опер. памяти не хватает для работы приложений.
Виды пространства в Linux swap:
 раздел подкачки (swap partition) – независимая секция жесткого диска, используемая
исключительно для подкачки, никаких других файлов там нет.
 файл подкачки (swap file) – файл особого типа внутри файловой системы, среди пр.
файлов всех др. типов.
Перед началом настройки нового раздела подкачки стоит проверить систему на наличие
др.х подключённых разделов подкачки. Это можно сделать с помощью команд:
1. Опр-е имеющегося в системе swap-пространства (если строка вывода пуста, то в
системе swap еще не настроен):
2. sudo swapon –s
3. Опр-е состояния памяти и swap (в мегабайтах): free –m
4. Опр-е доступного пространства на жестком диске: df -h
Размер swap-пространства зависит от потребностей. Как правило, размер swap д.б. равен
или вдвое больше объема оперативной памяти системы.
Настройка раздела подкачки Допустим, есть раздел /dev/sda2.
1. Форматирование раздела swap: sudo mkswap /dev/sda2
2. Подключение раздела swap: sudo swapon /dev/sda2
3. Проверка результата (если команды выполнены верно, то в списке подключенных
разделов отобразится нужный)
sudo swapon –s
4. Автоматическая активация после перезагрузки:
echo ‘/dev/sda2 none swap sw 0 0’ | sudo tee –a /etc/fstab
5. Отключение раздела swap: sudo swapoff /dev/sda2
22.Упр-е ПО, входящим в состав ОС. Без-ть при установке, обновлении и удалении ПО.
Основные возм-ти системы упр-я пакетами RPM.
Задачи по упр-ю ПО: Проверка целостности; Проверка достоверности; Установка; Обновление
версии; Удаление. ПО в Linux распростр-ся в виде пакетов – архивов файлов, содержащие все
компоненты приложений и инструкции по их запуску и настройке. Пакеты хранятся в
репозиториях, локальных или сетевых хранилищах. После установки пакета его метаданные
сохраняются в локальной БД и исп-ся для поиска файлов пакета. Задача упр-я ПО сводится к
задаче упр-я пакетами. Все операции, связанные с изм-ем состава системы производятся над
пакетами. Этим достигается упрощение работы администрирования системы, автоматизация
выполнения задач по упр-ю ПО. Типы пакетов: Бинарные (скомпилированные исполняемые и
прочие файлы программы); Исходные (исходные коды, инструкции по сборке). Метаданные
пакета: Название (имя программы, закрепленной за пакетом); Версия; Авторы, описание;
Зависимости (список пакетов с версиями, необходимых для установки и работы); Содержимое
(бинарный (скомпилированный) или исходный файл); Установочные скрипты. С точки зрения
без-ти при упр-и ПО явл-ся важным описание взаимосвязей приложений. Т.к. приложения
требуют для своего выполнения опр. рабочего окружения, пакеты могут предоставлять файлы,
предназначенные для исп-я в др. пакетах. Зависимости пакетов исп-ся для выражения таких
связей. Пакетные зависимости транзитивны. Типичны библиотечные зависимости: практически
каждое отдельное приложение требует нескольких библиотек (обычно названия пакетов,
содержащих библиотеки, начинаются с "lib"). Система упр-я пакетами (менеджер пакетов) –
набор ПО, позволяющего управлять процессом установки, удаления, настройки и обновления
разл. компонентов ПО. RPM (RPM package manager) – менеджер пакетов формата «.rpm»,
разработанный изначально фирмой Red Hat, применяется в Fedora, RHEL, openSUSE и пр.
дистрибутивах. БД RPM ведётся в каталоге /var/lib/rpm. Она состоит из одиночной БД, в которой
хранится вся инф-ция о пакетах, и мн-ва маленьких, которые служат для индексации и содержат
в себе сведения о том, какие файлы менялись и создавались при установке и удалении пакетов.
RPM – без автоматического разрешения зависимостей (при отсутствии нужного пакета он
только сообщит об ошибке). С автоматическим разрешением – YUM. Основные команды RPM
(требуются права root): утилита rpm
Основные ключи:
Что делает
# rpm -i имя_пакета
Установка пакета
-i
--install Установка
-U --upgrade Обновл-е/установка
# rpm -U имя_пакета Обновление версии
-e
--erase Удаление
# rpm -e имя_пакета Удаление пакета
-q
--query Запрос
Список всех установленных
#
rpm
–qa
пакетов
-V --verify Верификация
Поиск пакета, содержащего
# rpm -qf имя_файла файл
# rpm -qi имя_пакета Инф-ция о пакете
# rpm -ql имя_пакета Список файлов в пакете
# rpm -qR имя_пакета Зависимости пакета
23.Упр-е ПО ОС. Пакет RPM. Зависимости пакетов. Состав пакета (файлы, метаданные,
скрипты). Бинарные и src-пакеты. Назначение spec-файла.
RPM обозначает две сущности: формат пакетов ПО и программа, созданная для упр-я этими
пакетами. Исп-ся для установки, удаления и обновления ПО. Пакеты: Бинарные .rpm содержат
полный набор приложений и библиотек, собранных под определенную процессорную
архитектуру; Исходники .src.rpm содержит все необх. средства, нужные для сборки бин. пакета.
Структура пакета: Метаданные (название, описание, версия, зависимости); Файлы (архив типа
cpio). Spec-файл требуется для построения пакета. Это обычный текстовый файл, который имеет
суффикс .spec и содержит в себе название пакета, версию, номер релиза, инструкции по сборке
и установке пакета и список изменений. Именование пакета: name-version-release.arch.rpm
Зависимости возникают в тех случаях, когда работоспособность ПО из одного пакета зависит
от ПО, входящего в состав др. пакета. Типы зависимостей RPM:
 Requirements: случаи, когда пакету требуются возм-ти, предоставляемые др. пакетом
 Provides: списки пакетов, которые требуют возм-тей данного, а он их предоставляет
 Conflicts: случаи, когда пакет конфликтует с возм-тями, предоставляемыми др. пакетом
 Obsoletes: случаи, когда возм-ти данного пакета делают устаревшими возм-ти др. пакета;
обычно бывают, если при смене версии пакет меняет имя.
Режимы работы в RPM:
RPM для системного администрирования:
 Install: rpm -i install-options package_file
 Upgrade: rpm -U upgrade-options
package_file
 Erase: rpm -e erase-options package_file
 Query: определить, установлен ли уже
пакет и где он находится: rpm -q queryoptions
 Verify: сравнить установленный пакет с
оригинальным (размер, контрольная
сумма, разрешения, тип, владелец и
группа): rpm -V verify verify-options
RPM для распространения ПО:
 Build: создать пакет: rpmbuild
 Rebuild Database: изменить пакетную
инф-цию: rpm –rebuilddb
 Fix Permissions: изменить исходные
разрешения: rpm --setperms
{packagename})
 Signature Check: проверить целостность:
rpm -K package.rpm
 Set owners and Groups: изменить
исходные польз-ля и группу: rpm -setugids {packagename}
 Show RC: rmp --showrc
24.Упр-е ПО ОС. Верификация установл. пакета. Восстановление прав доступа файлов по
БД пакетов. Восстановление владельца и группы файлов по БД пакетов.
БД RPM хранит инф-цию обо всех пакетах, установленных в системе. Эта БД может исп-ся для
запросов, касающихся того, что установлено, для информирования о версиях установленного
ПО, для оценки целостности пакетов и системы. БД пакетов обычно хранится в директории
/var/lib/rpm. Верификация установл. пакета. Кроме запросов к установл. пакетам RPM
позволяет оценить целостность системы и каждого пакета в отдельности с помощью режима
верификации. Режим включается опцией -V.
Базовый синтаксис: rpm -V verify_options package_name
Если все в порядке, не выводится никаких сообщений, так как режим rpm -V выводит только
сообщения об ошибках. Верификация (ключ -V) включает: Проверку зависимости пакета от
возм-тей, предоставляемых другими пакетами (отключается ключом --nodeps); Выполнение
верификационных скриптов, предоставляемых разработчиком пакета (отключается ключом -noscripts); Проверку наличия всех файлов и их корректное состояние (отключается ключом -nofiles). В зависимости от типа файла проверяется: Директория (права доступа, владелец,
группа); Символьная ссылка (строка ссылки, права доступа (всегда 777), владелец (всегда root),
группа (всегда root)); FIFO (права доступа, владелец, группа); Устройство (права доступа,
владелец, группа, major, minor); Обычный файл (размер, права доступа, владелец, группа, MD5,
время модификации).
При несовпадении атрибутов файла с записью в БД выдается строка: SM5DLUGT c имя_файла
Для совпадающего атрибута вместо буквы выводится точка. Если невозможно произвести
проверку, то выводится ?. Кодовые символы говорят о характере несовпадения атрибутов файла:
 S - Изменился размер файла
 G - Изменилась группа файла
 M - Изменились атрибуты доступа файла  T - Время создания или время последней
 5 - Изменилась контрольная сумма MD5
модификации файла изменились
файла
 с - выводится, если файл относится к
 D - Старший и младший номер файла
конфигурационным
устройства изменились
 d - выводится, если файл относится к
 L - Ошибка ссылки
файлам документации
 U - Изменился владелец файла
Восст-е прав доступа файлов по БД пакетов: rpm --setperms ключи_выбора_пакета
Восст-е владельца и группы файлов по БД пакетов:
rpm --setugids ключи_выбора_пакета
Ключи: -vv, --root путь, --dbpath путь работают как обычно.
Ключи выбора пакета:
 метка_пакета (можно указать только имя)  -g класификационная_группа_и_подгруппа
 -a (все установленные пакеты)
 --whatprovides capability (пакеты,
обеспечивающие указанную возм-ть)
 -f полное_имя_файла (пакет, которому
 --whatrequires capability (пакеты, требующие
принадлежит указанный файл; в пути не
указанную возм-ть)
д.б. символьных ссылок)
 --triggeredby метка_пакета (пакеты,
 -p rpm-файл (вместо имени м.б. URL; БД
содержащие триггер-скрипты,
пакетов не исп-ся)
активизируемые указанным пакетом)
25. Упр-е ПО ОС. Обесп-е без-ти при уст-е и обнов-ии ПО ОС. Подпись пакетов RPM.
RPM предоставляет широкий спектр функций проверки без-ти при установке и
обновлении ПО: анализ пакетов; проверка файлов в пакетах; установка подписи, проверка
подписи пакетов. GPG-подпись – стандартный механизм подписи пакетов в RPM. Для ее
генерации необходимо: Генерация пары GPG-ключей; Конфигурирование RPM для испя ключа; Подпись пакетов; Экспорт публичного ключа.
Генерация пары ключей. Команда генерации ключа: gpg --gen-key.
После запуска генерации ключей появляется сообщение, в котором нужно выбрать: (1)
DSA and ElGamal (default) (2) DSA (sign only) (4) RSA (sign only).
Примите значение (1) DSA and ElGamal, что позволит создать цифровую подпись. Введите
1 и нажмите Enter. Выберите длину ключа, срок действия ключа. Далее надо указать
идентификатор польз-ля, который должен содержать имя, электронный адрес и,
дополнительно, комментарий. Инф-ция будет запрошена постепенно, после чего можно
просмотреть введенные данные.
Конфигурирование RPM для исп-я ключа. В файл ~/.rpmmacros нужно добавить:
%_signature gpg
%_gpg_name key_id
key_id – идентификатор польз-ля, указанный в предыдущем пункте.
Подпись пакета. Команда подписи пакета: package-name-1.0-1.noarch.rpm Параметры:
 --addsign – начальная подпись. Исп-ся, если пакет не подписывался ранее.
 --resign – переподписать уже подписанный пакет.
Команда экспорта открытого ключа: gpg --export -a 'имя' > public_key.txt
В этом случае ключ будет сохранен в файле public_key.txt
Команда импорта открытого ключа: rpm -import public_key.txt
Команда проверки подписи пакета: rpm --checksig -v package-name-1.0-1.noarch.rpm
Вывод: Good signature from "имя", где имя – имя польз-ля, подписавшего пакет.
26. Упр-е сервисами
Сервисы следят за: Состоянием системы; Автоматическим подключением внешних
устройств; Взаимодействием с сетью; Обеспечением безотказной работы разл. служб
Сервисы бывают: системные и сетевые. systemd – системный менеджер, демон
инициализации др. демонов в Linux. Особенность: интенсивное распараллеливание
запуска служб в процессе загрузки системы, что позволило существенно ускорить запуск
ОС. Оперируют специально оформленными файлами конфигурации – юниты (units). Unit
отвечает за отдельно взятую службу; точку монтирования; подключаемые устройства;
файлы подкачки; виртуальные машины
Юниты представлены конфигурацион. файлами, размещенными в одной из директорий:
 /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
 /run/systemd/system/ – юниты, созданные в рантайме. Этот каталог приоритетнее
каталога с установленными юнитами из пакетов.
 /etc/systemd/system/ – юниты, созданные и управляемые системным администратором.
Этот каталог приоритетнее каталога юнитов, созданных в рантайме.
Типы юнитов:
 .target - позволяет группировать юниты,  .swap - отвечает за подключение файла
воплощая концепцию уровней запуска
или устройства подкачки
(runlevel)
 .timer - позволяет запускать юниты по
 .service - отвечает за запуск сервисов
расписанию
(служб), также поддерживает вызов
 .socket - предоставляет службам
интерпретаторов для исполнения
поддержку механизма сокет-активации
пользовательских скриптов
 .slice - отвечает за создание контейнера
 .mount - отвечает за монтирование
cgroups
файловых систем
 .device - позволяет реагировать на
 .automount - позволяет отложить
подключение устройств
монтирование файловых систем до
 .path - управляет иерархией файловой
фактического обращения к точке
системы
монтирования
Основные команды упр-я systemd
# systemctl start name.service – запуск
# systemctl stop name.service – остановка
сервиса
сервиса
# systemctl restart name.service –
# systemctl disable name.service –
перезапуск сервиса
деактивирует сервис
# systemctl try-restart name.service –
# systemctl reenable name.service –
перезапуск сервиса только, если он
деактивирует сервис и сразу активирует
запущен
его
# systemctl reload name.service –
# systemctl is–enabled name.service –
перезагрузка конфигурации сервиса
проверяет, активирован ли сервис
# systemctl status name.service – проверка, # systemctl list-unit-files --type service –
запущен ли сервис с детальным
отображает все сервисы и проверяет,
выводом состояния сервиса
какие из них активированы
# systemctl is-active name.service –
# systemctl mask name.service – заменяет
проверка, запущен ли сервис с простым
файл сервиса симлинком на /dev/null,
ответом: active или inactive
делая юнит недоступным для systemd
# systemctl list-units --type service --all –
# systemctl unmask name.service –
отображение статуса всех сервисов
возвращает файл сервиса, делая юнит
# systemctl enable name.service –
доступным для systemd
активирует сервис (позволяет
стартовать во время запуска системы)
Зависимости (targets). Файлы целей systemd.target предназначены для группировки
вместе др. юнитов systemd через цепочку зависимостей.
27. Упр-е системными и сетевыми сервисами. Упр-е service-юнитами. Разрешенные
и запрещённые сервисы. Запуск, останов и перезагрузка сервиса.
Сервисы – программы, кот. запускаются и останавливаются через инициализационные
скрипты, расположенные в каталоге /etc/init.d. Многие из этих сервисов запускаются на
этапе загрузки системы. Сервисные юниты имеют расширение .service и представляют
собой системные службы. Этот тип устройства исп-ся для запуска часто посещаемых
демонов, таких как веб-сервер. Юниты представлены конфигурационными файлами.
Описание сервис-юнита:
[Unit]
Description=Daemon to detect crashing apps After=syslog.target
[Service]
ExecStart=/usr/sbin/abrtd Type=forking
[Install]
WantedBy=multi-user.target
 [Unit]. Она содержит общую инф-цию о сервисе В примере дается описание сервиса
и указываем на то, что демон д.б. запущен после Syslog.
 [Service] непосредственно содержится инф-ция о сервисе. Используемый параметр
ExecStart указывает на исполняемый файл сервиса.
 В Type указывается, как сервис уведомляет systemd об окончании запуска.
 Финальная секция [Install] содержит инф-цию о цели, в которой сервис должен
стартовать. В данном случае говорится, что сервис д.б. запущен, когда будет
активирована цель multi–user.target.
Основные команды:
 systemctl start name.service – запуск сервиса.
 systemctlstopname.service – остановка сервиса
 systemctl restart name.service – перезапуск сервиса
 systemctl reload name.service – перезагрузка конфигурации сервиса
 systemctlstatusname.service – проверка, запущен ли сервис с детальным выводом
состояния сервиса
 systemctlis-activename.service – проверка, запущен ли сервис с простым ответом:
active или inactive
 systemctlenablename.service – активирует сервис (По умолчанию большинство
юнитов systemd не запускается автоматически. Чтобы настроить автозапуск юнита,
нужно его включить. Это соединит юнит с опр. целевым компонентом, и тогда юнит
будет запускаться вместе с ним.)
 systemctl disable name.service – деактивирует сервис
 systemctlreenablename.service – деактивирует сервис и сразу активирует его
 systemctlis –enabledname.service – проверяет, активирован ли сервис
Разрешенные сервисы – сервисы, которые будут запускаться при загрузке.
systemctllist-unit-files --typeservice – отображает все сервисы и проверяет, какие из них
активированы
28. Упр-е системными и сетевыми сервисами. Упр-е target-юнитами, target-юнит по
умолчанию.
.target – группа юнитов systemd
Юниты целей исп-ся для связывания и группировки других юнитов с целью описания
соответствующего состояния системы. Некоторые из этих юнитов м.б. юнитами служб.
Др. юниты м.б. дополнительными юнитами целей со своими собственными группами
юнитов. Юниты целей позволяют группировать другие юниты не только на основе
содержимого соответствующих файлов юнитов. Файл юнита цели может использовать
директорию .wants для размещения ссылок на юниты, которые должны запускаться
вместе с юнитом цели.
Показать юнит по умолчанию: systemctl get-default
Показать активные юниты: systemctl list-units --type target
Показать все загруженные юниты: systemctl list-units --type target –all
Изменить юнит по умолчанию: systemctl set-default name.target
Включить все сервисы из name.target и выключить все остальные включенные
сервисы: systemctl isolate name.target
Узнать статус (запущен/остановлен): systemctl status my-name.target
Запуск сервиса или target: systemctl start my-name.target
Остановка сервиса или target: systemctl stop my-name.target
29.Упр-е системными и сетевыми сервисами. Выгрузка системы, перезагрузка,
приостановка и остановка системы.
Упр-е системными и сетевыми сервисами.
Systemd – системный менеджер инициализации демонов в linux. За счет
распараллеливания запуска служб systemd позволяет ускорить загрузку ОС, а также
обладает удобным функционалом. Systemd оперирует специально оформленными
файлами конфигурации - юнитами(unit). Каждый юнит отвечает за отдельно взятую
службу, точку монтирования, подключаемое устройство, файл подкачки, виртуальную
машину и т.д.
Сущ-ют специальные типы юнитов, которые не несут функциональной нагрузки, но
позволяют задействовать доп. возм-ти systemd. К ним относятся юниты типа target, slice,
automount и др. systemd поддерживает следующие типы юнитов:
 .target - позволяет группировать юниты, воплощая концепцию уровней запуска
(runlevel)
 .service - отвечает за запуск сервисов (служб), также поддерживает вызов
интерпретаторов для исполнения пользовательских скриптов
 .mount - отвечает за монтирование файловых систем и т.д.
Юниты разложены в трех каталогах:
/usr/lib/systemd/system/ – юниты из установленных пакетов RPM
/run/systemd/system/ – юниты, созданные в рантайме
/etc/systemd/system/ – юниты, созданные системным администратором
Systemctl - главная команда для отслеживания и контроля состояния systemd.
Основные команды system ($ …):
 systemctl status – инф-ция о состоянии всех юнитов
 systemctl –type=service – инф-ция о состоянии всех юнитов
 systemctl status имя.тип – инф-ция о состоянии сервиса (напр, $ systemctl status
auditd.service)
 инф-ция о состоянии сервиса (другим способом): systemctl is-active auditd.service
systemctl is-enabled auditd.service
 инф-ция о зависимостях сервисов друг от друга: systemctl list-dependencies --after
auditd.service systemctl list-dependencies --before auditd.service
Команда shutdown исп-ся для завершения сеанса польз-ля, перезагрузки компьютера,
перевода его в спящий режим или выключения питания. При наличии соответствующих
разрешений, команда может выполняться для удаленной системы.
Пример: shutdown -s -t 10 – выключение компьютера через десять секунд .
Упр-е работой системы и питанием компьютера. Выгрузка системы, перезагрузка,
приостановка и остановка системы.
 выключение системы (выгрузить систему и отключить питание компьютера): #
systemctl poweroff
 остановить систему (выгрузить систему без отключения питания компьютера): #
systemctl halt
 Перезагрузка системы: # systemctl reboot (в лабе было: systemctl --no-wall reboot)*
 Приостановление работы системы: # systemctl suspend
30.Система принудит. упр-я доступом SELinux. Режимы работы. Формат файла
/etc/selinux/config. Получение инф-ции о режиме работы. Изменение режима работы.
SELinux (Security Enhanced Linux) – система мандатного контроля доступа, встроенная
в ядро. Является дополнительным уровнем без-ти к стандартной в системах GNU/Linux
дискреционной модели упр-я доступом (user/group/other). Основная цель – защитить
пользовательские данные от системных процессов, которые м.б. скомпрометированы.
SELinux включает в себя систему правил без-ти, которые определяют, какой процесс
имеет доступ к каким файлам, каталогам, портам. Каждый файл, процесс, каталог, порт в
SELinux имеет спец. атрибут, который называется контекстом без-ти. Он исп-ся в
политике SELinux, чтобы разграничивать доступ. По умолчанию (если в политике нет
разрешающего правила) – доступ запрещен.
Структура контекста: user : role : type : sensitivity
Режимы работы SELinux.
1. Enforcing. Режим по умолчанию. При выборе этого режима все действия, которые
каким-то образом нарушают текущую политику без-ти, будут блокироваться, а
попытка нарушения будет зафиксирована в журнале.
2. Permissive. В случае исп-я этого режима, инф-ция о всех действиях, которые
нарушают текущую политику без-ти, будут зафиксированы в журнале, но сами
действия не будут заблокированы.
3. Disabled. Полное отключение системы SELinux.
Помимо режима работы к основным настройкам SELinux относится также параметр
SELINUXTYPE, указывающий какую политику без-ти необходимо использовать. Был
создан ряд стандартных политик без-ти для системы мандатного контроля доступа
(targeted, strict, mls)
По умолчанию SELinux использует целевую (targeted) политику без-ти, направленную на
защиту от потенциально компрометируемых злоумышленниками системных процессов.
Режим работы и тип политики системы SELinux описаны в файле /etc/selinux/config.
Содержимое файла включает в себя две переменные:
SELINUX=(enforcing/permissive/disabled) // режим работы
SELINUXTYPE=(targeted/mls) // типа политики
Команда
Что возвращает
getenforce
Enforcing/Permissive/Disabled
Статус SELinux и используемой политики:
SELinux status:
enabled
SELinuxfs mount:
/selinux
Sestatus
Current mode:
enforcing
Mode from config file:
enforcing
Policy version:
23
Policy from config file:
targeted
Способы изменения режима работы:
1. Сконфигурировать файл /etc/selinux/config, указать явно значение режима работы в
переменной SELINUX, перезагрузить систему.
2. Использовать команду: setenforce [ Enforcing | Permissive | 1 | 0 ], которая переключает
между режимами.
3. Отредактировать строку загрузки ядра.
/boot/grub/grub.conf – файл с конфигом для загрузчика GRUB.
В строке kernel, касающейся selinux, добавить enforcing=0 (постоянный Permissive)
или selinux=0 (постоянный Disabled)
31. Сист. принуд. упр-я дост. SELinux. Об и суб дост. Назн-е и формат контекста без.
SELinux – реализация системы принудительного контроля доступа. Разграничение
доступа основывается на ограничении доступа процессов к ресурсам. Все разграничение
доступа в ОС основывается на типах атрибутов доступа объектов и субъектов. В SELinux
эти атрибуты называются security context или контекст без-ти. Объекты доступа – то, к
чему производится доступ: файлы; сокеты; network hosts; каналы, использующиеся для
связи процессов друг с другом. Субъекты доступа – та сущность, которая пытается
получить доступ к объекту доступа. Субъект доступа – это процесс. Все объекты и
субъекты имеют связанный с ними контекст без-ти. Контекст без-ти состоит из 3х частей:
польз-ль, роль и тип. Обычно контекст без-ти отображается в след виде: user:role:type
Чтобы увидеть отображение контекста без-ти достаточно добавить опцию -Z в команду.
Например: $ id -Z
joe:user_r:user_t.
В SELinux индентификатор type явл-ся главной частью контекста без-ти, которая опр-ет,
разрешен ли доступ или нет. Идентификатор type процесса часто называют доменом.
Идентификаторы user и role имеют малое влияние на политику разграничения доступа для
type enforcement. По отн-ю к процессам user и role имеют большее значение, так как они
исп-ся для контроля соотв-я между type и идентификатором польз-ля (а следовательно, с
аккаунтами польз-лей Linux).
По отн-ю к объектам user и role практически не имеют влияния. По соглашению role
объекта – обычно object_r, а идентификатор user объекта - обычно пользовательский
идентификатор процесса, который создал этот объект.
Назначение контекста без-ти – сопоставить каждому объекту и субъекту в системе свою
метку, которая будет однозначно идентифицировать права. На основе сравнения
вырабатывается окончательное решение о разрешении доступа или о запрете.
Есть несколько схем реализации разграничения доступа в SELinux. Одна из этих схем –
Type Enforcement – основной механизм контроля доступа, используемый в целевых
политиках. Позволяет детально, на самом низком уровне управлять разрешениями. Самый
гибкий, но и самый трудоемкий для системного администратора механизм.
В SELinux доступ к любым объектам д.б. явно разрешен. В SELinux запрещает доступ по
умолчанию, это значит, что в SELinux нет суперпольз-ля по умолчанию, как root в Linux.
Разрешение доступа для определенного типа субъекта (для домена) к определенному типу
объекта осущ-ся при помощи команды allow.
Команда allow принимает 4 аргумента: source type (обычно домен процесса, которому
разрешаем доступ); target type (тип объекта, к которому
разрешаем доступ); object class (класс объекта);
permissions (по сути действия, которые субъект может
совершать над объектом с указанными типом и классом)
Пример: allow user_t bin_t : file {read execute getattr};
- разрешить процессам с доменом user_t чтение, запуск на
исполнение и получение атрибутов файлов с типом bin_t.
getattr позволяет процессу получать сведения об объекте
(дату создания, время создания и т.д.).
Визуализация правила allow: Рассмотрим, как программа passwd использует Type
Enforcement для разграничения доступа. Программа passwd должна иметь доступ для
чтения и редактирования файла /etc/shadow. В Linux достаточно запустить passwd от root,
в Type Enforcement же исп-ся более тонкая настройка – можно разрешить доступ к файлу
/etc/shadow только программе passwd, вне зависимости от того, какой польз-ль ее запустил.
В данном примере мы ввели 2 идентификатора type: passwd_t (домен, который будет
использовать программа passwd) и shadow_t (тип для файла /etc/shadow).
Рассмотрим команду allow подробнее: ее
назначение – разрешить домену passwd_t
доступ к файлу с типом shadow_t. Это
нужно для того, чтобы разрешить
процессу перемещать и создавать новый
shadow файл.
На картинке выше можно видеть, что
упр-е файлом shadow будет выполнено
успешно,
т.к.
процесс
имеет
эффективный id root и потому что
правило allow Type Enforcement
разрешает данному домену процесса доступ к файлу shadow.
32. Система принудит. упр-я доступом SELinux. Классы объектов ФС. Права доступа
к обычному файлу (объект file). Назначение контекста файлам. Наследование по
умолч-ю. Переход типа. Копир-е и перемещение файла внутри и за пределы ФС.
Классы объектов – категории каких-либо ресурсов, напр, files, sockets, а разрешения
представляют собой доступ к этим ресурсами, напр, read, write, send….
Классы объектов:
 Dir – директории
 Lnk_file – Символьная ссылка
 File – обычные файлы
(указатель на файл)
 Fd – дескрипторы файлов

Process – процесс
 Filesystem – Файловые системы
 System – Система в целом
Чтобы объявить класс объекта исп-ся оператор объявления: class class_name
Права доступа к классу file: append, create, entrypoint (file м.б. использован, как точка
доступа к новому домену с помощью доменного перехода (об этом далее)), execute, link
(создание жесткой ссылки), getattr, setattr, read, rename и т. д.
Изменение контекста без-ти файла
сhcon – изменяет контекст без-ти файла.
restorecon – восстанавливает контекст без-ти, определенный политикой.
Наследование контекста по умолчанию: Если процесс работает с каким-то контекстом
и запускает новый процесс, то тот будет иметь тот же контекст. Файл или директория,
созданные в директории с определенным контекстом, будут иметь тот же контекст.
Доменный переход – изменение польз-ля, роли или типа. Переход прописывается в
политике без-ти. Условия разрешения доменного перехода:
 Первоначальный домен должен иметь право execute на файл
allow user_t passwd_exec_t : file {execute getattr};
 В контексте файла д.б. определен entrypoint к целевому домену
allow passwd_t passwd_exec_t : file entrypoint;
 Первоначальный домен должен иметь разрешение переходить в целевой домен.
allow user_t passwd_t : process transition;
Пример: изменение пароля: если доменный тип user_t будет иметь возм-ть читать и
записывать в файл с паролями, тогда любая программа сможет просматривать и изменять
этот файл. Мы хотим, чтобы только программа с доменом passwd_t имела к нему доступ.
Копирование и перемещение файла внутри и за пределы файловой системы.
Если копировать файлы с помощью команды cp, то файл унаследует контекст без-ти от
директории, в которую его копируют, поскольку он создает новый файл в целевой
директории. С помощью опции –Z можно задать лэйбл (тип) файлу: –Z user:role:type.
Пример: cp -Z user_u:object_r:user_home_t foo /tmp/
Чтобы сохранить текущий контекст исп-ся cp –preserve=context
--context исп-ся чтобы изменить контекст без-ти копии.
cp –contest=system_u:object_r:samba_share_t:s0 file1 file2
При перемещении с помощью mv файлы сохраняют свой текущий контекст без-ти.
Скачать
Случайные карточки
Каталог карточек