Замкнутая программная среда

Инструменты из состава ОС предоставляют возможность создавать замкнутую программную среду (ЗПС). ЗПС обеспечивает динамический контроль неизменности (целостности) и подлинности файлов и предназначена для:

• выявления фактов несанкционированного изменения исполняемых и других файлов (в т. ч. относящихся к КСЗ);
• предотвращения загрузки и исполнения измененных исполняемых файлов, а также открытия измененных неисполняемых файлов.

Контроль целостности файлов реализован в невыгружаемом модуле ядра ОС digsig_verif и производится на основе проверки цифровых подписей (далее - подписи).  Для создания и проверки подписей используются алгоритмы ГОСТ Р 34.10-2012 (256 бит) и ГОСТ Р 34.10-2001 (256 бит), также для совместимости сохранено использование ГОСТ Р 34.10-2001.  Модуль позволяет проверять исполняемые файлы и разделяемые библиотеки, подписанные:

• встраиваемой подписью;
• подписью в расширенных атрибутах;
• отсоединенной подписью.

В модуле digsig_verif реализованы механизмы, позволяющий при проверке подписей файлов использовать ключи из разных наборов и проверять несколько подписей. Для проверки используются ключи, входящие в состав ОС и из дополнительные ключи. Проверка подписи может производиться:

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

При включенной ЗПС, в зависимости от настроек, может блокироваться доступ ко всем неподписанным файлам и файлам, имеющим некорректные (несоответствующие, непроверяемые, отозванные) подписи. При этом по умолчанию не блокируется использование инструмента qemu-user-static, с помощью которого возможно запустить неподписанные исполняемые файлы, предназначенные для другой аппаратной архитектуры. Поэтому при включении ЗПС может потребоваться дополнительно включить блокировку интерпретаторов, блокирующую в том числе использование qemu-*-static.  Блокировка интерпретаторов не влияет на использование ядерного механизма binfmt, позволяющего запускать исполняемые файлы другой аппаратной платформы через qemu-*-static (по умолчанию binfmt отключен).

Основные понятия

• Ключ — для обеспечения работы ЗПС используются ключи формата GPG (см. RFC4880). Особенности этого формата:
  • В состав ключа GPG, помимо собственно ключа, входят сведения о его владельце, подписанные эти ключом (самоподписанные). Таким образом, при использовании ключей GPG понятия ключ и сертификат становятся фактическими синонимами.
  • При работе с ключами GPG используются асимметричные алгоритмы, то есть работа ведется с ключевой парой, состоящей из закрытого (приватного) ключа и открытого (публичного) ключа.
• Закрытый ключ — используются для формирования подписей (файлов и других ключей). Если речь идет о подписании чего-либо ключом, то подразумевается закрытый ключ. Закрытые ключи не подлежат передаче сторонним лицам.
• Открытый ключ — открытые ключи передаются сторонним лицам и могут использоваться ими для проверки подписей, сформированных парными закрытыми ключами. Если речь идет о проверке подписей или о экспорте (получении, хранении) ключей, то подразумевается открытый ключ.
• Исполняемый файл, обычно это файлы программ и библиотек:
  • файл в формате ELF (ELF-64);
  • файл в формате PE (формате библиотек dll).
  Не следует путать разрешение на исполнение файла в дискреционных правах доступа к этому файлу и формат этого файла. Разрешение на исполнение может быть установлено на любой файл. Файл в форматах ELF/PE может не иметь разрешения на исполнение. Наличие или отсутствие разрешения на исполнение не влияет на применимость подписей.
• Интерпретируемый файл — произвольный (обычно человекочитаемый) файл, исполнение которого осуществляется программой-интерпретатором, например, сценарий на языке bash или программа на языке Python.
• Неисполняемый файл — любой файл, не являющийся исполняемым, включая интерпретируемые файлы.
• Изготовитель — изготовитель Astra Linux, ООО "РусБИТех-Астра".
• Предустановленные ключи — ключи подписанные изготовителем и входящие в состав ОС.

