Astramode astra linux отключить

Обновлено: 05.07.2024

В данном руководстве описан процесс установки и первичной конфигурации операционной системы Astra Linux Common Edition (Релиз "Орел", версия 2.12) в целях последующей установки под данной операционной системой программных средств Платформы НЕЙРОСС. Приводимые в настоящем руководстве инструкции описывают лишь один из возможных способов установки и настройки программных средств.

Загрузка дистрибутива ОС

Запишите загруженный ISO-образ на установочный носитель (DVD-диск / USB-флешку).

По вашему запросу компания ИТРИУМ может предоставить дистрибутив операционной системы.

Установка операционной системы

Задайте разметку дисков.

Системными требованиями обусловлено наличие выделенного под ОС диска. В этом случае используйте опцию Guided — use entire disk (Использовать весь диск).

При наличии одного физического диска (не рекомендуемый вариант), необходимо создать как минимум два логических раздела на данном диске — для операционной системы и для данных (медиаданные, резервные копии и др.). Для этого выберите Вручную и выделите под раздел операционной системы только часть носителя. Раздел для данных можно создать как на данном этапе, так и впоследствии — см. раздел Подготовка накопителей.

Дождитесь окончания процесса установки и извлеките установочный диск для загрузки ОС.

Настройка сетевых параметров

Для корректной работы требуется фиксированный IP-адрес сервера. Задайте сетевые параметры вручную или используйте DHCP, который всегда для данного MAC выдаёт один и тот же IP-адрес.

Отключите network-manager. Для этого, откройте терминал Fly и выполните следующую команду:

sudo apt remove network-manager -y

После отключения network-manager перезагрузите систему.

Откройте терминал Fly и выведите список подключённых сетевых устройств:

В тексте вывода обратите внимание на первую строку:

eth0 - это и есть искомое имя сетевого интерфейса . С етевые интерфейсы могут иметь и другие имена. В результате eth0 может называться, например enp0s3 или eno1 , или даже enx78e7d1ea46da . Именно это имя сетевого адаптера и нужно использовать в настройке сети.

Рассмотрим пример настройки одного сетевого интерфейса со статическим IP-адресом. Выполните команду открытия файла /etc/network/interfaces в текстовом редакторе:

Допишите блок кода (вместо eth0 впишите имя вашего интерфейса):

auto eth0
iface eth0 inet static
address 10.1 . 29.37
netmask 255.248 . 0.0
gateway 10.0 . 1.1
dns-nameservers 10.1 . 31.1

auto eth0 — флаг автоматического включения сетевого интерфейса eth0 при загрузке системы;

iface eth0 inet static — интерфейс ( iface eth0 ) находится в диапазоне адресов IPv4 ( inet ) со статическим ip ( static );

address 10.1.29.37 — IP адрес (address) сетевой карты;

netmask 255.248.0.0 — маска подсети (netmask);

gateway 10.0.1.1 — адрес шлюза ( gateway );

dns-nameservers 10.1.31.1 — адреса DNS серверов;

Сохраните изменения: нажмите Ctrl+X, введите Y (для подтверждения изменений) и нажмите Enter.

Настройка репозиториев

Для установки необходимых системных компонентов необходимо произвести настройку репозиториев Astra Linux.

Выполните команду открытия файла /etc/apt/sources.list в текстовом редакторе:

Измените блок кода и приведите его к следующему виду:

Установка системных компонентов

Для работы Платформы НЕЙРОСС необходимо установить и настроить Java 1.8 (ГосJava) и некоторые системные утилиты (ntpdate и др.). Приведённые ниже инструкции предполагают, что у целевой операционной системы корректно настроен сетевой интерфейс и есть доступ в сеть Интернет. В отсутствие доступа в сеть Интернет вы можете загрузить необходимые deb-пакеты, перенести их на целевую систему и установить их вручную.

Установка ГосJava

Создайте файл /etc/apt/sources.list.d/gosjava.list:

Добавьте в него следующую строку:

Сохраните изменения: нажмите Ctrl+X, введите Y (для подтверждения изменений) и нажмите Enter.

Добавьте цифровой ключ подписи в APT.

Проверить корректность установки java вы можете с помощью команды:

Установка необходимых системных компонентов

Установка и настройка NTP-сервера

Все узлы сети НЕЙРОСС должны быть синхронизированы по времени. Для этого каждый узел выполняет периодическую синхронизацию времени с NTP-сервером, адрес которого задан в настройках узла.

