Как отключить зпс astra linux
Команды-переключатели (за исключением команды astra-modeswitch), входящие в состав пакета astra-safepolicy, поддерживают стандартный набор опций вызова:
-
enable — включить/разрешить управляемое инструментом действие.
В некоторых командах для включения требуется дополнительный параметр (например, уровень для astra-mic-control enable или имя пользователя для astra-autologin-control);
В случаях, когда команда поддерживает ещё какие-либо опции, кроме указанного выше минимального набора, параметры дополнительных опций приводятся в описании команды (см. ниже).
Запуск команд-переключателей без параметров используется при необходимости повторно привести настройки системы в соответствии с состоянием переключателя (применяется только внутри unit-файлов, создаваемых при включении некоторых переключатей)".
astra-autologin-control
Управление автоматическим входом в графическую среду.
При включении нужно указать имя (логин) пользователя, от имени которого будет производиться автоматический вход в систему после загрузки.
astra-bash-lock
Управление блокировкой интерпретатора команд bash. Аналогична блокировке других интерпретаторов команд, но вынесена в отдельную блокировку, т.к. доставляет больше неудобств, в том числе для служб, работающих в фоновом режиме.
В частности, после блокировки интерпретатора bash становится невозможным вход непривилегированных пользователь, использующих bash в качестве командной оболочки, в консольную сессию.
Не распространяет своё действие на пользователей из группы astra-admin. Изменение режима блокировки вступает в действие немедленно.
astra-commands-lock
Управление блокировкой запуска пользователями следующих программ:
Программы блокируются для пользователей с помощью выставления на них прав доступа 750 (rwx r-x — — -). Эти программы необходимо блокировать при обработке в одной системе информации разных уровней конфиденциальности, т.к. с их помощью можно организовать скрытый канал передачи информации между уровнями.
Изменение режима блокировки вступает в действие немедленно.
astra-console-lock
Управление блокировкой доступа к консоли и терминалам для пользователей, не входящих в группу astra-console. При необходимости группа astra-console автоматически создается и при этом в неё включаются пользователи, состоящие в группе astra-admins на момент включения этой функции.
Изменение режима блокировки вступает в действие немедленно.
astra-digsig-control
Позволяет из командной строки включать и выключать режим замкнутой программной среды (ЗПС) в исполняемых файлах. Команда astra-digsig-control enable включает режим ЗПС, команда astra-digsig-control disable выключает режим ЗПС.
astra-docker-isolation
Переводит сервис docker с высокого уровня целостности на уровень целостности 2. Для этого в каталоге /etc/systemd размещаeтся override-файл. Изменения вступают в силу после перезапуска сервиса docker. Если служба docker не установлена, включение или отключение изоляции docker недоступно.
astra-format-lock
Включает или отключает запрос пароля администратора при форматировании съемных носителей. По умолчанию включено (пароль запрашивается).
astra-hardened-control
Включает/отключает в загрузчике grub2 загрузку ядра hardened по умолчанию, если такое ядро присутствует в системе.
Данный переключатель работает только в системах, использующих загрузчик grub2.
astra-ilev1-control
Переводит некоторые сетевые сервисы с высокого уровня целостности на уровень 1, для чего в каталоге /etc/systemd размещаются override-файлы для соответствующих сервисов. Изменения касаются следующих сервисов:
Если указанные сервисы не были установлены в момент включения этой функции, то функция автоматически применится и к вновь установленным сервисам. Для изменения уровня целостности работающего сервиса требуется его перезапуск. Выполнить перезапуск указанных сервисов можно путем перезагрузки системы, или командой:
astra-interpreters-lock
Блокирует запуск пользователями командных интерпретаторов:
astra-interpreters-lock НЕ БЛОКИРУЕТ интерпретатор bash , так как такая блокировка может отключить функционал, неочевидным образом использующий bash, что приведёт к нарушению нормальной работы ОС. Для блокировки иентерпретатора bash используйте переключатель astra-bash-lock.
Блокировка не позволяет пользователям исполнять в системе произвольный код в обход ЗПС. Не распространяется на пользователей из группы astra-admin.
Запуск сценариев, имеющих установленный бит разрешения исполнения, остаётся возможен. Блокировка запуска командных интерпретаторов должна использоваться совместно с astra-nochmodx-lock, т.к. в противном случае пользователь может сам создать сценарий, назначить ему бит исполнения и запустить, обойдя таким образом эту блокировку.
Изменение режима блокировки вступает в действие немедленно.
astra-lkrg-control
Если установлен пакет lkrg, настраивает автозагрузку модуля ядра lkrg при загрузке системы (на этапе загрузки initrd) и загружает модуль lkrg сразу после включения функции astra-lkrg-control. При отключении функции astra-lkrg-control модуль lkrg удаляется из автозагрузки и выгружается из ядра. lkrg — это экспериментальный модуль, обеспечивающий обнаружение некоторых уязвимостей и защиту пространства памяти ядра от модификации. Может конфликтовать с драйверами виртуализации, например, virtualbox.
astra-macros-lock
Блокирует исполнение макросов в документах libreoffice. Для этого из меню программ libreoffice удаляются соответствующие пункты, а файлы, отвечающие за работу макросов, перемещаются или делаются недоступными пользователю. Блокировка макросов решает две задачи — защищает от выполнения вредоносного кода при открытии документов и не позволяет злонамеренному пользователю исполнять произвольный код через механизм макросов.
Изменение режима блокировки вступает в действие немедленно.
astra-mac-control
Включает или отключает возможность работы приложений с ненулевым уровнем конфиденциальности. Состояние по умолчанию — включено. Изменения применяются после перезагрузки.
Отключение возможности работы приложений с файловыми объектами, имеющими ненулевую метку конфиденциальности, не равносильно удалению таких объектов.
Файловые объекты, имеющие ненулевую метку конфиденциальности после отключения возможности работы с ними сохраняются.
Доступ к таким объектам не может быть получен штатными средствами ОС, но доступ к ним может быть получен при наличии неконтролируемого физического доступа к ПК, позволяющему использовать нештатные средства.
astra-mic-control
Включает или отключает механизм контроля целостности в ядре, изменяя значение параметра parsec.max_ilev командной строки ядра. После отключении механизма контроля целостности и перезагрузки целостность на файловой системе сбрасывается на нулевые значения. После включения механизма контроля целостности и перезагрузки на объектах файловой системы восстанавливаются принятые по умолчанию значения целостности (высокий уровень целостности на каталоги /dev, /proc, /run, /sys). При включении этой функции возможно указать значение максимальной целостности, отличное от принятого по умолчанию (63), что требуется для специальных применений (Брест).
Механизм контроля целостности в ядре по умолчанию включён.
astra-modban-lock
Блокирует загрузку неиспользуемых модулей ядра. Неиспользуемыми считаются те модули, которые не загружены в момент включения функции.
Изменение режима блокировки вступает в действие немедленно.
astra-modeswitch
Переключает и отображает режимы работы систем защиты информации ОС:
- Базовый;
- Усиленный;
- Максимальный.
При изменении уровня защищенности (режимов работы ОС):
-
В сторону снижения уровня защищенности:
автоматически отключаются опции, которые для данного уровня защищенности недоступны;
Для того, чтобы переключение режимов вступило в силу, необходимо перезагрузить систему.
Функции, недоступные в выбранном режиме, невозможно будет включить:
Режим работы системы защиты
Дополнительные опции команды:
- list — вывести список доступных режимов;
- get — вывести текущий режим в числовом представлении;
- getname — вывести текущий режим в текстовом представлении;
set <v> — установить режим, указанный параметром <v> (число или текст). Допустимые значения для задания режимов:
| Режим работы системы защиты | Текстовое значение | Числовое значение |
|---|---|---|
| Базовый | base | 0 |
| Усиленный | advanced | 1 |
| Максимальный | maxinum | 2 |
astra-mount-lock
Запрещает монтирование съемных носителей с помощью службы fly-reflex-service/fly-admin-reflex непривилегированным пользователям.
Изменение режима монтирования вступает в действие немедленно.
astra-noautonet-control
Отключает автоматическое конфигурирование сетевых подключений, блокируя работу служб NetworkManager, network-manager и connman, а также отключает элемент управления сетью в трее графического интерфейса. Изменение режима блокировки вступает в действие немедленно.
astra-nobootmenu-control
Отключает отображение меню загрузчика grub2. Это затрудняет вмешательство пользователя в процесс загрузки и несколько ускоряет загрузку.
Данный переключатель работает только в системах, использующих загрузчик grub2.
astra-nochmodx-lock
Блокирует возможность установки на файлы бита разрешения исполнения (chmod +x), чем не позволяет пользователям привнести в систему посторонний исполняемый код. Запрет распространяется в том числе и на пользователей из группы astra-admin, но не распространяется на root. Изменение режима вступает в действие немедленно.
astra-overlay
Включает overlay на корневой файловой системе (ФС). Фактическое содержимое корневой ФС монтируется в overlay одновременно с файловой системой, хранящейся в памяти. После этого все изменения файлов сохраняются только в памяти, а файловая система, хранящаяся на носителе, остается без изменений. После перезагрузки все изменения теряются, и система каждый раз загружается в исходном состоянии. Эта функция может применяться в тех случаях, когда носитель, на котором расположена корневая ФС, аппаратно защищен от записи, либо необходимо программно защитить ее от изменений.
Функционал overlay не касается файловых систем, хранящихся на отдельных разделах, отличных от корневого. Если, например, /home хранится на отдельном разделе или носителе, вносимые в него изменения будут сохраняться после перезагрузки.
Изменение режима работы вступает в действие после перезагрузки.
astra-ptrace-lock
Устанавливает максимальные ограничения на использование механизма ptrace, выставляя параметр kernel.yama.ptrace_scope в значение 3. Значение устанавливается сразу при включении этой функции и настраивается сохранение этого значения после перезагрузки. Функция не может быть отключена без перезагрузки.
astra-secdel-control
Включает режим безопасного удаления файлов на разделах с файловыми системами, присутствующими в файле /etc/fstab. Поддерживаются следующие форматы файловых систем:
Когда функция astra-secdel-control включена, при удалении файлов содержимое файлов затирается, чтобы его нельзя было восстановить. В обычных условиях при удалении файлы логически помечаются как удаленные, но их содержимое остается на носителе, пока не будет затерто новыми данными. Изменение режима работы вступает в действие после следующего монтирования файловой системы (в т.ч. после перезагрузки ОС).
astra-shutdown-lock
Блокирует выключение компьютера пользователями, не являющимися суперпользователями. Для этого права доступа на исполняемый файл /bin/systemctl меняются на 750 (rwx — — — — — -) и меняются параметры в fly-dmrc, после чего команды systemctl могут выполняться только от имени суперпользователя (sudo systemctl . ). Дополнительно отключается возможность перезагрузки ПК комбинацией клавиш Ctrl-Alt-Del.
Изменение режима блокировки вступает в действие немедленно.
astra-sudo-control
Включает требование ввода пароля при использовании sudo. По умолчанию не требуется вводить пароль при вызове sudo. Это повышает удобство, но в некоторых случаях может быть небезопасно. Состояние "включено" означает, что будет требоваться пароль, "выключено" — не будет требоваться. Изменение режима блокировки вступает в действие немедленно.
astra-sumac-lock
Блокирует работу утилит sumac и fly-sumac. Если эта функция включена, даже те пользователи, у которых есть привилегия PARSEC_CAP_SUMAC, не смогут использовать команду sumac. Для этого устанавливаются права доступа 000 на исполняемый файл sumac и библиотеку libsumacrunner.so. Изменение режима блокировки вступает в действие немедленно.
astra-swapwiper-control
Включает функцию очистки разделов подкачки при завершении работы ОС. Для этого вносятся изменения в конфигурационный файл /etc/parsec/swap_wiper.conf. Изменение режима блокировки вступает в действие немедленно.
astra-sysrq-lock
Отключает функции системы, доступные при нажатии клавиши SysRq, т.к. их использование пользователем может быть небезопасно. Для этого изменяется значение параметра kernel.sysrq. Значение параметра сохраняется в файл /etc/sysctl.d/999-astra.conf.
По умолчанию эта функция безопасности включена, т.е. клавиша SysRq не работает.
Изменение режима блокировки вступает в действие немедленно.
astra-ufw-control
Включает межсетевой экран ufw. Если уже включен firewalld (другой межсетевой экран), то ufw не будет включен, т.к. при одновременном включении они вызывают конфликты.
Изменение режима работы вступает в действие немедленно.
astra-ulimits-control
Включает ограничения на использование пользователями некоторых ресурсов системы, чтобы предотвратить нарушение доступности системы в результате исчерпания ресурсов. Настройка ограничений производится путем внесения изменений в файл /etc/security/limits.conf. На пользователей, уже вошедших в систему, изменение режима не влияет и вступает в действие после следующего входа пользователя.
Аналог графической утилиты "Монитор безопасности". При вызове без параметров отображает компактную сводку о состоянии функций безопасности.
Дополнительные параметры команды:
- list — выводит машиночитаемый список всех контролируемых функций безопасности;
- status — выводит сводку о состоянии функций безопасности (так же, как и при вызове без параметров);
- status N — выводит состояние функции безопасности по номеру N, где N — это id функции функции безопасности, получаемое из вывода опции list;
- switches — выводит в машиночитаемом виде список переключателей безопасности, предназначенный для отображения в графических утилитах администрирования.
Для каждой функции возможны следующиесостояния:
- ВКЛЮЧЕНО/ВЫКЛЮЧЕНО
- ВКЛЮЧАЕТСЯ/ВЫКЛЮЧАЕТСЯ
- ЧАСТИЧНО
Состояние "ВКЛЮЧАЕТСЯ" обозначает, что функция находится в процессе включения или будет включена после перезагрузки, но в настоящий момент еще не активна. Состояние "ВЫКЛЮЧАЕТСЯ" имеет обратный смысл. Например, после отключения блокировки ptrace она переходит в состояние "ВЫКЛЮЧАЕТСЯ", т.к. она не может быть выключена в процессе работы системы, но отключится после перезагрузки.
Состояние "ЧАСТИЧНО" обозначает, что функция включена, но не все параметры, контролируемые этой функцией, соответствуют заданным по умолчанию. Например, состояние "ЧАСТИЧНО" для функции "МКЦ файловой системы" обозначает, что функция фключена, но метки целостности на некоторых файловых объектах не соответствуют заданной системной конфигурации (см. ниже).
Включенное состояние функций безопасности означает повышенную безопасность, т.е. состояние, когда некий потенциально небезопасный функционал ОС запрещен.
"норма" — метка целостности файлового объекта соответствует заданной;
Механизм контроля целостности исполняемых файлов и разделяемых библиотек формата ELF при запуске программы на выполнение реализован в модуле ядра ОС digsig_verif, который является не выгружаемым модулем ядра Linux и может функционировать в одном из следующих режимов:
Механизм контроля целостности файлов при их открытии на основе ЭЦП в расширенных атрибутах файловой системы также реализован в модуле ядра ОС digsig_verif и может функционировать в одном из следующих режимов:
Настройка режима функционирования модуля digsig_verif осуществляется посредством графического инструмента fly-admin-smc (<<Панель управления — Безопасность — Политика безопасности — Замкнутая программная среда>>) или путем редактирования конфигурационного файла /etc/digsig/digsig_initramfs.conf. Описание использования графического инструмента приведено в электронной справке.
Редактирование конфигурационного файла /etc/digsig/digsig_initramfs.conf осуществляется следующим образом:
для использования отладочного режима для тестирования СПО необходимо установить для параметра DIGSIG_ELF_MODE значение 0:
для использования режима для проверки ЭЦП в СПО необходимо установить для параметра DIGSIG_ELF_MODE значение 2:
для использования штатного режима функционирования необходимо установить для параметра DIGSIG_ELF_MODE значение 1:
В модуль digsig_verify встроены открытые ключи АО "НПО РусБИТех", которые используются:
- для проверки подписи исполняемых файлов;
- для проверки подписи открываемых файлов в расширенных атрибутах;
- для проверки подписи на дополнительных ключах, загружаемых из каталога /etc/digsig/keys.
В каждый момент времени модуль использует два набора ключей:
- основной набор (изначально три встроенных ключа АО "НПО РусБИТех") — для проверки любых подписей;
- дополнительный набор (изначально пустой) — только для проверки подписи открываемых файлов в расширенных атрибутах.
Если дополнительный набор не содержит ключа, который использовался для подписи файла в расширенных атрибутах, модуль ищет подходящий ключ в основном наборе.
Каталог /etc/digsig/keys содержит открытые ключи в формате gnupg —export, которыми расширяется основной набор ключей при загрузке системы. Каждый ключ, использованный для подписывания СПО, необходимо скопировать в каталог /etc/digsig/keys/, например, с использованием команды:
В каталоге /etc/digsig/keys/ может располагаться иерархическая структура ключей. Каждый ключ должен быть подписан уже загруженным ключом основного набора в момент его добавления в основной набор. Иерархия подкаталогов /etc/digsig/keys обрабатывается сверху вниз таким образом, что:
- файлы ключей в /etc/digsig/keys должны быть подписаны встроенными в модуль digsig_verify ключами АО "НПО РусБИТех";
- файлы ключей в /etc/digsig/keys/subdirectory могут быть подписаны и встроенными ключами АО "НПО РусБИТех", и ключами из /etc/digsig/keys;
- в целом, каждый ключ из подкаталога внутри /etc/digsig/keys должен быть подписан либо ключом из вышележащего каталога, либо встроенным ключом АО "НПО РусБИТех".
Для проверки использования дополнительных ключей для контроля целостности исполняемых файлов и разделяемых библиотек формата ELF (до перезагрузки ОС) можно от имени учетной записи
администратора через механизм sudo выполнить команды:
cat /etc/digsig/key_for_signing.gpg > /sys/digsig/keys
cat /etc/digsig/keys/key1.gpg >> /sys/digsig/keys
cat /etc/digsig/keys/key2.gpg >> /sys/digsig/keys
cat /etc/digsig/keys/key1/key1-1.gpg >> /sys/digsig/keys
cat /etc/digsig/keys/key1/key1-2.gpg >> /sys/digsig/keys
cat /etc/digsig/keys/key2/key2-1.gpg >> /sys/digsig/keys
cat /etc/digsig/keys/key2/key2-2.gpg >> /sys/digsig/keys При проверке ЭЦП в расширенных атрибутах файловой системы установка для параметра DIGSIG_XATTR_MODE значения 1 запрещает открытие поставленных на контроль файлов с неверной ЭЦП или без ЭЦП.
Настройка режима функционирования механизма контроля целостности файлов при их открытии на основе ЭЦП в расширенных атрибутах файловой системы осуществляется с помощью графического инструмента fly-admin-smc (<<Панель управления — Безопасность — Политика безопасности — Замкнутая программная среда>>) или путем редактирования конфигурационного файла /etc/digsig/digsig_initramfs.conf.
Редактирование конфигурационного файла /etc/digsig/digsig_initramfs.conf осуществляется следующим образом:
для включения проверки подписей в режиме запрета открытия поставленных на контроль файлов с неверной ЭЦП или без ЭЦП в расширенных атрибутах файловой системы необходимо установить для параметра |DIGSIG_XATTR_MODE значение 1:
для включения проверки подписей в режиме вывода предупреждений об открытии поставленных на контроль файлов с неверной ЭЦП или без ЭЦП в расширенных атрибутах файловой системы необходимо установить для параметра DIGSIG_XATTR_MODE значение 2:
для игнорирования дополнительных ключей, используемых только при проверке ЭЦП в расширенных атрибутах файловой, необходимо установить для параметра DIGSIG_IGNORE_XATTR_KEYS значение 1:
для настройки шаблонов имен, используемых при проверке ЭЦП в расширенных атрибутах ФС, необходимо в файле /etc/digsig/xattr_control задать их список. Каждая строка задает свой шаблон в виде маски полного пути. Например, следующий шаблон определяет, что будет проверяться ЭЦП всех файлов в каталоге /bin, имя которых начинается на lo (т.е. имён, соотвествующих регулярному выражению (шаблону) /bin/lo*) :
Каталог /etc/digsig/xattr_keys содержит открытые ключи в формате gnupg —export, которыми расширяется дополнительный набор ключей модуля (изначально пустой набор, используемый только для проверки подписи в расширенных атрибутах файла). Подписи на ключах дополнительного набора не проверяются.
Каждый дополнительный ключ, использованный для подписывания файлов в расширенных атрибутах, необходимо скопировать в каталог /etc/digsig/xattr_keys/, например, с
использованием команды:
В каталоге /etc/digsig/xattr_keys/ может располагаться иерархическая структура дополнительных ключей для контроля целостности файлов.
В указанной структуре одни дополнительные ключи могут быть подписаны на других дополнительных ключах.
При этом дополнительные ключи должны располагаться в подкаталогах таким образом, чтобы при их загрузке не нарушалась цепочка проверки подписей:
/etc/digsig/xattr_keys/key1.gpg — публичный ключ 1
/etc/digsig/xattr_keys/key2.gpg — публичный ключ 2
/etc/digsig/xattr_keys/key1/key1-1.gpg — публичный ключ, подписанный на ключе 1
/etc/digsig/xattr_keys/key1/key1-2.gpg — публичный ключ, подписанный на ключе 1
/etc/digsig/xattr_keys/key2/key2-1.gpg — публичный ключ, подписанный на ключе 2
/etc/digsig/xattr_keys/key2/key2-2.gpg — публичный ключ, подписанный на ключе 2
Для проверки использования дополнительных ключей для контроля целостности файлов (до перезагрузки ОС) можно от имени учетной записи администратора через механизм sudo выполнить команды:
cat /etc/digsig/xattr_keys/key1.gpg >> /sys/digsig/xattr_keys
cat /etc/digsig/xattr_keys/key2.gpg >> /sys/digsig/xattr_keys
cat /etc/digsig/xattr_keys/key1/key1-1.gpg >> /sys/digsig/xattr_keys
cat /etc/digsig/xattr_keys/key1/key1-2.gpg >> /sys/digsig/xattr_keys
cat /etc/digsig/xattr_keys/key2/key2-1.gpg >> /sys/digsig/xattr_keys
cat /etc/digsig/xattr_keys/key2/key2-2.gpg >> /sys/digsig/xattr_keys
Управление модулем digsig_verif осуществляется через интерфейс sysfs с использованием файлов:
- /sys/digsig/elf_mode — просмотр и переключение режима работы при проверке ЭЦП исполняемых файлов и разделяемых библиотек формата ELF;
- /sys/digsig/xattr_mode — просмотр и переключение режима работы при проверке ЭЦП в расширенных атрибутах файловой системы;
- /sys/digsig/keys — файл загрузки дополнительных ключей для проверки ЭЦП исполняемых файлов формата ELF и ЭЦП в расширенных атрибутах ФС;
- /sys/digsig/ignore_gost2001 — отключение проверки ЭЦП по ГОСТ
Проверка режимов работы выполняется командами:
Для отключения проверки ЭЦП по ГОСТ
34.10-2001 необходимо в конфигурационном файле /etc/digsig/digsig_initramfs.conf установить следующее значение параметра:
После внесения изменений в конфигурационный файл /etc/digsig/digsig_initramfs.conf и для загрузки модулем digsig_verif ключей после их размещения его в каталогах /etc/digsig/keys/ и /etc/digsig/xattr_keys/
необходимо от имени учетной записи администратора через механизм \verb|sudo| выполнить команду:
В модуле ядра digsig_verif реализован механизм, позволяющий использовать несколько ключей при подписывании файлов формата ELF.
Порядок использования ключей для digsig_verif:
- дополнительные ключи записываются в /sys/digsig/keys или /sys/digsig/xattr_keys’ в иерархической последовательности цепочек подписей;
- все дополнительные ключи должны быть подписаны главным ключом или другим дополнительным ключом, подпись которого может быть проверена (за исключением первого ключа в каталоге /sys/digsig/xattr_keys).
Для создания дополнительных ключей используется GNU Privacy Guard.
Модифицированный GnuPG выводит ГОСТ
34.11-94 в списке доступных алгоритмов.
Для получения списка доступных алгоритмов необходимо выполнить команду:
/.gnupg
Поддерживаются следующие алгоритмы:
С открытым ключом: RSA, RSA-E, RSA-S, ELG-E, DSA,
GOST_R 34.10-2001,GOST_R 34.10-2012
Симметричные: 3DES, CAST5, BLOWFISH,
AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Хэш-функции: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512,
SHA224, GOST_R34.11-2012, GOST_R34.11-94
Алгоритмы сжатия: Без сжатия, ZIP, ZLIB,
BZIP2
Далее приведен пример создания дополнительного ключа и его использования для подписывания СПО.
Сначала создается ключевая пара GOST R 34.10-2001, которая сохраняется в каталоге
/.gnupg.
Для создания ключевой пары необходимо выполнить приведенную далее команду с последующим выбором в меню gpg алгоритма ГОСТ
gpg: создан каталог `/home/keys/.gnupg’
gpg: создан новый файл настоек `/home/keys/.gnupg/gpg.conf’
gpg: ВНИМАНИЕ: параметры в `/home/keys/.gnupg/gpg.conf’ еще не активны при этом запуске
gpg: создана таблица ключей `/home/keys/.gnupg/secring.gpg’
gpg: создана таблица ключей `/home/keys/.gnupg/pubring.gpg’
Выберите тип ключа:
(1) RSA и RSA (по умолчанию)
(2) DSA и Elgamal
(3) DSA (только для подписи)
(4) RSA (только для подписи)
(10) GOST R 34.10-2001 (только для подписи) устаревший
(12) GOST R 34.10-2012 (только для подписи)
Ваш выбор? 12
GOST keypair will have 256 bits.
Выборите срок действия ключа.
0 = без ограничения срока действия
<n> = срок действия — n дней
<n>w = срок действия — n недель
<n>m = срок действия — n месяцев
<n>y = срок действия — n лет
Срок действия ключа? (0) 0
Срок действия ключа не ограничен
Все верно? (y/N) y
Ваше настоящее имя: Test GOST R 34.10-2012 Secondary Key
Адрес электронной почты: test@gost.secondary.key
Комментарий:
Вы выбрали следующий ID пользователя:
"Test GOST R 34.10-2001 Secondary Key <test@gost.secondary.key>"
Сменить (N)Имя, (C)Комментарий, (E)адрес или (O)Принять/(Q)Выход? O
Для защиты закрытого ключа необходим пароль.
Введите пароль: ПАРОЛЬ
Повторите пароль: ПАРОЛЬ
Экспорт ключа в файл осуществляется командой:
gpg —export "Test GOST R 34.10-2012 Secondary Key <test@gost.secondary.key>" > /tmp/secondary_gost_key.gpg
Ключ пользователя может быть заверен с использованием команд:
gpg —import /tmp/secondary_gost_key.gpg
gpg —sign-key "Test GOST R 34.10-2012 Secondary Key <test@gost.secondary.key>"
gpg —export "Test GOST R 34.10-2001 Secondary Key <test@gost.secondary.key>" > /tmp/secondary_gost_key_signed.gpg
Пользователь подписывает на данном ключе некоторый файл формата ELF с использованием утилиты bsign (по умолчанию подпись внедряется в том числе и в расширенные атрибуты файла):
Пользователь подписывает утилитой bsign на данном ключе произвольный файл с внедрением подписи только в расширенные атрибуты:
$ bsign —sign —xattr test_elf
Дополнительная информация доступна в справке по утилите bsign;
Для проверки правильности ЭЦП файла формата ELF используется утилита bsign:
Дополнительный ключ пользователя, подписанный на главном ключе, копируется в каталог /etc/digsig/.
Astra Linux не плохая альтернатива от отечественных разработчиков. Если вам необходимо заменить Windows, на неё стоит обязательно обратить внимание. Сам пользовался, ставил в качестве рабочих станции. В обоих случаях показала себя не плохо. Поэтому решил написать несколько статей, небольших инструкций так сказать, по работе с данной ОС. Сегодня рассмотрим политику безопасности.
По умолчанию в Astra Linux полита настроена не достаточно строго. Например, пароль должен содержать не менее 8 символов, причем можно использовать только цифры. Также только после 8 неуспешных попыток ввода пароля учетная запись заблокируется. В наше время политика должна быть настроена намного строже.
Системный администратор помни безопасность превыше всего!
Как настроить политику учетных записей
Админ ни когда не используй простые пароли тиап Qwe123, Qaz123 и тому подобные.
Пароли должны обновляться хотя бы один раз в месяц.
На следующей вкладке можно создать шаблоны устаревания.
Вводим имя шаблона и заполняем остальные поля.
Большинство системных администраторов не уделяют особое внимания политикам безопасности. Особенно это касается начинающих, которые делают всем одинаковые пароли Qwe123 без ограничения срока. Потом плачут, как так взломали пароль, зашифровали диск украли важную инфу и требуют выкуп.
Всего этого можно очень легко избежать если соблюдать минимальные требования безопасности, в 2020 году это очень актуальна. Так как очень много злоумышленников появилось. Которые без особого труда подберут пароль.
Системный администратор помни пароли должны быть сложными, желательно быть сгенерированными автоматически и меняться раз в месяц!
Добрый день, установил AstraLinux SE 1.5, но не могу на пользователя user(которого создал с установкой системы) выставить высокий уровень целостности. В "управлении политикой безопасности" во вкладке МРД стоит высокий уровень целостности, перезахожу под пользователем в систему, выбираю "высокий", и на рабочий стол не заходит, опять нахожусь в окне авторизации. Команда pdp-id тоже говорит, что я на низком уровне целостности, дал pdpl-user -i 63 user, вррде в консоли написал что высокий, но опять попытался зайти после перезагрузки, и не входит . что делать?
Никита, а зачем вам высокий уровень целостности в 1.5? Там без него можно администрировать систему
Шурик, чтобы понять и убедится в том, что есть разделение по контролю целостности, ведь администрирование сюдя по руководству по адм. должно происходить под высоким уровнем привилегий. Так же узнать, возможно была ошибка в процессе установки ОС
Никита, честно, впервые слышу для 1.5. Хотя и не знаю много, но, вроде как, обязательное условие администрирования под уровнем 63 появилось в 1.6
Роберт, нужно уточнить, вопрос как. щас будем искать . спасибо, но я думаю дело в этом, что не установлено обновление
установил Орел, пошел в Панель управления-Сеть, хотел создать соединение Ethernet, нажал плюс, открывается окно, но во всех вкладках поля не активные, кнопка Сохранить не активная, что за лабуда? очень давно ставил Орел, не помню деталей, но там все настроил на раз-два, в чем проблема?
Евгений, посмотрите состояния NetworkManager.service. Должно быть:
Как связать по локалке Смоленск 1.6 и Виндоус
Что бы у них была одна рабочая группа и работали локальные папки
Пытаюсь перенастроить дефолтные настройки рабочего стола в /usr/share/fly-wm/default.themerc. Хочу отключить переключатель рабочих столов, убрать лого, включить NumLock и отключить блокировку экрана для всех будущих юзеров. Получилось все, кроме двух последних пунктов. Прописал так:
Куда копать дальше?
купился на то что есть возможность переключаться на интерфейсы заточенные для планшета и мобилы, решил попробовать на своем трасформере. запустил livecd орел — на сайте ссылки на ливы не нашел (пришлось ссылку на скачивание обрезать и по фс репозитория лазить))), первый поверхносный взгляд не порадовал — при повороте экрана сенсор не поворачивается, размеры окон управления не оптимизированы под дефолтное разрешение экрана, смена разрешения экрана ни к чему не приводит (как окна не влазили так и не влазят, вообще не понятно сменилось разрешение или осталось тем же), не смог запустить менеджер пакетов (это я криворукий или в лив версии он выпилен?). короче как то после такого лива нет никакого желания экспериментировать с установкой этой ос. наверно подожду пока ливовый образ сделают более дружественным.
Русский бронированный Debian. Как устроена новая модель управления доступом в Astra Linux SE
Россия, как известно, родина слонов. А также ракетных комплексов, подводных лодок, танков и, как оказалось, не менее бронированных операционных систем. Если ты рубишь в ИБ и живешь в России, то это как раз тот вид вооружений, которым ты можешь интересоваться и даже гордиться. Astra Linux SE — одна из таких ОС. Наш автор Евгений Лебеденко — специалист по таким системам, так что приготовься взглянуть на безопасность в Linux с самой серьезной стороны!
Операционные системы сегодня — это не просто набор служебных функций, который позволяет компьютеру работать. Операционки стали играть огромную роль в мире потребительской электроники: Microsoft приспосабливает Windows для всех возможных устройств, Apple экспериментирует с интерфейсом мобильных и десктопных систем, Google развивает Android и одновременно превращает в операционную систему Chrome.
В корпоративной среде прогресс ОС тоже идет по полной: программно-конфигурируемые сети (SDN), виртуальные серверы, глобальные и частные облака. Здесь на первый план выходит не юзабилити, а защищенность и соответствие жестким требованиям к безопасности.
Есть и еще одна область, в которой защита превыше всего, — это ОС для государственных и военных нужд. Это еще один параллельный мир операционных систем — безумно консервативный, но и в нем существует прогресс. Причем не только за рубежом, но и у нас. Показательный пример — это дистрибутив Astra Linux SE.
Пять лет. Полет нормальный
Astra Linux — не единственный российский защищенный дистрибутив. Есть и другие, и все они успешно прошли проверку в органах сертификации и нашли свои рыночные ниши. Детище НПО «РусБИТех» — не исключение. Astra Linux SE с завидной регулярностью получает сертификаты соответствия в системах сертификации ФСТЭК, Министерства обороны и ФСБ. Действующие на настоящий момент версии имеют «срок годности» до 2018 года.
На основе Astra Linux развернуты и функционируют десятки информационных систем — как в государственных, так и в коммерческих структурах. Среди них, например, такие крупные, как защищенная платформа для государственной автоматизированной системы гособоронзаказа.
В составе дистрибутива Astra Linux SE есть все необходимое, чтобы развернуть защищенную инфраструктуру
Другие статьи в выпуске: 
Xakep #200. Тайная жизнь Windows 10
Astra Linux отметился и в популярной ныне теме импортозамещения. Вполне вероятно, что органы госвласти самого «санкционированного» российского региона — Республики Крым — будут использовать эту ОС в качестве базы для своей инфраструктуры ИТ. В общем, менеджерам «РусБИТех» есть чем гордиться. Но нас, конечно, больше всего интересуют не те достижения, что связаны с продажами и историями успеха.
Первый релиз Astra Linux вышел в конце 2009 года. С тех пор дистрибутив совершенствуется, следуя за основной веткой Debian, но при этом разработчики не забывают о главном — повышенной безопасности. Предприятие «РусБИТех» неплохо оснащено научными кадрами и при этом ведет активное сотрудничество с вузами и исследовательскими институтами, которые специализируются на информационной безопасности.
Черты, которые делают Astra Linux 1.4 уникальным, относятся как раз к этой теме. В фирменной подсистеме безопасности PARSEC используется формальная модель разграничения доступа. Она была разработана в Институте криптографии, связи и информатики Академии ФСБ России, а в оценке качества принял участие Центр верификации ОС Linux Института системного программирования РАН. Реализация этой модели в Astra Linux SE ведется поэтапно, и в версии 1.4 добавлена большая ее часть, но еще не последняя.
MAC в LSM. Далеко не фастфуд в управлении доступом
Прежде чем разбирать модель разграничения доступа в Astra Linux SE 1.4, следует вспомнить некоторые основы. Очевидно, что пользователям информационных систем требуется доступ к данным, а также к набору механизмов ОС, которые обеспечивают этот доступ, — например, к файловым системам и стекам сетевых протоколов.
Именно поэтому в моделях разграничения доступа пользователей именуют субъектами доступа. На самом деле доступ к данным пользователь получает не лично, а через программы, которые «переваривают» эти данные. Именно они и являются настоящими (действительным) субъектами доступа и представляют зарегистрированного в системе пользователя (номинального субъекта). Совокупность программ, которые получают доступ к данным в течение сеанса работы зарегистрированного пользователя, обычно именуется субъект-сессией.
Объектами доступа выступают, конечно же, не сами данные, а их носители, представленные логическими структурами: директориями, файлами, сетевыми сокетами и областями памяти, которые участвуют в межпроцессном взаимодействии.
Задача любой модели разграничения доступа — определить, разрешить (allow) доступ к тем или иным объектам для тех или иных субъектов (субъект-сессий) или отказать (deny) в нем в соответствии с правилами. Если коротко, любая модель разграничения доступа задает некоторые отношения между субъектами и объектами доступа.
Базовая (как говорится, «из коробки») модель безопасности в GNU/Linux — это DAC, дискреционная модель доступа (discretionary access control). Она представляет собой комбинацию произвольного управления доступом (субъект-субъектная модель) и доступа на основе списков (ACL — Access Control Lists).
Субъект-субъектная модель подразумевает, что каждому объекту сопоставляется один субъект — владелец объекта. Он наделен правом давать или отнимать доступ к этому объекту другим субъектам. ACL — это таблица, объединяющая субъекты и объекты доступа при помощи перечисления прав, которыми субъект обладает в отношении объекта.
В общем виде модель DAC в GNU/Linux соответствует «виртуальному» стандарту POSIX ACL (настоящая стандартизация POSIX.1e и POSIX.2с была свернута в силу безбрежности стандартизуемой предметной области) и для большинства случаев вполне подходит на роль «диспетчера доступа» субъектов к объектам.
В DAC-модели Astra Linux SE используется полновесная поддержка стандарта POSIX ACL
Однако защищенные операционные системы — это не «большинство случаев». Одно из важных требований, предъявляемых к ним органами сертификации, — это реализация принудительного контроля доступа, который устраняет определенный волюнтаризм модели DAC. Как и в некомпьютерном секретном делопроизводстве, модель принудительного управления доступом основана на сопоставлении меток конфиденциальности, присвоенных объектам доступа, с официальным разрешением (допуском, мандатом) субъекта. Именно это «официальное разрешение» (мандат) дало такой модели название MAC (Mandatory access control) — мандатное управление доступом.
В GNU/Linux попытки расширения DAC-модели безопасности MAC-моделью предпринимались с 2001 года. Именно тогда АНБ США показало первую версию SELinux с реализацией мандатного управления доступом на основе формальной модели MLS (Multilevel Security). Было предложено включить MLS в состав ядра версии 2.5. Благо сообщество разработчиков Linux такое решение отвергло. Наряду с SELinux похожие реализации MAC-модели разрабатывались в рамках проекта AppArmor и, позже, — в Smack, TOMOYO и других. С какой стати отдавать предпочтение какому-то одному из них?
Вместо жесткой интеграции MAC-модели в состав ядра было принято соломоново решение: использовать расширение модели безопасности GNU/Linux. Она продолжит базироваться на модели DAC, но с использованием особых модулей ядра. В них можно реализовать какой угодно вариант модели управления доступом. Это решение было претворено в жизнь в виде фреймворка LSM (Linux Security Modules), который официально включили в ядро Linux 2.6.
Идея LSM проста. На ключевые с точки зрения управления доступом функции ядра навешивается совокупность «крючков» — хуков (hooks). Они представляют собой интерфейсы подключения обработчиков из модуля LSM, которые вызываются в том случае, если нужен контроль доступа. То есть фреймворк LSM предоставляет разработчику модуля LSM возможность перехвата управления в ходе выполнения тех участков кода ядра, которые отвечают за реализацию доступа субъектов к объектам.
Прелесть такого подхода заключается в том, что внутри модуля LSM можно реализовать любую модель управления доступом — как общего назначения, так и с учетом специфических особенностей эксплуатации системы. Естественно, эффективность подхода LSM напрямую зависит от широты охвата хуками функций ядра Linux. Но с этим, судя по всему, проблем нет. С момента включения LSM в ядро 2.6 по настоящее время было реализовано около двухсот хуков, и их внедрение ведется параллельно с появлением новых функций ядра.
Фреймворк LSM не заменяет модель DAC — она остается «первой линией обороны». Обработка хуков LSM начинается только после успешного прохождения контроля доступа по линии DAC. Такая двухъярусность позволяет не перегружать функциями безопасности те системы, где это не нужно. Там можно попросту не использовать LSM.
Безопасность SELinux базируется как раз на модулях LSM, равно как все остальные рассмотренные выше проекты, которые реализуют мандатное управление доступом. Подсистема безопасности PARSEC, функционирующая в составе Astra Linux SE, — это тоже модуль LSM. И даже не один.
В Astra Linux SE подсистема безопасности PARSEC базируется на фреймворке LSM
XPARSEC
Подсистема безопасности PARSEC в Astra Linux SE 1.4 содержит модуль XPARSEC, благодаря которому сервер X.Org получает возможность определять привилегии клиента X.Org (программы с графическим интерфейсом) и передавать их с использованием модифицированного X-протокола менеджеру окон Fly-wm. Тот выполняет привилегированные операции во время запуска клиента X.Org с различными мандатными контекстами. При этом на рабочем столе Fly отображается:
- мандатный контекст пользовательской сессии в системном лотке (область tray);
- мандатный уровень каждого окна;
- мандатный уровень всех приложений, размещенных на рабочем столе Fly;
- уровень доверенности окна для локально и удаленно запущенных приложений (цвет рамки окна приложения).
В качестве DE в Astra Linux используется Fly — «брат по коду» KDE 4. В отличие от KDE, Fly — защищенная рабочая среда
Контроль доступа, контроль целостности и роли
Поскольку Astra Linux вовсю используется в разных проектах, связанных с обработкой информации различных уровней конфиденциальности, у разработчиков уже есть статистика, по которой можно судить о корректности реализации модели управления доступом. Не менее важны исследовательские работы, в которых формировались модели нарушителей в рамках известных уязвимостей информационной безопасности CVE (Common Vulnerabilities and Exposures).
Проверке подверглись известные «проблемы» модели Белла — Лападулы. К примеру, деклассификация — когда пользователь с высоким уровнем конфиденциальности случайно или намеренно помещает данные из объекта с соответствующей мандатной меткой в объект с меткой более низкого уровня. Или нарушение логики доступа к данным при обработке потока информации в распределенной среде.
Моделировалась и проблема компрометации субъекта доступа, в ходе которой повышается уровень его привилегий (включая получение привилегий PARSEC). В результате можно получить возможность управлять доступом к защищаемой информации.
Очевидное решение таких проблем — это модификация формальной модели управления доступом. В случае Linux это делается добавлением модулей LSM, которые реализуют систему PARSEC. Ее основой стала мандатная сущностно-ролевая ДП-модель. Разработка ведется в рамках научной школы в Институте криптографии, связи и информатики Академии ФСБ России.
Подсистема безопасности PARSEC — не только LSM-модули, в которых реализована та или иная модель управления доступом, но и «обвязка»: собственная файловая система parsecfs, конфигурационные файлы, демоны и утилиты
В общем случае эта модель относится к классу ДП-моделей, то есть моделей управления доступом (Д) и информационными потоками (П), в которых учитывается не только единичный акт доступа к данным, но и направления распространения потоков информации при выполнении операций над данными.
Кардинальное отличие мандатной сущностно-ролевой ДП-модели от «классики» MAC — это объединение мандатного и ролевого управления доступом. При этом традиционный подход (уровни конфиденциальности, категории безопасности) мандатной модели в ней усиливается применением мандатного же контроля целостности (MIC, Mandatory Integrity Control) — механизма, который нашел широкое применение в семействе операционных систем Windows, начиная с релизов Vista и Server 2008.
Мандатная сущностно-ролевая модель управления доступом в версии 1.4 Astra Linux SE относится к широкому классу ДП-моделей 
Приоритет в мандатной сущностно-ролевой ДП-модели — это MAC-модель, усиленная ролевой моделью и моделью управления целостностью
Фактически управление целостностью (integrity) правильнее называть управлением уровнем доверия. К традиционной проверке целостности данных (например, на основе подсчета их контрольных сумм) механизм MIC отношения не имеет. Назначаемые объектам и субъектам доступа уровни доверия дополняют традиционную модель управления доступом и гарантируют, что субъекты с низким уровнем целостности (IL — Integrity Level) не могут влиять на объекты с более высоким уровнем целостности.
Реализация мандатной сущностно-ролевой модели в Astra Linux SE 1.4 поддерживает наличие двух уровней целостности: высокий (hi) и низкий (low). Этого достаточно для разделения субъектов и объектов доступа на доверенные и недоверенные. При этом переменная, которая определяет значение IL, может принимать одно из 255 значений. Это означает, что в последующих реализациях модели может появиться более чем один уровень целостности. Подобный подход используется в модели MIC операционных систем Windows, поддерживающей пять (от untrusted до system) значений IL.
Еще одна важная особенность мандатной сущностно-ролевой модели — это учет иерархичности организации как ряда объектов доступа, так и функций (ролей), выполняемых субъектами. Такой учет позволил отнести и подобные объекты, и роли субъектов доступа к единой категории «сущность». В рамках этой категории могут формироваться отношения иерархии. Например, каталог может считаться сущностью-контейнером. Размещенные в нем объекты — файлы и подкаталоги — будут для него дочерними сущностями.
Аналогичным образом можно рассматривать и роли субъектов. Корневыми будут роли администратора (суперпользователя) и индивидуального пользователя. На самом деле иерархии сущностей-ролей — это вложенные друг в друга функции субъекта, вся совокупность которых в сумме и определяет корневые роли.
Что дает учет иерархии сущностей? Например, совместно с моделями MAC и MIC он позволяет определять правила размещения обычных объектов-сущностей с разными мандатными метками и уровнями IL в сущности-контейнере с определенными мандатной меткой и уровнем IL. Именно эта возможность и используется в текущей реализации сущностно-ролевой модели путем добавления к DAC-, MAC- и MIC-атрибутам директорий (напомним, что это — сущности-контейнеры) дополнительных атрибутов ccnr и ccnri. Они ограничивают возможность размещения в контейнерах объектов с мандатными метками и уровнями целостности, которые превышают таковые у самой директории.
Чтобы создать дочерний объект в отмеченных подобным образом директориях, даже с мандатными метками и уровнями IL ниже, чем у «родителя», субъект должен иметь соответствующие PARSEC-привилегии. Равно как и для установки ненулевого значения указанных атрибутов. При этом установка этих атрибутов не мешает просмотру объектов внутри директории.
Кроме ограничивающих атрибутов, для любых сущностей (не только сущностей-контейнеров) возможна установка атрибута ehole. Он позволяет игнорировать мандатные метки целостности при выполнении операций записи в них. Такой атрибут необходим для работы с объектами общего пользования — к примеру, директорией tmp.
Правила разграничения доступа в мандатной сущностно-ролевой ДП-модели учитывают иерархическую организацию ряда сущностей-объектов доступа 
Скрипт инициализации правил разграничения доступа для ключевых директорий корневой файловой системы Astra Linux SE
Реализовав в LSM-модулях PARSEC мандатную сущностно-ролевую ДП-модель, разработчики не забыли и о средствах ее администрирования. Ведь набор утилит мандатного управления доступом в Astra Linux SE 1.3 был ориентирован на традиционную MAC-модель и не учитывал рассмотренные выше новшества.
В версии 1.4 появилась совокупность утилит pdp-, которые поддерживают просмотр и модификацию как традиционных MAC-атрибутов (уровни и категории), так и MIC-атрибута (уровни целостности) и дополнительных атрибутов (ccnr, ccnri, ehole). Впрочем, утилиты из предыдущей версии никуда пока не делись и применяются, чтобы облегчить администраторам уже функционирующих информационных систем миграцию субъектов и объектов доступа на новую модель.
В настройках среды окружения нового варианта подсистемы PARSEC первую скрипку играют новые pdp-утилиты
Распространение абстракции «сущность» не только на объекты доступа, но и на роли, реализуемые субъектами, позволяет применить подобный подход и к иерархии «роль-контейнер» — «дочерняя роль». Правда, в реализации модели для Astra Linux SE 1.4 gjkysq переход к ролевому управлению не выполнен (сущности-контейнеры «административная роль» и «индивидуальная роль» еще пусты).
Сейчас вовсю идет разработка версии 1.5, где в полном объеме будет реализована главная особенность мандатной сущностно-ролевой модели — приоритетное выполнение требований мандатного управления доступом при реализации ролевого управления в сочетании с мандатным контролем целостности.
Следует еще задать вот какой вопрос: корректна ли новая, достаточно сложная и для понимания, и для реализации модель управления доступом? Не несет ли она на логическом уровне возможностей для несанкционированного доступа? Достоинство Astra Linux SE здесь в том, что корректность его решений проверяет научное сообщество. В частности, в процессе занят Центр верификации ОС Linux Института системного программирования РАН — там разрабатываются тесты и технологии тестирования как модулей ядра Linux, так и в целом инфраструктуры LSB (Linux System Base).
Так, Центром в рамках проекта Linux Deductive Verification на основе методологии дедуктивной верификации последовательных программ был разработан набор свободно распространяемых инструментов верификации — Astraver Toolset 1.0. Они помогают убедиться в корректности реализации LSM-модулей подсистемы PARSEC, которые поддерживают новую мандатную сущностно-ролевую модель. Они же помогут тестировать и будущие версии Astra Linux SE.
В tray-области рабочего стола Fly-wm для пользователя отображается его уровень конфиденциальности и категории безопасности 
Файловый менеджер fly-fm отмечает цветовыми метками документы с разными MAC-атрибутами и цветной рамкой уровень доверенности окна приложения
Выводы
К отечественным системным программным разработкам, особенно если они ведутся на основе опенсорсных проектов, зачастую относятся с изрядной долей снисхождения. Мол, сложно ли? Любой сможет взять отовсюду понемногу и сделать нечто, выдаваемое за свое. Возможно, иногда так и есть. Но только не в области операционных систем специального назначения. Их разработка скрупулезна, а сертификация проходит не для галочки. Именно такой подход продемонстрирован в Astra Linux SE 1.4, и именно его можно ожидать в последующих версиях этой операционной системы специального назначения.
Блокировка интерпретаторов и блокировка консоли в Astra Linux / Запрет установки бита исполнения
- Xuất bản 11 Th07, 2020
- Нужна для того, чтобы запретить особо умным программистам создавать, например, на питоне текстовые файлы и подавать их на вход интерпретатору, тем самым реализуя какой-то функционал, который в системе запрещен.
1. HARDENED ядро. Запрет установки бита исполнения — vnclip.net/video/fNja489i3H8/video.html
2. Мандатный контроль целостности — vnclip.net/video/A5wd_Dg9rNQ/video.html
3. Регламентный контроль целостности — vnclip.net/video/StzNZTLj2d0/video.html
4. ЗПС в Astra Linux 1.6 — vnclip.net/video/2Np0zZe8PBE/video.html
5. Очистка памяти — vnclip.net/video/QchBwEyrxec/video.html
6. Блокировка интерпретаторов и блокировка консоли — vnclip.net/video/u08NM7igUeI/video.html
7. Графический КИОСК — vnclip.net/video/X1rDq19OQr4/video.html 
Khoa học và Công nghệ