Быстрые решения

Простое включение и выключение ЗПС для проверки исполняемых файлов

1. В процессе установки ОС включение ЗПС в части проверки подписей исполняемых файлов может быть выполнено выбором соответствующего пункта программы установки ОС.
2. После установки ОС быстрое включение и выключение ЗПС в части проверки подписей исполняемых файлов выполняется с помощью инструмента  astra-digsig-control (пакет astra-safepolicy). Инструмент обеспечивает включение и выключение проверки подписей исполняемых файлов. По умолчанию используется только проверка встраиваемых подписей предустановленными ключами, что обеспечивает:
   • контроль целостности ОС (подлежащие контролю файлы ОС подписаны ключом изготовителя);
   • возможность использования в ЗПС стороннего ПО, при условии, что файлы этого ПО подписаны ключами, заверенным ключами изготовителя.

Включение ЗПС:

Выключение ЗПС:

Для того, чтобы изменения вступили в силу — перезагрузить ОС.

Более подробно управление режимами проверки подписей описано далее.

Диагностика работы ЗПС

Информация о работе ЗПС записывается в журнал ядра. Просмотреть журнал ядра можно командой:

Просмотреть записи журнала ядра, относящиеся к ЗПС можно командой:

Пример вывода команды:

[    1.480907] DIGSIG: Initializing module ...
[    1.480916] DIGSIG: Have loaded main key with id=0xdb069ff5
[    1.480918] DIGSIG: Registered DigSig hooks
[    1.480918] DIGSIG: ignore_i_mode 0x0
[    1.557555] DIGSIG: Have loaded key with id=0x37db8024
[    1.562869] DIGSIG: Have loaded key with id=0x3675b6fa
[    2.575464] DIGSIG: Switching to (elf only) mode
[    2.575852] DIGSIG: Switching to DEBUG mode (elf)
[   51.275630] DIGSIG:[ERROR]  NOT ELF SIGNED: path=/home/astra/a.out uid=1000 gid=1000

Поиск подписанных файлов

Начиная с очередного обновления Astra Linux Special Edition 1.8 доступен пакет bsign-integrator, предоставляющий набор инструментов для работы с подписями файлов. После установки пакета для предварительной проверки того, какие файлы были подписаны с использованием отзываемого ключа, можно произвести поиск файлов по заданному сертификату и сохранить их список в файл:

Чтобы выполнить поиск файлов по списку ключей следует внести список в файл и использовать команду:

Описание инструмента командной строки bsign-integrator приведено далее.

Поиск ключей

Для удобства отладки используемые ключи рекомендуется загрузить в хранилище ключей (keyring). Сделать это можно командой: 

Например, для комплекта предустановленных ключей:

После того, как ключи загружены в таблицу ключей, информации о ключах можно получать по их идентификаторам с помощью опции --list-keys:

Поиск ключей по идентификаторам dmesg

Как указано ранее, информация о работе ЗПС сохраняется в журнале ядра и может быть получена командой:

Пример записи о ключе (о загрузке ключа в ядро) в журнале ядра:

[    1.549646] DIGSIG: Have loaded key with id=0x37db8024

Пример информации о ключе:

Поиск ключей по идентификаторам bsign

Подучить идентификатор ключа которым подписан файл можно с помощью опции -w команды bsign, например:

Пример вывода команды:

version: 1
id: bsign v1.0
hash: {GOST R34.11-2012} 99d9ceffdef23b6f515a857ee30a39bb0d796fff9c11e4c0dee1cc2a8a6d9f78
signature_size: 119
signature:
   88 75 04 00 23 0c 00 1d  16 21 04 80 66 e9 bd 22
   01 d9 78 3e 2d 84 2b d2  b6 68 9a 37 db 80 24 05
   02 67 3c 5a 96 00 0a 09  10 d2 b6 68 9a 37 db 80
   24 51 55 00 fe 39 ca 7d  9c 17 8c e4 3b 65 7a da
   74 6b bd 15 a1 4e 05 f2  db 0f 0b 1b 91 c0 96 39
   bd fd bb af 70 00 fe 24  17 02 29 97 46 00 36 02
   09 a3 0e 97 42 c2 c3 86  2d 40 dd 48 ce 29 00 8f
   8c c9 70 50 25 41 8b
signer: D2B6689A37DB8024
timestamp: 19 Nov 2024 12:29:58 (1732008598)
bsign: good hash found in '/usr/bin/cat'
bsign: no xattr hash found for '/usr/bin/cat'
bsign: no detached hash found for '/usr/bin/cat'

Идентификатор ключа которым подписан файл находится в строке signer:

signer: D2B6689A37DB8024

Информация о ключе:

Инструменты для работы с подписями

• ЗПС: инструмент bsign
• ЗПС: инструмент bsign-integrator
• Инструменты для выполнения подписания файлов DLL и проверки подписи
• Порядок создания подписей файлов для режима ЗПС

Детальная настройка ЗПС

Типы и применимость подписей

В ЗПС используются следующие типы подписей:

Особенности применения:

• подпись в расширенных атрибутах и отсоединенная подпись не нарушают структуру исходного файла, что может играть важную роль в системах, использующих периодический контроль целостности по эталонным значениям контрольных сумм;
• при проверке отсоединенной подписи модулем digsig_verif подписанными считаются все идентичные файлы независимо от их расположения в файловой системе;
• при проверке отсоединенной подписи инструментом bsign или bsign-integrator подпись ищется в файле с именем вида @путь@имя_файла.расширение.sign (например, @tmp@example@settings.conf.sign) в каталоге /etc/digsig/external_sig/;
• при подписании модулей ядра необходимо подписать все модули ядра, от которых зависит подписываемый модуль.

Ключи для проверки подписей

Для проверки подписей используются ключи в формате GPG. Ключи для проверки подписей перед проверкой должны быть загружены в ядро. Для загрузки ключей:

• Для постоянного применения ключей:
  • ключи должны быть размещены в подкаталогах каталога /etc/digsig (подробнее см. далее);
  • выполнена команда, обеспечивающая регистрацию ключей в ядре ОС:
    
    sudo update-initramfs -uk all
  • ОС должна быть перезагружена.
• Для временного применения ключей (например, в целях тестирования) ключи могут быть динамически загружены через интерфейсы модуля digsg_verif (подробнее см. далее). Загруженные таким способом ключи действуют до перезагрузки ОС.

При регистрации списка ключей в ядре используются следующие каталоги и файлы:

1. Основной набор ключей — три предустановленных ключа в каталоге /etc/digsig/:
   • primary_key_2018.gpg — корневой ключ изготовителя. Используется для верификации других предустановленных ключей. Этот ключ изначально загружен в ядро.
   • build_system_rbt_root_key_2018.gpg — ключ сборочной системы изготовителя, подписанный корневым ключом изготовителя. Используется для верификации подписей файлов, входящих в состав ОС. Этот ключ изначально не загружен в ядро, и загружается после включения режима ЗПС.
   • partners_rbt_root_key_2018.gpg — партнерский ключ изготовителя, подписанный корневым ключом изготовителя. Используется для верификации подписей файлов производителей стороннего ПО. Этот ключ изначально не загружен в ядро, и загружается после включения режима ЗПС.
   Эти ключи используется для проверки всех типов подписей (в т.ч. для проверки подписей ключей из дополнительного набора, если такая проверка применяется).
   

   Если ПО было подписано ранее ключами, сгенерированными для Astra Linux Special Edition РУСБ.10015-01 (очередное обновление 1.5) и более ранних очередных обновлений, то обеспечить работу такого ПО в режиме ЗПС можно установив пакет astra-digsig-oldkeys. В таком случае открытые ключи необходимо размещать в каталоге /etc/digsig/keys/legacy/keys/

2. Дополнительный набор ключей — ключи, которые изначально отсутствуют и могут быть добавлены в каталоги:
   • /etc/digsig/keys/ — ключи для проверки всех типов подписей. Обязательно должны быть подписаны ключами изготовителя или ключами, подписанными ключами изготовителя.
   • /etc/digsig/xattr_keys/ — ключи для проверки подписей в расширенных атрибутах и, в обновлениях начиная с Astra Linux Special Edition 1.8, отсоединенных подписей. Наличие подписи в этих ключах не проверяется.
   • /etc/digsig/certs — ключи для проверки подписей. Используется начиная с Astra Linux Special Edition 1.8. Наличие подписи в этих ключах не проверяется.
   При этом:
   • Ключи в каталоге etc/digsig/keys/:
     • Должны быть подписаны секретным ключом изготовителя и должны быть получены от изготовителя.
     • Применяются для проверки всех типов подписей.
     • Для загрузки могут быть организованы в иерархическую структуру каталогов, при этом ключи в дочерних каталогах /etc/digsig/keys/<имя_каталога>/ могут быть подписаны секретным ключом изготовителя или ключом, находящемся в каталоге /etc/digsig/keys/.Пример размещения ключей, подписанных изготовителем:
       • /etc/digsig/keys/key1.gpg — ключ 1, подписанный на партнерским ключом изготовителя;
       • /etc/digsig/keys/key2.gpg — ключ 2, подписанный на партнерским ключом изготовителя;
       • /etc/digsig/keys/key1/key1-1.gpg — ключ, подписанный ключом 1;
       • /etc/digsig/keys/key1/key1-2.gpg — ключ , подписанный ключом 1;
       • /etc/digsig/keys/key2/key2-1.gpg — ключ , подписанный ключом 2;
       • /etc/digsig/keys/key2/key2-2.gpg — ключ , подписанный ключом 2.
   • Ключи в каталоге /etc/digsig/xattr_keys/:
     • Могут быть созданы самостоятельно с помощью инструмента gpg.
     • Применяются:
       • для проверки подписей в расширенных атрибутах;
       • начиная с обновления Astra Linux Special Edition 1.8 — также для проверки отсоединенных подписей.
     • Подписи на ключах в данном каталоге не проверяются.
   • Ключи в каталоге /etc/digsig/certs/ :
     • Используются начиная с обновления Astra Linux Special Edition 1.8.
     • Применяются для работы КриптоПро.
3. Файл /etc/digsig/revoked_keys — список отзыва ключей. См. ниже.

Отзыв ключей

В случае потери доверия к закрытому ключу возможно исключить подписанные им ключи из процедуры проверки подписей файлов. Для этого нужно сформировать список отзываемых ключей и загрузить его в ядро. Список формируется в файле /etc/digsig/revoked_keys.

Для указания отзываемого ключа используется значение его отпечатка, полученное по алгоритму SHA-1. Отпечаток можно можно получить с помощью команды:

Для указания одного ключа следует использовать команду:

Для указания ключей по заготовленному списку следует использовать команду:

Для применения настроек выполнить команду:

и перезагрузить систему.

Настройка режимов работы ЗПС

Постоянные режимы работы модуля digsig_verif задаются в конфигурационном файле /etc/digsig/digsig_initramfs.conf. Для того, чтобы параметры, заданные в конфигурационном файла вступили в силу, он должен быть загружены в ядро. Процедура загрузки такая же, как для ключей и списка отозванных ключей. Для оперативного изменения режимов работы модуль имеет интерфейсы, представленные специальными файлами. Интерфейсы позволяют оперативно изменять настройки модуля digsig_verif  с сохранением изменений до перезагрузки ОС. Изменение режимов производится записью значений в интерфейс,  текущие значения могут быть прочитаны из некоторых интерфейсов. Возможные значения параметров конфигурации описаны далее.

Параметры управления режимами представлены в таблице:

echo -n <имя_файла> | sudo tee /sys/digsig/verify_path_sign
if [[ "$?" == "0" ]] ; then
 echo "Подпись верна"
else
 echo "Подпись неверна"
fi

Например:

Для временного (до перезагрузки) отключения проверки цифровой подписи по ГОСТ Р 34.10-2001 необходимо в интерфейс /sys/digsig/ignore_gost2001 записать значение 0:

Для проверки актуального значения режима проверки цифровой подписи по ГОСТ Р 34.10-2001 прочитать значение режима из интерфейса:

Для постоянного отключения проверки цифровой подписи по ГОСТ Р 34.10-2001:

1. В конфигурационном файле /etc/digsig/digsig_initramfs.conf для соответствующего параметра задать значение 1
   

   DIGSIG_IGNORE_GOST2001=1

2. После внесения изменений в конфигурационный файл /etc/digsig/digsig_initramfs.conf , а также для загрузки модулем digsig_verif ключей после их размещения в каталогах /etc/digsig/keys/ и /etc/digsig/xattr_keys/ необходимо выполнить команду:
   sudo update-initramfs -u -k all

В Astra Linux Special Edition 1.8 настройка режимов работы может быть выполнена в графической утилите astra-systemsettings («Параметры системы», модуль «Замкнутая программная среда» в разделе «Ограничения программной среды», см. электронную справку). Для вызова модуля можно использовать команду:

Текущие значения параметров проверки подписей можно получить из соответствующих интерфейсов, например:

Включение проверки подписи неисполняемых файлов

Модуль digsig_verif позволяет проверять цифровую подпись неисполняемых файлов в расширенных атрибутах. По умолчанию эта возможность отключена. Для включения следует использовать параметр конфигурации DIGSIG_XATTR_MODE.

Для проверки подписи используются ключи из основного и дополнительного наборов. Проверка подписи производится при открытии файла. Для проверки подписи в расширенных атрибутах имена проверяемых файлов должны быть указаны в файле /etc/digsig/xattr_control. Каждая строка в файле задает шаблон имени проверяемого файла в виде маски полного пути. Например, проверка цифровой подписи всех файлов в каталоге /bin, имя которых начинается на lo:

/bin/lo

Для проверки отдельных файлов (без маски) необходимо указать дополнительный символ «/» в начале пути, например:

//home/start.sh

Добавление дополнительных ключей

В дополнительный набор ключей могут быть добавлены:

• ключи, подписанные изготовителем;
• ключи, подписанные ключом из иерархии подписанных изготовителем ключей;
• произвольные ключи без требований к подписи.

Возможно как скопировать переданный открытый ключ в соответствующий каталог, так и создать собственные ключи самостоятельно. Для создания ключей используется доработанный GNU Privacy Guard (GnuPG), в который добавлена возможность использования алгоритма вычисления хеш-функции ГОСТ Р 34.11-2012. Получить список доступных алгоритмов можно командой:

Пример результата выполнения команды:

Для создания собственного ключа

Создать ключевую пару (закрытый и открытый ключи) по ГОСТ Р 34.10-2012, выполнив команду:

В процессе выполнения команды на запрос о выборе типа ключа указать номер пункта, соответствующий ГОСТ Р 34.10-2012. Пример в вывода команды:

В созданной ключевой паре открытый ключ имеет идентификатор 07888A89440B749338619DF1FBBB20B915E8F5EA, с которым он добавляется в хранилище GPG-ключей /root/.gnupg/pubring.kbx и по которому он выбирается в командах экспорта и копирования.
Если созданный ключ предназначен для создания подписей в расширенных атрибутах или отсоединенных подписей и нет требований подтверждать подпись ключом изготовителя, то экспортировать открытый ключ созданной пары и сохранить его в каталоге /etc/digsig/xattr_keys/ выполнив команду:

Пример:

Если созданная ключевая пара предназначена для подписания любой подписью (в т. ч. встраиваемой), то открытый ключ должен быть подписан закрытым ключом изготовителя или закрытым ключом из иерархии подписанных изготовителем ключей. Такие подписи выполняются владельцем закрытого ключа. Для выполнения такой подписи:

1. Подписать открытый ключ созданной пары, выполнив команду:
   
   gpg --default-key <идентификатор_подписывающего_ключа> --sign-key <идентификатор_подписываемого_ключа>
   Если опция --default_key не использована, то для подписания используется первый найденный закрытый ключ.
   Пример:
   
   gpg --sign-key 07888A89440B749338619DF1FBBB20B915E8F5EA
2. Экспортировать подписанный ключ в файл, выполнив команду:
   
   sudo gpg --export <идентификатор_ключа> > <имя_файла_ключа>.gpg
   Пример:
   
   gpg --export 07888A89440B749338619DF1FBBB20B915E8F5EA > /tmp/secondary_gost_key_signed.gpg
3. Далее подписанный ключ должен быть передан пользователям и размещен в каталоге /etc/digsig/keys на пользовательских компьютерах.

После изменения конфигурации ключей для загрузки ключей в систему контроля ЗПС выполнить команду:

Для просмотра всех ключей, созданных с помощью gpg или импортированных в gpg, использовать команду:

Подписывание файлов

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

Режим Киоск-2

Режим Киоск-2 — инструмент подсистемы безопасности PARSEC для ограничения возможностей, предоставляемых непривилегированным пользователям (далее - ограничения). Работу режима Киоск-2 обеспечивает пакет parsec-kiosk2.

Профили пакета parsec-kiosk2

Пользовательские профили

Для задания разрешений, предоставляемых пользователям при включенном режиме Киоск-2, используются пользовательские профили. Пользовательский профиль — это текстовый файл в каталоге /etc/parsec/kiosk2, имя которого совпадает с именем пользователя. Один профиль служит для установки разрешений только для одного пользователя.

Системные профили

Системные профили parsec-kiosk2 располагаются в каталоге /etc/parsec/kiosk2-profiles и также служат для задания разрешений действий пользователей. Содержимое файла системного профиля представляет собой список файлов и профилей приложений с абсолютными или относительными путями, а также с информацией о правах доступа и владельцах этих файлов. Системные профили можно включать в пользовательские профили. Например, системный профиль может быть задан для приложения и его включение в пользовательские профили предоставит пользователям доступ к приложению.

Синтаксис профилей parsec-kiosk2

Разрешения могут быть установлены для файлов (жестких ссылок на файлы) или символьных ссылок на файлы. Разрешения для каталогов не поддерживается. Синтаксис разрешения на доступ к файлу:

+file rwc u/o: <имя_файла>

или на доступ к символьной ссылке:

+link rwc uo: <имя_ссылки>

где:

• rwc — права доступа к файлу, которые указываются при наличии соответствующего разрешения:
  • открытие на чтение (r);
  • открытие на запись (w)
  • создание (c);
• u — доступ владельцу файла;
• o — доступ остальным пользователям;
• <имя_файла> и <имя_ссылки> — имя файлового объекта (файла или ссылки), к которому применяются права доступа. В момент загрузки профиля, содержащего разрешения на доступ к символьным ссылкам, эти ссылки должны существовать. В список контроля доступа при этом будут добавлены целевые файлы, указанные в ссылках. Целевые файлы в момент загрузки могут не существовать.

В синтаксисе профилей режима Киоск-2 можно использовать кириллицу, также могут быть использованы метасимволы в имени файла.

Доступные метасимволы:

Для включения одного профиля в другой профиль используется лексема @include:

@include other-profile-name

Синтаксис, совместимый с parsec-kiosk

В профилях режима Киоск-2 корректно распознаются строки, соответствующие синтаксису режима киоска (устаревший инструмент для ограничений действий пользователя). При этом при использовании синтаксиса режима киоска в режиме Киоск-2:

• в именах файлов спецсимволы не интерпретируются;
• любое из прав на чтение (r) или исполнение (x) преобразуется в право на чтение (r), а право на запись (w) преобразуется в права на запись (w) и создание (c);
• правила одинаково применяются для доступа как владельцев, так и других пользователей;
• строка обязательно должна начинаться с символа «"» или «/»;
• если файл представляет символьную ссылку, то режим Киоск-2 обрабатывает целевой файл ссылки;
• имя профиля должно начинаться только с латинской буквы, а также в нем должен отсутствовать символ «/».

Если профиль, созданный в режиме киоска, отредактировать и сохранить с использованием графического инструмента fly-admin-kiosk, то он сохранится с использованием синтаксиса режима Киоск-2.

Работа с Киоск-2 через консоль

Включение и выключение Киоск-2

При первом запуске ОС режим Киоск-2 выключен. Чтобы включить режим и применять ограничения на работу с файлами, требуется выполнить команду:

Для временного оперативного включения (до перезагрузки ОС) протоколирования попыток нарушений установленных фильтров доступа выполнить команду:

Для включения режима контроля доступа Киоск-2 и протоколирования с сохранением данного состояния после перезагрузки требуется, соответственно, выполнить команды:

и перезагрузить ОС. Результаты применения этих команд будут действительны после перезагрузки ОС.

Для выключения режимов контроля доступа Киоск-2 и протоколирования в соответствующих командах требуется заменить 1 на 0.

Для того чтобы избирательно включать режим Киоск-2 и исключать выбранных пользователей:

1. В каталоге /etc/parsec/kiosk2 создать каталог disabled:
   
   cd /etc/parsec/kiosk2
   sudo mkdir disabled
2. Переместить в каталог disabled профили тех пользователей, для которых не должны применяться ограничения:
   
   sudo mv <имя_пользователя1> <имя_пользователя2> disabled
3. Включить режим Киоск-2:
   
   echo 1 | sudo tee /sys/module/parsec/parameters/uc_enforce

После выполнения данных действий ограничения режима Киоск-2 будут применены ко всем пользователям, кроме <имя_пользователя1>, <имя_пользователя2> и тех пользователей, для которых не были созданы профили. После перезагрузки ОС режим Киоск-2 вернется в состояние, указанное в /etc/parsec/kiosk2_enforce. При повторном включении режима Киоск-2 исключения для <имя_пользователя1>, <имя_пользователя2> и тех пользователей, для которых не были созданы профили, сохранятся и ограничения доступа к ним не будут применены.

Протоколирование процессов

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

1. Выключить режим контроля доступа Киоск-2:
   
   echo 0 | sudo tee /sys/module/parsec/parameters/uc_enforce
2. Включить протоколирование процессов:
   
   echo 1 | sudo tee /sys/module/parsec/parameters/uc_complain
3. Создать профиль пользователя:
   
   true | sudo tee /etc/parsec/kiosk2/<имя_пользователя>
4. Запустить сессию пользователя <имя_пользователя>:
   
   su - <имя_пользователя>
5. Запустить протоколируемое приложение;
6. Выйти из сессии пользователя:
   
   exit
7. Выключить протоколирование процессов:
   
   echo 0 | sudo tee /sys/module/parsec/parameters/uc_complain
8. Получить сообщения о совершённых операциях:
   
   sudo dmesg | grep PARSEC-UC:

Создание профилей

Для создания системного профиля протоколируемого приложения в каталоге /etc/parsec/kiosk2-profiles создать файл, задав в качестве его имени название приложения, и вписать в него с учетом синтаксиса все пути из сообщений о совершённых операциях.
Для создания профиля пользователя в каталоге /etc/parsec/kiosk2 создать файл с именем, совпадающим с именем этого пользователя.

Графический инструмент управления профилями

Для управления режимом Киоск-2 и профилями используется графический инструмент fly-admin-kiosk. Описание инструмента приведено в электронной справке.

Для запуска утилиты выполнить в консоли команду:

или перейти «меню «Пуск» — Панель управления — Безопасность — Системный киоск».

Графический киоск

Для ограничения прав запуска программ локальными пользователями возможно использовать режим графического киоска. Настройка режима графического киоска выполняется с использованием модуля «Графический киоск» в разделе «Ограничения программной среды» графической утилиты astra-systemsettings («Параметры системы», см. электронную справку). Для вызова модуля можно использовать команду:

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

Графический киоск в режиме «Мобильный»

Графический киоск в режиме «Мобильный» ограничивает доступ пользователя к функциям системы и возможность запуска графических приложений. Настройка графического киоска выполняется администратором в конфигурационном файле /etc/mobile-kiosk/mobile-kiosk.conf (если указанные каталог и конфигурационный файл отсутствуют, их необходимо создать). В конфигурационном файле необходимо указать имя учетной записи пользователя, для которого настраивается графический киоск, и в качестве значения параметра Applications перечислить desktop-файлы приложений, которые можно будет запускать указанному пользователю:

[<имя_пользователя>]
Applications=<приложение1>,<приложение2>,...

Пример настройки киоска для пользователя user, разрешающая запуск только приложений «Галерея» и «Музыка»:

[user]
Applications=fly-gallery,fly-music

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

• просмотр и удаление уведомлений;
• строка поиска;
• изменение громкости звука и яркости экрана;
• завершение работы.

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

Если в конфигурационном файле /etc/mobile-kiosk/mobile-kiosk.conf в качестве значения параметра Applications указано одно приложение и дополнительно указан параметр SingleMode=true, киоск будет работать в одиночном режиме — указанное приложение будет запускаться автоматически при входе пользователя в сессию и пользователь сможет работать только в данном приложении. При завершении работы приложения будет автоматически завершена пользовательская сессия. Из функций системы пользователю будет доступно только завершение работы.

Пример настройки киоска для пользователя user, разрешающая работать в одиночном режиме в приложении «Калькулятор»:

[user]
Applications=org.kde.kalk
SingleMode=true

Изоляция приложений

Для обеспечения изолированного выполнения графических и консольных приложений в состав ОС входит инструмент Firejail . Целью применения Firejail является минимизация риска компрометации основной ОС при запуске недоверенных или потенциально уязвимых программ.

Для обеспечения изоляции приложений в Firejail используются:

• механизм пространств имен namespaces;
• фильтрация системных вызовов seccomp-bpf.

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

Firejail не требует подготовки системного образа: состав окружения формируется при запуске на основе содержимого текущей ФС, и удаляется после завершения работы приложения.

При использовании Firejail предоставляются средства задания правил доступа к ФС, позволяющие:

• определять файлы и каталоги, к которым разрешен или запрещен доступ;
• предоставлять доступ к файлам или каталогам только для чтения;
• подключать для данных временные ФС (tmpfs);
• совмещать каталоги через bind-mount и overlayfs.

При установке ОС установка инструмента Firejail выполняется автоматически. В целях повышения безопасности при установке Firejail снимается бит suid. Для того чтобы с помощью Firejail можно было запускать приложения, необходимо включить этот бит, выполнив от имени администратора команду:

В состав ОС входят профили изоляции системных вызовов для большинства популярных приложений, в том числе для Firefox, Chromium, VLC. Для выполнения программы в режиме изоляции требуется указать имя приложения в качестве параметра для инструмента Firejail, например:

Для запуска браузера Firefox может потребоваться внести изменения в конфигурационный файл /etc/firejail/firefox.profile, заменив строку seccomp на строку:

seccomp.drop @clock,@cpu-emulation,@debug,@module,@obsolete,@raw-io,@reboot,@resources,@swap,acct,add_key,bpf,fanotify_init,io_cancel,io_destroy,io_getevents,io_setup,io_submit,ioprio_set,kcmp,keyctl,mount,name_to_handle_at,nfsservctl,ni_syscall,open_by_handle_at,personality,pivot_root,process_vm_readv,ptrace,remap_file_pages,
request_key,setdomainname,sethostname,syslog,umount,umount2,userfaultfd,vhangup,vmsplice