Платформа НЕЙРОСС автоматически выполняет синхронизацию времени с указанным в настройках NTP-сервером. Если сервер Платформы НЕЙРОСС должен сам выступать в роли NTP-сервера для других узлов НЕЙРОСС, то необходимо установить системный сервис NTP-сервера.

Проверьте, правильно ли установлена временная зона:

При необходимости, выполните перенастройку:

Установите демон NTP-сервера:

Если сервер должен быть основным источником времени (должен «доверять» сам себе), то отредактируйте файл /etc/ntp.conf в текстовом редакторе:

Поместите следующее содержимое в файл /etc/ntp.conf :

После переконфигурации NTP-сервера может потребоваться 10-15 минут, чтобы применить новые настройки. В течение этого времени синхронизация с этим NTP-сервером может быть всё ещё недоступна.

Подготовка накопителей

Для обработки медиаданных (импорта, экспорта и пр.) требуется хотя бы один накопитель. В роли накопителей в Платформе НЕЙРОСС выступают разделы (partitions) на жёстких дисках. Платформа НЕЙРОСС использует все смонтированные разделы с файловыми системами типов Ext4, Ext2, NTFS, VFAT за исключением корневого раздела (смонтированного в / ), однако для медиаданных рекомендуется выделить отдельный физический диск/диски.

В подавляющем большинстве случаев достаточно простого физического подключения диска, но иногда требуется смонтировать раздел для диска вручную.

Выполните физическое подключение диска и загрузите операционную систему.

Выполните поиск всех доступных дисков и разделов:

Название жёсткого диска в Linux зависит от интерфейса, через который он подключён. Название может начинаться на:
sd — устройство, подключённое по SCSI (сюда входят жёсткие диски, USB-флешки и ATA-диски, которые подключаются к SCSI через специальный переходник);
hd — устройство ATA;
vd — виртуальное устройство;
mmcblk — обозначаются флешки, подключённые через картридер;
Третья буква в имени диска означает его порядковый номер в системе: sda - первый диск, sdb - второй диск, sdc - третий и так далее. Дальше следует цифра - это номер раздела на диске - sda1, sda2.
Пример вывода команды (два диска: sda и sdb, диск sdb не имеет таблицы разделов):

Создайте точку монтирования раздела:

Отформатируйте диск в файловую систему ext4 с помощью утилиты mkfs :

Где:
/dev/sdb — форматируемый диск.

Где:
/dev/sdb — монтируемый диск;
/storage — выделенный раздел для диска.

06.03.2020

Установка ОС Astra Linux SE 1.6 по сети без ошибок

Коллеги! Обещанного 3 года ждут, но тем не менее. Многие помнят проблему Astra Linux SE релиза 1.6 с сетевой установкой, не решенную, кстати, до сих пор. Но прогресс не стоит на месте и найден путь ee обхода. Теперь мы можем в полной мере наслаждаться преимуществами сетевой инсталляции Astra! Выход этой статьи приурочен к 8 марта, так что еще раз присоединяюсь к поздравлениям нашим прекрасным дамам и желаю счастья, красоты и здоровья! А теперь заканчиваем затянувшуюся музыкальную паузу и дружно приступаем к инсталляции!

1. Установка пакетов

subnet 10.0.2.0 netmask 255.255.255.0

range 10.0.2.10 10.0.2.100;
max-lease-time 86400;
filename "pxelinux.0";
next-server 10.0.2.15;
>

Чтобы сервис начал работу с новыми настройками, его нужно перезапустить:

sudo systemctl restart isc-dhcp-server

Установить пакет tftpd-hpa. Установить его можно из графического менеджера пакетов, или из командной строки командой:

sudo apt install tftpd-hpa apache2*

2. Настройка tftp-hpa

Настройки пакета хранятся в файле /etc/default/tftpd-hpa . Приведём его к следующему виду (жирным шрифтом выделены рекомендованные к добавлению параметры):

Чтобы сервис начал работу с новыми настройками, его нужно перезапустить:

sudo systemctl restart tftpd-hpa

Создаем директории для монтирования репозитория:

mkdir /var/www/ html/astra
mount /dev/cdrom /var/www/html/astra

Кладем в /var/www/html файл preceed.cfg * (ниже будет рассказано, как его получить)

Проверяем его работу через firefox:

Если дерево директорий не видно, тогда выполняем:

echo "AstraMode off" >> /etc/apache2/apache2.conf
systemctl restart apache2

Проверяем наличие файлов через firefox

Изменилась ли картинка? Почему? (ответ: отключили принудительную аутентификацию)

Изменяем /etc/apt/sources.list следующим содержимым:

4. Размещение данных для загрузки

В каталог /srv/tftp поместить содержимое каталога netinst и библиотеку ldlinux.c32 с установочного диска:

sudo cp /var/www/html/astra/netinst/* /srv/tftp/
sudo cp /var/www/html/astra/isolinux/ldlinux.c32 /srv/tftp/

Создать в /srv/tftp директорию pxelinux.cfg

sudo mkdir /srv/tftp/pxelinux.cfg

В этой директории создать файл default . Содержимое файла default для полной автоматизации должно содержать параметры, передаваемые файлу preseed.cfg:

/srv/tftp/pxelinux.cfg/default

*В примере предполагается, что IP-адрес сервера для загрузки 10.0.2.15

Примечание 1.

В файле preseed.cfg с помощью текстового редактора изменить источник, из которого должны будут скачиваться пакеты при установке, например репозиторий, а также иные параметры!

Выставить права на этот файл:

chmod 664 /var/www/html/preseed.cfg

Примечание 2.

sudo debconf-get-selections --installer > preseed.cfg из пакета debconf-utils на ранее установленной типовой системе.

Поздравляю! Ваша система прокачана готова к безошибочной установке по сети!

Устанавливайте в BIOS на клиентской машине загрузку по сети и наслаждайтесь!

Операционных систем без уязвимостей не бывает — вопрос лишь в том, как эффективно разработчики их выявляют и закрывают. Наша ОС Astra Linux Special Edition здесь не исключение: мы постоянно проверяем и тестируем код на ошибки, нарушения логики, прочие баги и оперативно их устраняем. Иначе бы ФСТЭК России вряд ли сертифицировала Astra Linux на обработку данных, составляющих гостайну. Но о сертификации мы поговорим подробней в другом посте. А в этом расскажем о том, как организована работа над уязвимостями Astra Linux и взаимодействие с отечественным банком данных угроз безопасности информации.

Фото: Leonhard Foeger/Reuters

Подход первый, архитектурный

Для улучшения безопасности ОС мы используем два подхода. Первый, архитектурный, заключается в том, что мы разрабатываем и внедряем различные средства защиты информации еще на этапе проектирования. Эти средства образуют комплекс средств защиты (КСЗ), который реализует функции безопасности. С помощью КСЗ мы стараемся достичь того, чтобы в системе уже по умолчанию был минимизирован риск возможных потенциальных угроз.

Архитектура комплекса средств защиты Astra LInux Special Edition

Ключевой элемент КСЗ – монитор обращений, созданный чтобы предотвращать несанкционированный доступ и изменение защищаемых компонентов системы. Монитор предусматривает дискреционное, ролевое и мандатное управление доступом, а также мандатный контроль целостности.

Что такое мандатный контроль целостности? Поясним на примере. Ключевым компонентом ОС является ядро. Соответственно, мы обязаны обеспечить для него максимально защищенную среду выполнения в самой операционной системе, чтобы уменьшить количество возможных способов атаки на ядро.

Для этого мы реализуем в операционной системе мандатный контроль целостности, за счет чего сегментируем ОС по различным подсистемам — так, чтобы взлом одной подсистемы не повлиял на работоспособность других. Если произойдет взлом непривилегированного пользователя ОС (уровень целостности 0) или сетевой подсистемы (уровень целостности 1), системы виртуализации (уровень целостности 2), графического интерфейса (уровень целостности 8) или другого компонента, это не повлечет за собой дискредитацию всего КСЗ (уровень целостности 63).

При этом надо отметить, что указанные уровни не являются иерархическими, то есть не располагаются друг над другом и полностью изолированы друг от друга с точки зрения возможности прав записи. Принадлежность объекта к тому или иному уровню целостности монитор обращений определяет по битовой маске.

Чтобы уровни целостности не воспринимались как иерархические — то есть, например, «уровень 8 имеет больше прав, чем уровень 2», что неверно — каждый из уровней получает свое наименование. Так, например, восьмой уровень целостности называется «Графический сервер», максимально возможный уровень целостности администратора в системе — «Высокий», а нулевой уровень целостности (пользовательский) — «Низкий».

Монитор обращений, о котором рассказывалось в нашей предыдущей статье, контролирует и исключает возможность влияния друг на друга процессов с метками разных уровней целостности.

Таким образом операционная система получает набор правил, как изолировать друг от друга системные процессы, и теперь понимает, какие именно процессы, даже запущенные пользователем с высокими привилегиями, не имеют права на запись в другие процессы или файлы.

Поэтому если в результате эксплуатации уязвимости (в том числе, нулевого дня) злоумышленник получит контроль над каким-либо процессом в системе и повысит свои полномочия до привилегированного пользователя (например, root), его метка целостности останется прежней, и, соответственно, он не получит возможности влиять на системные процессы, менять настройки или скрыть свое присутствие в системе.

Принцип работы изолированных уровней целостности

Таким образом, значимой мишенью для злоумышленника становится уже не вся операционная система, а только hardened ядро и максимально компактный монитор обращений, что уже существенно сокращает поверхность атаки.

Помимо мандатного, есть еще динамический и регламентный контроль целостности. Их применяют для исключения запуска и использования недоверенного или стороннего ПО, а также периодических проверок целостности системы.

Динамический контроль вычисляет и проверяет электронную цифровую подпись исполняемых файлов в момент их запуска. Если ЭЦП нет или она неправильная, в запуске программ будет отказано. В какой-то степени это реализация концепции белых списков, но за счет использования иерархии ключей, выданных разработчикам программного обеспечения.

Работа с динамическим контролем целостности

Регламентный контроль проверяет целостность и неизменность ключевых для системы файлов, сравнивая их контрольные суммы с эталонными значениями. Это могут быть как конфигурационные файлы, так и любые другие.

Таким образом в ОС применяется эшелонированная защита от уязвимостей в приложениях и их подмены, чем минимизируется вред от угроз безопасности, в том числе и тех, которые используют уязвимости «нулевого» дня.

Подход второй, процессный

Вместе с архитектурным мы параллельно используем процессный подход: постоянно выявляем и собираем сведения об уязвимостях, прорабатываем эту информацию и передаем результаты в банк данных уязвимостей ФСТЭК России. Так мы готовим и выпускаем плановые и оперативные обновлений ОС. Ищем уязвимости как в открытых источниках, так и самостоятельно — особенно в тех частях ПО, которые полностью разрабатываем сами. Много информации мы получаем от партнеров, занимающихся аналогичными исследованиями — тестированием и изучением безопасности операционных систем.

Организация работ по выявлению уязвимостей

Исследования безопасности в первую очередь ведутся в отношении компонентов, которые входят в состав ОС Astra Linux Special Edition («Смоленск»). Вместе с тем уязвимости закрываются также и для версии Astra Linux Common Edition, как в рамках обновлений безопасности, так и в процессе планового обновления компонентов системы.

Как только мы получаем сведения об уязвимости, проверяем, насколько она актуальна для наших пользователей. Если уязвимость не является критической, то описываем ее в ближайшем выпуске бюллетеня безопасности на официальном сайте. Уведомления об выпуске бюллетеней отправляются пользователю по электронной̆ почте, адрес которой̆ обязательно указывается в лицензионном договоре. Для критических уязвимостей в течение нескольких дней выпускаются методические указания: каким образом можно устранить ее своими силами, не дожидаясь кумулятивного обновления безопасности. В списке бюллетеней безопасности они отмечены буквами MD (мethodical direction).

Здесь хорошим примером является уязвимость, информация о которой была опубликована здесь же, на Хабре. К слову, автор данной статьи с нами заранее не связывался и предварительно не уведомлял о том, что им выявлена данная уязвимость и готовится материал. В качестве иллюстрации мы решили привести тайминг работ над уязвимостью с момента размещения текста на ресурсе.

Итак, ночью, в 4 утра, 9 июля 2019 года была опубликована сама статья, о том, что при манипуляциях с размером экрана виртуальной машины можно увидеть окна под блокировщиком экрана.

Стоит отметить, что для эксплуатации продемонстрированной на видео уязвимости нужно совершить ряд дополнительных действий: необходимо сначала установить на виртуальную машину Astra Linux, а затем и на гостевую машину дополнительные пакеты, которые отвечают за изменение разрешения виртуальной машины «на лету», но при этом не входят в состав сертифицированной операционной системы.

10 июля 2019 года сведения об уязвимости опубликованы в БДУ ФСТЭК. Серьёзность уязвимости была определена как средняя (базовая оценка по метрике CVSS 2.0 составила 4,9, по метрике CVSS 3.0 — 4).

12 июля нами опубликован бюллетень безопасности № 20190712SE16MD для Astra Linux Special Edition версии 1.6 и бюллетень безопасности № 20190712SE15MD для Astra Linux Special Edition версии 1.5. Аналогичное обновление безопасности получил и релиз Astra Linux Common Edition.

Таким образом, с момента размещения информации об уязвимости среднего уровня опасности до выпуска корректирующего патча для всех версий Astra Linux (где возможно использование виртуализации) прошло меньше 4 дней.

Схема выпуска оперативных обновлений для Astra Linux

Не реже чем раз в квартал мы выпускаем обновления безопасности — оперативные обновления, которые устраняют ранее неизвестные уязвимости, в том числе прикладного ПО, библиотек и функций ОС, не реализующих требования безопасности. Если угрозы безопасности, реализуемые с использованием уязвимости, нельзя исключить компенсирующими мерами, проводятся работы по доработке ОС. После завершения доработки и тестирования обновления безопасности на сайте также публикуется бюллетень и само обновление. За первые полгода 2019 года было выпущено два кумулятивных обновления для ОС Astra Linux Special Edition версии 1.6, закрывших сотни различных уязвимостей. Сейчас к выпуску готовится третье.

Наконец, мы активно взаимодействуем с сообществом разработчиков:

сообщаем в багтрекеры проектов о самостоятельно обнаруженных ошибках;
в проекты готовые исправления недостатков, закрытые нами;
обращаемся к коммьюнити с просьбами оказать содействие в устранении недостатков — знание логики работы программы позволяет на порядок быстрее получить исправление нежели реверсивный инжиниринг, проводимый собственными силами;
используем и включаем в свои обновления все выпускаемые сообществом исправления. Мы понимаем, что тем самым повышаем качество продукта. При этом применяем методы контроля и обеспечения доверия, о которых писали в предыдущей статье.

Открытость — это важно

Поскольку наша ОС сертифицирована ФСТЭК России, мы в первую очередь добавляем информацию о найденных уязвимостях в банк данных угроз безопасности информации (БДУ) ФСТЭК для официальной публикации: если вы зайдете в БДУ, то найдете информацию о более чем 350 устраненных уязвимостей в разных версиях Astra Linux, а также подробную информацию по ним.

Таким образом мы обеспечиваем открытость в работе. Благодаря этому пользователи — и регулятор в том числе — могут быть в определенной степени уверены в том, что безопасность действительно находится под контролем. Мало получить обновление, нужно понимать, какие конкретно уязвимости оно закрыло.

Пока что наш архитектурно-процессный подход по поддержанию безопасности ОС полностью себя оправдывает — мы успешно соблюдаем высокий уровень защищенности информационных систем с ОС Astra Linux Special Edition. А открытый доступ к информации об уязвимостях через БДУ ФСТЭК повышает уровень доверия к нашему продукту.

Будем рады ответить на вопросы о безопасности нашей системы в комментариях. Также, если вам интересно узнать что-то новое о системе, оставляйте ваши пожелания — мы их обязательно учтем при дальнейшей работе с блогом.

1.Основные задачи администрирования ASTRA LINUX SE.

В общем случае процесс администрирования ОС на базе проекта Debian GNU/Linux (в том числе ASTRA LINUX SE) включает решение следующих основных задач:

администрирование учётных записей пользователей и групп с целью организации многопользовательской работы ASTRA LINUX SE и реализации управления доступом процессов (субъект-сессий, функционирующих от имени учётных записей пользователей) к файлам, каталогам и другим объектам доступа ASTRA LINUX SE (сущностям);
администрирование процессов с целью оптимизации распределения между ними ресурсов компьютера;
администрирования запоминающих и периферийных устройств с целью контроля имеющихся в составе компьютера устройств и управления динамически подключаемыми устройствами.
В случае включения компьютера с ASTRA LINUX SE в сетевую среду и его функционирования в составе домена сетевой инфраструктуры Astra Linux Directory (ALD) перечень задач дополняется задачами администрирования сети и доменной инфраструктуры. Эти задачи будут подробно рассмотрены в следующих лекциях.

2. Администрирование учётных записей пользователей и групп.

Отправной точкой реализации управления доступом в ASTRA LINUX SE являлось унаследованное от ОС семейства Linux дискреционное управление доступом. Поэтому, несмотря на то, что в настоящее время в ASTRA LINUX SE используются мандатные управление доступом и контроль целостности, а в перспективе ролевое управление доступом, целесообразно рассмотреть основные элементы дискреционного управления доступом, не утратившие своей актуальности в современных релизах ASTRA LINUX SE.

Дискреционное управление доступом в ОС семейства Linux базируется на понятии владения (использовании права доступа владения) файлом, каталогом, процессом (сущностями и субъект-сессиями). Так в файловых системах семейства extfs, которые по умолчанию используются в ASTRA LINUX SE, для каждого файла или каталога обязательно задана учётная запись пользователя — их владелец. Процесс, функционирующий от имени такой учётной записи-владельца сущности, имеет право изменять дискреционные права доступа к ней, например назначать их учётным записям других пользователей ASTRA LINUX SE на основе стандарта POSIX ACL .

Access Control List или ACL — список контроля доступа, который определяет, кто или что может получать доступ к конкретному объекту, и какие именно операции разрешено или запрещено этому субъекту проводить над объектом. Списки контроля доступа являются основой систем с избирательным управлением доступа.

Для оптимизации и облегчения администрирования дискреционного управления доступом в случаях, когда к одним и тем же файлам или каталогам требуется установить одинаковые права доступа более чем для одной учётной записи пользователя, в ASTRA LINUX SE применяются группы учётных записей пользователей. В результате для файлов и каталогов владельцем (обладателем к ним правом доступа владения) может быть задана группа. При этом для них остаются владельцами и соответствующие учётные записи пользователей. В перспективе при реализации в ASTRA LINUX SE ролевого управления доступом вместо учётных записей пользователей и групп владельцами будут задаваться роли или административные роли.

Таким образом, при управлении доступом в ASTRA LINUX SE, в том числе дискреционным, администрируют следующие его элементы:

учётные записи пользователей (account);
группы (логические объединения учётных записей пользователей с равными дискреционными правами доступа);
права доступа к файлам, каталогам, другим объектам доступа (сущностям и субъект-сессиям);
режимы доступа, обеспечивающие возможность учета ряда особенностей управления доступом.

Утилиты администрирования учётных записей пользователей и групп реализованы в пакете Shadow Suite.

Кроме них для этого используется ряд системных файлов, которые конфигурируются администратором системы. Такие файлы в рамках МРОСЛ ДП -модели рассматриваются как сущности, параметрически ассоциированные с учётными записями пользователей.

Основой для задания учётных записей пользователей и групп являются их идентификаторы:

uid (User ID) — число, уникально идентифицирующее учётную запись пользователя в ASTRA LINUX SE;
gid (Group ID) — число, уникально идентифицирующее группу пользователей ASTRA LINUX SE.

Эти идентификаторы хранятся в следующих конфигурационных файлах, которые используется специальным процессом login, реализующим вход пользователя в ASTRA LINUX SE — его идентификацию и аутентификацию:

/etc/passwd — файл с данными об учётных записях пользователей;
/etc/group — файл с данными об учётных записях групп пользователей.

учётная запись каждого пользователя представляет одну строку в файле/etc/passwd. Таким образом, регистрация новой учётной записи пользователя в системе, фактически, является добавлением соответствующей строки в этот файл.

Добавим пользователя admin.

Откроем файл /etc/passwd в редакторе mc

Разделителем полей данных в строке, соответствующей учётной записи пользователя, является символ «:». В результате у администратора с помощью команды grep есть возможность фильтрации требуемых данных об учётной записи пользователя, которая состоит из следующих элементов:

• username — уникальное символьное имя, присваиваемое каждой учётной записи пользователя (при выборе имени могут использоваться буквы и цифры, а также знак подчёркивания и точка);

• uid — уникальный идентификатор учётной записи пользователя (представлен числом);

• gid — уникальный идентификатор первичной группы, в которую входит учётная запись пользователя (представлен числом);

• password — пароль, который может храниться в зашифрованном виде непосредственно в рассматриваемой строке (если вместо пароля задан символ «х»), то он хранится в доступном для чтения и записи только администратору системном файле /etc/shadow в зашифрованном виде);

• full name — полное имя учётной записи пользователя (например, пользователь с username равным sidor может иметь полное имя «Ivan Sidorov», а также в этом же элементе через запятую могут перечисляться дополнительные сведения о пользователе: домашний и рабочий номера телефонов, адрес и т.д.);

• home directory — домашний каталог учётной записи пользователя, находящийся в каталоге /home;

• login shell — командный интерпретатор (shell), который запускается при входе пользователя в ASTRA LINUX SE, по умолчанию это интерпретатор bash (/bin/bash).

Создание, удаление и изменение учётных записей пользователей осуществляется администратором (в рамках МРОСЛ ДП-модели ему соответствует доверенная субъект-сессия, обладающая соответствующими текущими специальными административными ролями) с использованием следующих приёмов:

• непосредственное редактирование файла /etc/passwd;

• с применением утилит из пакетов passwd и adduser;

• с активизацией из меню «Пользователи и группы» утилиты с графическим интерфейсом «Управление политикой безопасности».

В ASTRA LINUX SE получение идентификатора учётной записи пользователя (uid), а также других связанных с ним наборов параметров, возможно с помощью команд whoami, id, who. Для изменения пароля учётной записи пользователя используется команда passwd, которая проверяет заданные правила формирования пароля, например, его минимальную длину, или же создан ли он на основе предыдущего пароля.

Для корректного администрирования учётной записи пользователя (в том числе с добавлением при её создании в домашний каталог необходимых конфигурационных файлов) администратор может использовать команды adduser, useradd (создание), usermod (модификация параметров) и userdel (удаление). В рамках МРОСЛ ДП-модели этим командам соответствуют де-юре правила вида create_ user, set-user_labels и delete-user.

В то же время для администрирования учётных записей пользователей целесообразно использовать утилиту с графическим интерфейсом «Управление политикой безопасности» (утилиту flу-admin-smc), доступную из элемента «Настройки» главного пользовательского меню.

Добавление учётной записи пользователя также осуществляется администратором с использованием утилиты «Управление политикой безопасности».

Для безопасности ASTRA LINUX SE важна регулярная проверка корректности параметров учётных записей пользователей, для чего администратор может использовать команду pwck (от password check), которая проверяет целостность данных и правильность формата записей в файлах /etc/passwd и /etc/shadow, при этом проверяются:

- корректность количества полей в записях этих файлов;
- уникальность имён учётных записей пользователей;
- уникальность идентификаторов учётных записей пользователей;
- корректность принадлежности каждой учётной записи пользователя её первичной группе;
- корректность пути к домашнему каталогу каждой учётной записи пользователя;
- корректность сведений об используемом интерпретаторе по умолчанию.
Исправление выявленных командой pwck ошибок администратор может осуществить с помощью команды usermod.

Данные о каждой группе учётных записей пользователей находятся в системном файле /etc/group в строке формата «groupname: password:gid:other members», которая состоит из следующих элемента

• groupname — имя группы;

• password — пароль, установленный для группы;

• gid — идентификатор группы (аналогичный полю gid в учётной записи пользователя);

• other members — другие пользователи, входящие в состав группы.

Как и в случае системного файла /etc/passwd право на запись в файл /etc/group (который является сущностью, параметрически ассоциированной с учётными записями доверенных и недоверенных пользователей) имеет только администратор, остальные пользователи могут только просматривать его содержимое.

Пользователь может получить данные о своей принадлежности к группам с помощью команд id и groups. Администратор может создавать, удалять или изменять параметры групп учётных записей пользователей:

• редактируя файлы /etc/group и /etc/gshadow (назначение последнего аналогично назначению файла /etc/shadow) командой gpasswd;

• используя команды groupadd и groupdel;

• изменяя параметры групп учётных записей пользователей командой groupmod;

• используя утилиту «Управление политикой безопасности».

Для проверки корректности параметров групп учётных запиcей пользователей используется аналогичная команде pwck команда grpck, которая анализирует данные файлов /etc/group и /etc/gshadow, дополнительно используя для этого данные из файла /etc/passwd. При этом проверяются:

• корректность количества полей в записях этих файлов;

• уникальность имён групп;

• уникальность идентификаторов групп;

• корректность состава учётных записей пользователей и администраторов каждой группы.

Исправление выявленных командой grpck ошибок администратор может осуществить с помощью команды groupmod.

Так как в перспективе на смену группам в ASTRA LINUX SE придут роли или административные роли, то в рамках МРОСЛ ДП-модели к командам администрирования групп учётных записей пользователей соответствуют де-юре правила вида grant_admin_rights, remove_admin_rights, create-role, delete_role, create_hard_link_role, delete_hard_link_role, rename_role, get_role_attr, set_role_labels.

3.Администрирование процессов.

Администратору ASTRA LINUX SE требуется контролировать и управлять выполнением совокупности процессов (доверенных или недоверенных субъект-сессий в рамках МРОСЛ ДП-модели), которые были запущены пользователями в рмчках своих сеансов, а также ядром ASTRA LINUX SE, системными и прикладными сервисами.

Основной командой для мониторинга состояния процессов в ASTRA LINUX SE является команда ps. Запущенная без опций и аргументов команда ps выводит на экран список процессов, выполняемых на активном терминале (tty) или псевдотерминале (pts), при этом для каждого процесса указываются:
- PID — идентификатор процесса, который присваивается при его г гарте из числа свободных PID в диапазоне значений от 0 до (2 32 – 1);
- TTY— терминал (tty) или псевдотерминал (pts), в котором выполняется процесс;
- TIME — время выполнения процесса процессором;
- CMD — имя программы, соответствующей выполняющемуся процессу.
Использование параметров с командой ps позволяет просмотреть более детальную информацию о процессах.

Опции, отбирающие процессы для отчёта:

-A : все процессы;

-a : связанные с конкретным терминалом, кроме главных системных процессов сеанса, часто используемая опция;

-N : отрицание выбора;

-d : все процессы, кроме главных системных процессов сеанса;

-e : все процессы;

-f : расширение информации

T : все процессы на конкретном терминале;

a : процессы, связанные с текущим терминалом, а также процессы других пользователей;

r : информация только о работающих процессах;

x : процессы, отсоединённые от терминала.
- R : процесс выполняется в данный момент
- S : процесс ожидает (т.е. спит менее 20 секунд)
- I : процесс бездействует (т.е. спит больше 20 секунд)
- D : процесс ожидает ввода-вывода (или другого недолгого события), непрерываемый
- Z : zombie или defunct процесс, то есть завершившийся процесс, код возврата которого пока не считан родителем
- T : процесс остановлен
- W : процесс в свопе
- < : процесс в приоритетном режиме.
- N : процесс в режиме низкого приоритета
- L : real-time процесс, имеются страницы, заблокированные в памяти.
- s : лидер сессии
Прототипом команды ps, позволяющим моделировать получении данных о процессах (субъект-сессиях), в рамках МРОСЛ ДП-модели является де-юре правило вида get-subject-attr.

Команда pstree дополняет команду ps, с её помощью можно отобразить дерево процессов, функционирующих на всех терминалах, в формате «предок-потомок». Это позволяет проследить, цепочку порождения исследуемого процесса и получить возможность корректного управления им (особенно это касается его завершения) с учётом его «родственных связей». Без использования параметров команда pstree выводит дерево процессов, где каждый процесс идентифицируется именем соответствующей ему программы.

Команды ps и pstree позволяют получить сведения о запущенных процессах, отследить их текущее состояние и взаимосвязи друг с другом. Для того чтобы получать данные о процессах, собранные за некоторый интервал времени, используется команда top. Принцип ее работы основан на периодическом анализе обновлений таблицы процессов ASTRA LINUX SE, что позволяет отследить изменение их параметров.

Информация, выводимая командой top, содержит общие данные о процессах и ресурсах ASTRA LINUX SE:
- число пользовательских сеансов (user);
- усреднённая загруженность ресурсов системы (load average);
- общее число процессов (total task) и число процессов, находящихся в разных состояниях (running, sleeping, stopped и zombie);
- загруженность процессора (%Cpu);
- распределение оперативной памяти между процессами (KiB Mem);
- используемые области подкачки страниц (KiB Swap).
Кроме того, команда top выводит в терминал все данные, выдаваемые командой ps в режиме детализированного вывода.

При работе в защищённой графической подсистеме Fly информацию, аналогичную выводимой командой top, можно получить с использованием графической утилиты «Системный монитор» меню Системные» главного меню.

Дополнительно графическая утилита «Системный монитор» может осуществлять управление процессами, при этом доступны следующие функции:

• остановки/возобновления работы процессов;

• прерывания (для допускающих прерывания процессов);

В ASTRA LINUX SE администратор может управлять запущенными процессами, передавая им сигналы с использованием команды kill (в рамках МРОСЛ ДП-модели ей соответствует де-юре правило вида delete_session). Процесс, получив сигнал, может отреагировать на него либо по умолчанию, заданному ядром ASTRA LINUX SE, либо использовать собственную функцию обработки сигнала. В основном сигналы команды kill предназначены для реализации различных режимов прерывания, завершения, приостановления или возобновления работы процессов. Команда killall является расширением команды kill и отличается от нее тем, что посылает сигналы всем процессам, запущенным при выполнении одной программы.

Также администратор и пользователи ASTRA LINUX SE имеют возможность влиять (например, с помощью команды nice) на использование выполняющимися процессами ресурса времени центрального процессора путём изменения их приоритета, указывающего ядру ASTRA LINUX SE, где расположить процесс в общей очереди готовых к выполнению на центральном процессоре процессов.

Читайте также: