Digsig error not signed

Общая информация

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

• к файлам формата ELF (исполняемым файлам и разделяемым библиотекам) — проверка ЭЦП, записанной в специальное поле файла (далее — встроенная ЭЦП);
• к любым файлам — проверка ЭЦП, размещаемой в расширенных атрибутах файла (далее — присоединенная ЭЦП);

Режимы выполнения проверки описаны ниже.

Средства создания ЗПС предоставляют возможности внедрения встроенной ЭЦП в исполняемые файлы формата ELF, входящие в состав устанавливаемого СПО, и возможность создания присоединенных ЭЦП. Поддерживается использование при подписывании нескольких ключей.

Настройка режима работы модуля digsig_verif

Графический инструмент fly-admin-smc

Графический инструмент fly-admin-smc может применяться для настройки всех параметров. Инструмент устанавливается по умолчанию при установке ОС и доступен в графическом меню: fly-admin-smc (<<Панель управления — Безопасность — Политика безопасности — Замкнутая программная среда>>) . Описание графического инструмента приведено в электронной справке.

Инструмент командной строки astra-digsig-control

Инструмент командной строки astra-digsig-control применяется для настройки режима проверки подписи в исполняемых файлах. См. Инструменты командной строки astra-safepolicy.

Параметры работы ЗПС в каталоге /etc/digsig/

Параметры работы ЗПС в файле /etc/digsig/digsig_initramfs.conf

Настройка режима работы ЗПС может осуществляться путем прямого редактирования конфигурационного файла /etc/digsig/digsig_initramfs.conf.

Параметры задаются в виде:

<имя_параметра>=<значение_параметра>

Используются следующие параметры:

• DIGSIG_ELF_MODE — режим проверки встроенной ЭЦП в файлах формата ELF. Возможные значения:
  • 0 — Значение по умолчанию. Проверка встроенной ЭЦП отключена. Может применяться как отладочный режим для разработки и отладки СПО;
  • 1 — Штатный режим проверки встроенной ЭЦП. Проверка встроенной ЭЦП включена. Выполнение файлов, имеющих неверную встроенную ЭЦП или не имеющих встроенную ЭЦП, запрещается;
  • 2 — Режим проверки работы СПО в ЗПС. Проверка встроенной ЭЦП включена. Выполнение файлов, имеющих неверную встроенную ЭЦП или не имеющих встроенную ЭЦП, разрешается, но при этом выдается сообщение об ошибке проверки ЭЦП;
• DIGSIG_XATTR_MODE — режим проверки прикрепленной ЭЦП в расширенных атрибутах. Возможные значения:
  • 0 — Значение по умолчанию. Проверка прикрепленной ЭЦП отключена. Может применяться как отладочный режим для разработки и отладки СПО;
  • 1 — Штатный режим проверки прикрепленной ЭЦП. Проверка прикрепленной ЭЦП включена. Выполнение файлов, имеющих неверную прикрепленную ЭЦП или не имеющих прикрепленную ЭЦП, запрещается;
  • 2 — Режим проверки работы СПО в ЗПС. Проверка прикрепленной ЭЦП включена. Выполнение файлов, имеющих неверную прикрепленную ЭЦП или не имеющих прикрепленную ЭЦП, разрешается, но при этом выдается сообщение об ошибке проверки ЭЦП;

• DIGSIG_IGNORE_XATTR_KEYS – режим применения при проверке встроенной ЭЦП ключей для проверки присоединенной ЭЦП:

  • 0 — Значение по умолчанию. При проверке встроенной ЭЦП ключи для проверки присоединенной ЭЦП используются;
  • 1 – При проверке встроенной ЭЦП ключи для проверки присоединенной ЭЦП игнорируются;

• DIGSIG_IGNORE_GOST2001 – режим использования при проверке ЭЦП по ГОСТ~Р~34.10-2001:
  • 0 — Значение по умолчанию. При проверке ЭЦП по ГОСТ~Р~34.10-2001 используется;
  • 1 – При проверке ЭЦП по ГОСТ~Р~34.10-2001 не используется;

Данные для работы ЗПС

Помимо конфигурационного файла /etc/digsig/digsig_initramfs.conf в каталоге /etc/digsig/ представлены:

• Каталог /etc/digsig/keys — каталог дополнительных ключей для проверки встроенной и присоединенной ЭЦП;
• Файл /sys/digsig/xattr_control — список шаблонов шаблонов имен, определяющих файлы, в которых проверяется присоединенная ЭЦП;
• Каталог /sys/digsig/xattr_keys — каталог дополнительных ключей, используемых только при проверке присоединенной ЭЦП;

Шаблоны для проверки присоединенной ЭЦП

В файле /sys/digsig/xattr_control хранится список шаблонов шаблонов имен файлов, определяющих файлы, в которых проверяется присоединенная ЭЦП. Порядок применения шаблонов:

• В шаблонах должны указываться абсолютные пути, т.е шаблон всегда должен начинаться с символа slash (косая черта, «/»);
• Шаблоны, начинающиеся с двух символов slash («//»), указывают имя конкретного файла. Например: //bin/script.sh;
• Шаблоны, оканчивающиеся символом slash, указывают имя каталога, в котором должны проверяться все файлы (включая файлы в подкаталогах). Например: /bin/;
• Все остальные шаблоны рассматриваются как префикс имени файла, Например, шаблону /bin/script соответствуют файлы: /bin/script, /bin/script.signed, /bin/script12345 и т.д.

Ключи для работы с ЭЦП

В модуль digsig_verify встроены открытые ключи, которые используются:

• для проверки встроенных ЭЦП;
• для проверки присоединенных ЭЦП;
• для проверки ЭЦП в дополнительных ключах, загружаемых из каталога /etc/digsig/keys.

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

• основной набор ключей — для проверки всех ЭЦП;
• дополнительный набор ключей  в каталоге /etc/digsig/keys (изначально пустой) — для проверки встроенных ЭЦП;
• дополнительный набор ключей  в каталоге /etc/digsig/keys_xattrs (изначально пустой) — для проверки присоединенных ЭЦП и, возможно, встроенных ЭЦП. Подпись на первом ключе из этого набора не проверяется..

Все ключи хранятся в указанных каталогах и их подкаталогах (см. ниже). Ключи хранятся в формате gnupg —export/etc/digsig/keys и загружаются при загрузке ОС;

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

Каждый новый ключ, использованный для подписывания СПО, необходимо включить в дополнительный набор ключей, для чего скопировать файл с ключом в каталог /etc/digsig/keys/ или /etc/digsig/xattr_keys, например, с использованием команды:

    sudo cp /<каталог>/<файл ключа> /etc/digsig/keys/

Каждый ключ в момент его добавления в каталог /etc/digsig/keys должен быть подписан уже загруженным ключом. При этом в подкаталогах ключи располагаются в иерархической структуре, которая обрабатывается сверху вниз таким образом, что:

• файлы ключей в корневом каталоге (/etc/digsig/keys) должны быть подписаны встроенными в модуль digsig_verify ключами;
• каждый ключ в подкаталогах должен быть подписан либо ключом из вышележащего каталога, либо встроенным ключом.

Например:

Каждый дополнительный ключ, использованный для проверки присоединенной ЭЦП, необходимо скопировать в каталог /etc/digsig/xattr_keys/, например:

sudo cp /<каталог>/<файл ключа> /etc/digsig/xattr_keys/

В каталоге /etc/digsig/xattr_keys/ также может располагаться иерархическая структура дополнительных ключей, в которой одни дополнительные ключи должны быть подписаны на других дополнительных ключах. При этом дополнительные ключи должны располагаться в подкаталогах таким образом, чтобы при их загрузке не нарушалась цепочка проверки подписей (см. пример выше).

Графический инструмент fly-admin-smc

В состав Astra Linux входит графический инструмент fly-admin-smc, предоставляющий возможности работы с настройками ЗПС. Инструмент доступен в графическом меню: «Пуск» — «Панель управления» — «Безопасность» — «Политика безопасности» — «Замкнутая программная среда». Работа с инструментом подробно описана во встроенной справке. (клавиша F1).

Подписывание ПО

Встроенная ЭЦП

См. Создание встроенной подписи в ELF файлах для режима ЗПС а также Подписание пакетов ПО.

Присоединенная ЭЦП

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

gpg —version

Далее приведен пример создания дополнительного ключа и его использования для создание встроенной ЭЦП.

1. Создать ключевую пару. По умолчанию пара будет сохранена подкаталоге .gnupg домашнего каталога текущего пользователя. Ключевая пара может быть создана с помощью графического инструмента fly-admin-amc, или в командной строке в интерактивном или пакетом режиме.

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

      gpg —gen-key

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

      _открытый и секретный ключи созданы и подписаны.
      
      pub   rsa3072 2022-11-24 [SC] [   годен до: 2024-11-23]
            12B6FA0CD98F2D9CE72AB595C0316DBD6D879F9Fо uid                      имя_пользователя <адрес_электронной_почты>
      sub   rsa3072 2022-11-24 [E] [   годен до: 2024-11-23]

      Далее в примерах для идентификации ключа используется идентификатор ключа —  последовательность шестнадцатеричных цифр, в примере выше  12B6FA0CD98F2D9CE72AB595C0316DBD6D879F9F. Ключ можно также идентифицировать по имени пользователя;

   2. Для создания ключевой пары в пакетном режиме:

      1. Создать файл с параметрами ключа, например:
         

         Key-Type:GOST_R34.10-2012
         %no-protection
         Name-Real:<имя_пользователя>
         Name-Comment: <комментарий>
         Name-Email: <e-mail>

         подробнее см. Unattended GPG key generation;
         

      2. Выполнить команду:
         

         gpg —gen-key —batch <имя_файла_с_параметрами_ключа>

         
         

      3. Информацию о созданном ключе можно получить командой:
         

         gpg —list-keys

         
         

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

   gpg —export <идентификатор_ключа> | sudo gpg —import 
   sudo gpg —sign-key <идентификатор_ключа>

   для применения подписанный ключ должен быть экспортирован в каталог /etc/digsig/xattr_keys. Команды:

   sudo gpg —export  <идентификатор_ключа> | tee /etc/digsig/xattr_keys/<имя_файла_с_подписанным_экспортированным_ключом>

   Наличие подписи в ключах для проверки присоединенной ЭЦП не проверяется. Поэтому созданный ключ можно экспортировать не подписывая:

   gpg —export <идентификатор_ключа> | sudo tee /etc/digsig/xattr_keys/<имя_файла_с_экспортированным_ключом>

3. В файле /etc/digsig/xattr_control задать маски имен контролируемых файлов, например:
   

   Если заданная маска оканчивается символом «/», то она интерпретируется как имя каталога и контролируются все файлы в этом каталоге, в ином случае маска интерпретируется как префикс полного имени контролируемых файлов.

4. Подписать контролируемые файлы внешней ЭЦП:
   

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

   bsign —sign —xattr <имя_файла>

   Дополнительная информация доступна в справке по утилите bsign;

5. Включить проверку ЭЦП:

   1. Изменить параметр  DIGSIG_XATTR_MODE в файле /etc/digsig//etc/digsig/digsig_initramfs.conf, указав нужный режим проверки;

   2. Выполнить команду:
      

      sudo update-initramfs -u -k all

   3. Перезагрузить ОС;

Для проверки наличия и правильности ЭЦП файла можно использовать утилиту bsign:

bsign -w <имя_файла>

Проверка работы ЗПС

Модуль проверки подписи приложений digsig_verif является модулем ядра. Сообщения модулей ядра можно просмотреть командой:

sudo dmesg

Или, в случае модуля digsig_verif:

sudo dmesg | grep DIGSIG

Попытки запуска файлов во включенной ЗПС будут :

... DIGSIG: [ERROR]  NOT SIGNED: path=....

sag_ekb	#1 Оставлено : 25 ноября 2019 г. 12:07:54(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.11.2019(UTC) Сообщений: 2 Откуда: Екатеринбург	Здравствуйте. Пользуясь инструкцией https://wiki.astralinux….e.action?pageId=32833902 был установлен криптоПро CSP. При переходе в режим ЗПС(замкнутая программная среда) возникают ошибки вида /var/log/syslog: DIGSIG:[ERROR] digsig_gost_bsign_verify: ERROR, signer key was not found (ID=0x6e3956ee) DIGSIG:[ERROR] VERIFICATION FAILED: path=/opt/cprocsp/sbin/amd64/cpconfig uid=0 gid=0 DIGSIG:[ERROR] digsig_gost_bsign_verify: ERROR, signer key was not found (ID=0x6e3956ee) DIGSIG:[ERROR] VERIFICATION FAILED: path=/opt/cprocsp/sbin/amd64/cpconfig uid=0 gid=0 DIGSIG:[ERROR] digsig_gost_bsign_verify: ERROR, signer key was not found (ID=0x6e3956ee) DIGSIG:[ERROR] VERIFICATION FAILED: path=/opt/cprocsp/sbin/amd64/cryptsrv uid=0 gid=0 DIGSIG:[ERROR] digsig_gost_bsign_verify: ERROR, signer key was not found (ID=0x6e3956ee) DIGSIG:[ERROR] VERIFICATION FAILED: path=/opt/cprocsp/lib/amd64/libcsp_kc2.so.4.0.4 uid=0 gid=0 DIGSIG:[ERROR] NOT SIGNED: path=/usr/bin/git uid=0 gid=0 Предполагаю, что проблема связана с тем, что ОС не может найти ключи, которыми били подписаны elf файлы КриптоПро. Верно ли это предположение? Нужно ли отдельно ставить ключи в папку /etc/digsig/keys? Где можно взять открытые ключи, которыми были подписаны файлы криптопро

sag_ekb	#2 Оставлено : 26 ноября 2019 г. 11:30:55(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 25.11.2019(UTC) Сообщений: 2 Откуда: Екатеринбург	Решение следующее: Нужно получить открытый ключ КриптоПро: https://cryptopro.ru/sit…sp/cryptopro_pub_key.gpg Установить пакет astra-digsig-oldkeys. Взять можно с установочного диска Астры. В моем случае файла не было, пришлось вновь качать образ диска: https://download.astrali…nternational-se-version/ После установки пакета поместить открытый ключ сюда /etc/digsig/keys/legacy/keys Спасибо за помощь Андрею Русеву. Отредактировано модератором 26 ноября 2019 г. 12:48:12(UTC)  | Причина: Не указана

Быстрый переход
 

Вы не можете создавать новые темы в этом форуме.

Вы не можете отвечать в этом форуме.

Вы не можете удалять Ваши сообщения в этом форуме.

Вы не можете редактировать Ваши сообщения в этом форуме.

Вы не можете создавать опросы в этом форуме.

Вы не можете голосовать в этом форуме.

Загрузка неподписанного файла заблокирована сзос digsig astra linux

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

Механизм контроля целостности исполняемых файлов и разделяемых библиотек формата ELF при запуске программы на выполнение реализован в модуле ядра ОС digsig_verif, который является не выгружаемым модулем ядра Linux, и может функционировать в одном из следующих режимов:
— исполняемым файлам и разделяемым библиотекам с неверной ЭЦП, а также без ЭЦП загрузка на исполнение запрещается (штатный режим функционирования);
— исполняемым файлам и разделяемым библиотекам с неверной ЭЦП, а также без ЭЦП загрузка на исполнение разрешается, при этом выдается сообщение об ошибке проверки ЭЦП (режим для проверки ЭЦП в СПО);
— ЭЦП при загрузке исполняемых файлов и разделяемых библиотек не проверяется (отладочный режим для тестирования СПО).
———

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

В каталог /etc/digsig/keys необходимо поместить(при наличии) переданный открытый (публичный) ключ (например, ключ в файле компания_pub_key.gpg)

В файле /etc/digsig/digsig_initramfs.conf установить параметры:

Двнные параметры в файле и во все могут отсуствовать. Необходимо ввести с нуля.

update-initramfs -u -k all

Перезагрузить компьютер.
Без открытого ключа (*_pub_key.gpg) Вашей компании, возможна работа только пакетов из состава дистрибутива операционной системы специального назначения «Astra Linux Special Edition«.

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

Перед подписыванием пакетов необходимо импортировать закрытый и открытый ключи переданные Авторизуйтесь, для доступа к ссылке (gpg —import ***.gpg, gpg —import ***.key).

Посмотреть идентификатор импортированного ключа можно командой gpg —list-keys.

Отдельные файлы ELF можно подписать командой bsign -s, закрытый и открытый ключи переданные Авторизуйтесь, для доступа к ссылке перед выполнением команды должны быть импортированы.
———

Источник

Общая информация

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

Механизм контроля целостности исполняемых файлов и разделяемых библиотек формата ELF при запуске программы на выполнение (загрузке библиотеки) реализован в модуле ядра ОС digsig_verif. Модуль digsig_verif является невыгружаемым модулем ядра Linux и может функционировать в одном из следующих режимов:

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

Механизм контроля целостности файлов при их открытии на основе ЭЦП, содержащейся в расширенных атрибутах файлов, также реализован в модуле ядра ОС digsig_verif и может функционировать в одном из следующих режимов:

• запрещается открытие или запуск файлов, поставленных на контроль, имеющих неверную ЭЦП или не имеющих ЭЦП (т.е. файлов, либо не подписанных, либо не имеющих ключа в каталогах /etc/digsig/xattr_keys или /etc/digsig/keys);
• открытие файлов, поставленных на контроль, имеющих неверную ЭЦП или не имеющих ЭЦП разрешается, при этом выдается сообщение об ошибке проверки ЭЦП (режим для проверки ЭЦП в расширенных атрибутах файловой системы);
• ЭЦП при открытии файлов не проверяется.

Настройка модуля digsig_verif

Настройка режима функционирования модуля digsig_verif осуществляется посредством графического инструмента fly-admin-smc ( >) или путем редактирования конфигурационного файла /etc/digsig/digsig_initramfs.conf. Описание использования графического инструмента приведено в электронной справке.

Дополнительно для настройки режима функционирования модуля digsig_verif с проверкой подписи в исполняемых файлах можно использовать инструмент командной строки astra-digsig-control, входящий в пакет astra-safepolicy (см. Инструменты командной строки astra-safepolicy).

Порядок прямого редактирования конфигурации модуля digsig_verif для настройки режима проверки подписи ELF:

Редактирование конфигурационного файла /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/, например, с использованием команды:

sudo cp / / /etc/digsig/keys/

В каталоге /etc/digsig/keys/ может располагаться иерархическая структура ключей. Каждый ключ должен быть подписан уже загруженным ключом основного набора в момент его добавления в основной набор. Иерархия подкаталогов /etc/digsig/keys обрабатывается сверху вниз таким образом, что:

• файлы ключей в /etc/digsig/keys должны быть подписаны встроенными в модуль digsig_verify ключами АО «НПО РусБИТех»;
• файлы ключей в /etc/digsig/keys/subdirectory могут быть подписаны и встроенными ключами АО «НПО РусБИТех», и ключами из /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

Для проверки использования дополнительных ключей для контроля целостности исполняемых файлов и разделяемых библиотек формата 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.

Порядок прямого редактирования конфигурации модуля digsig_verif для настройки режима проверки подписи в расширенных атрибутах (xattr):

Редактирование конфигурационного файла /etc/digsig/digsig_initramfs.conf осуществляется следующим образом:

для включения проверки подписей в режиме запрета открытия поставленных на контроль файлов с неверной ЭЦП или без ЭЦП в расширенных атрибутах файловой системы необходимо установить для параметра |DIGSIG_XATTR_MODE значение 1:

для включения проверки подписей в режиме вывода предупреждений об открытии поставленных на контроль файлов с неверной ЭЦП или без ЭЦП в расширенных атрибутах файловой системы необходимо установить для параметра DIGSIG_XATTR_MODE значение 2:

для игнорирования дополнительных ключей, используемых только при проверке ЭЦП в расширенных атрибутах файловой, необходимо установить для параметра DIGSIG_IGNORE_XATTR_KEYS значение 1:

DIGSIG_IGNORE_XATTR_KEYS=1

для настройки шаблонов имен, используемых при проверке ЭЦП в расширенных атрибутах ФС, необходимо в файле /etc/digsig/xattr_control задать их список. Каждая строка задает свой шаблон в виде маски полного пути. Например, следующий шаблон определяет, что будет проверяться ЭЦП всех файлов в каталоге /bin, имя которых начинается на lo (т.е. имён, соотвествующих регулярному выражению (шаблону) /bin/lo*) :

• Для отображения сообщения о загрузке неподписанного файла можно добавить в автозапуск утилиту fly-syslog-monitor.

Каталог /etc/digsig/xattr_keys содержит открытые ключи в формате gnupg —export, которыми расширяется дополнительный набор ключей модуля (изначально пустой набор, используемый только для проверки подписи в расширенных атрибутах файла). Подписи на ключах дополнительного набора не проверяются.

Каждый дополнительный ключ, использованный для подписывания файлов в расширенных атрибутах, необходимо скопировать в каталог /etc/digsig/xattr_keys/, например, с
использованием команды:

sudo cp / / /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;

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

cat /sys/digsig/elf_mode
cat /sys/digsig/xattr_mode

Для отключения проверки ЭЦП по ГОСТ

34.10-2001 необходимо в конфигурационном файле /etc/digsig/digsig_initramfs.conf установить следующее значение параметра:

После внесения изменений в конфигурационный файл /etc/digsig/digsig_initramfs.conf и для загрузки модулем digsig_verif ключей после их размещения его в каталогах /etc/digsig/keys/ и /etc/digsig/xattr_keys/
необходимо от имени учетной записи администратора через механизм verb|sudo| выполнить команду:

sudo update-initramfs -u -k all

Подписывание ПО

В модуле ядра digsig_verif реализован механизм, позволяющий использовать несколько ключей при подписывании файлов формата ELF.

Порядок использования ключей для digsig_verif:

• дополнительные ключи записываются в /sys/digsig/keys или /sys/digsig/xattr_keys’ в иерархической последовательности цепочек подписей;
• все дополнительные ключи должны быть подписаны главным ключом или другим дополнительным ключом, подпись которого может быть проверена (за исключением первого ключа в каталоге /sys/digsig/xattr_keys).

Для создания дополнительных ключей используется GNU Privacy Guard.
Модифицированный GnuPG выводит ГОСТ

34.11-94 в списке доступных алгоритмов.
Для получения списка доступных алгоритмов необходимо выполнить команду:

Далее приведен пример создания дополнительного ключа и его использования для подписывания СПО.

Сначала создается ключевая пара GOST R 34.10-2001, которая сохраняется в каталоге

/.gnupg.
Для создания ключевой пары необходимо выполнить приведенную далее команду с последующим выбором в меню gpg алгоритма ГОСТ

Экспорт ключа в файл осуществляется командой:

gpg —export «Test GOST R 34.10-2012 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 «
gpg —export «Test GOST R 34.10-2001 Secondary Key » > /tmp/secondary_gost_key_signed.gpg

Пользователь подписывает на данном ключе некоторый файл формата ELF с использованием утилиты bsign (по умолчанию подпись внедряется в том числе и в расширенные атрибуты файла):

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

Дополнительная информация доступна в справке по утилите bsign;

Для проверки правильности ЭЦП файла формата ELF используется утилита bsign:

Дополнительный ключ пользователя, подписанный на главном ключе, копируется в каталог /etc/digsig/.

Подписанный файл формата ELF может выполняться:

Проверка работы ЗПС

Модуль проверки подписи приложений digsig_verif является невыгружаемым модулем ядра. Сообщения таких модулей можно просмотреть командой:

Или, в случае модуля digsig_verif:

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

Источник

0

Отредактировано: Raijin 2022.06.21 11:38:13

Режим замкнутой программной среды

Пример активизации режима замкнутой программной среды

Разрешить запуск только подписанных файлов

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

Необходимо запретить запуск любых исполняемых файлов, которые не подписаны ЭЦП (x509 сертификат).

О системе: Linux Debian, под руктом не сидим, у пользователя права ограничены. Но в теории допускаем, что в систему может попасть вредоносный исполняемых файл. Поэтому хотим запретить все, разрешить только то, что подписано нашей ЭЦП. Тоесть будем подписывать все исполняемые системные файлы нашей ЭЦП.

Какие есть идеи?

Как быть со скриптами, которые как-бы напрямую не выполняются, но вредоносные действия выполнить могут ?
http://g.zeos.in/?q=linux run only signed executable files

Спасибо, нашел несколько решений, буду разбираться.

А со скриптами, наверное запретим выполнение bash скриптов из папки пользователя совсем. Тоесть только системные скрипты пусть выполняются, и по идеи пользователь их не может модифицировать.

Думаю почитать про selinux будет нелишним.

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

Корень в ro и запрет на исполнение из всех мест кроме корня уже чем то не торт?

скрипты тоже подписать! дописать в конец текстом цифровую подпись в ascii-armored виде

Какие пакеты есть реализующие проверку этой подписи?

запрет на исполнение из всех мест кроме корня уже чем то не торт?

Как? Как? Наверное монтированием всех остальных мест с соответствующей опцией?

От ручного вызова интерпретатора с корня не поможет.

И да у этих ублюдков в GrSecurity в их заплатке ядра был флажок который запрещает исполнение любого кода не созданного в тулчейне с их же заплатками. И вот если включить эту паранойю то да perl, python, bash, sh… всё вообще шло лесом. И помоему эту фичу оттуда пока что так и не портировали.

От ручного вызова интерпретатора с корня не поможет.

Товарищь Сталин не может ошибатся — нет интерпретатора нет проблем.

ld-linux.so тоже интерпретатор.

Питон и перл и так запрещен, всмысле нечем их обрабатывать. Доустановить нельзя.

JS в браузере не считаем, там своя песочница у браузера.

Даже в пользовательский каталог?

Ну ты понил да? А то до тех пор пока он есть проблем не оберешься.

Из пользовательского каталога нужно вообще запретить выполнять файлы

Бегло ознакомился с вариантами, на сколько понял, это:

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

Можно через seccomp переопределить вызовы execv, execp, . На свой который читает значение extended атрибута security.myattribute и соответственно проверяет хэш, выполняет или нет.

DigSig давно заброшен. IMA/EVM включены в ядро и развиваются, очень функциональны, но пользоваться ими на обычном дистрибутиве ими будет, вероятно, довольно проблематично. Для оффлайн-дистрибутивов для встраиваемых систем подходят.

snort, selinux такое умеют?

По идее достаточно noexec в качестве опции монтирования для хомяка. Нечаянно запустить вредоносный исполняемый файл уже никак не получится. Специально, прописав нужные команды в командную строку — получится. Но не пофиг ли (как верно заметили выше, один фиг остаются интерпретаторы)? Если юзер осознанно хочет запустить что-то плохое, то он может вообще ручками выполнить то, что должен был выполнить скрипт (удалить какие-нибудь файлы, скопировать что-нибудь на флешку или отправить по сети с помощью браузера и т. д.). И от этого никак не уйти. Только доверять юзерам + ограничивать максимально их в правах (чтобы они не могли получить доступ к тому, к чему в принципе не должны).

Придумал, как обойдись селинухом

Достаточно объявить, что его метки есть кеш результата проверки подписей. Грубо говоря, наваять кастомный restorecon, который выставляет метки согласно 2х разных политик для проверенных и непроверенных файлов(очевидно, вторая — без исполнимых меток), отобрать права менять их всему, кроме него, у всего отобрать права писать в исполнимые типы, добавить принудительный relabel всего при перезагрузке и обновлениях.

Источник

Установка программы в Astra Linux в режиме закрытой программной среды

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

Для Astra Linux Special Edition версии 1.6

Укажите следующие параметры в файле /etc/digsig/digsig_initramfs.conf:

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

apt install astra-digsig-oldkeys

Создайте директорию для ключа программы:

mkdir -p /etc/digsig/keys/legacy/kaspersky/

Разместите ключ программы (/opt/kaspersky/kesl/shared/kaspersky_astra_pub_key.gpg) в директории, созданной на предыдущем шаге:

cp kaspersky_astra_pub_key.gpg /etc/digsig/keys/legacy/kaspersky/

Обновите диски оперативной памяти:

update-initramfs -u -k all

Для Astra Linux Special Edition версии 1.5

Укажите следующие параметры в файле /etc/digsig/digsig_initramfs.conf:

Создайте директорию для ключа программы:

mkdir -p /etc/digsig/keys/legacy/kaspersky/

Разместите ключ программы (/opt/kaspersky/kesl/shared/kaspersky_astra_pub_key.gpg) в директории, созданной на предыдущем шаге:

cp kaspersky_astra_pub_key.gpg /etc/digsig/keys/legacy/kaspersky/

Обновите диски оперативной памяти:

sudo update-initramfs -u -k all

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

Источник

Операционные системы Astra Linux

Оперативные обновления и методические указания

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

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

1. инструкций и методических указаний по настройке и особенностям эксплуатации ОС, содержащих сведения о компенсирующих мерах или ограничениях по примене- нию ОС при эксплуатации;
2. отдельных программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, инструкций по их установке и настройке, а также информации, содержащей сведения о контрольных суммах всех файлов оперативного обновления;
3. обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.

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

Источник

Операционные системы Astra Linux

Оперативные обновления и методические указания

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

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

1. инструкций и методических указаний по настройке и особенностям эксплуатации ОС, содержащих сведения о компенсирующих мерах или ограничениях по примене- нию ОС при эксплуатации;
2. отдельных программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, инструкций по их установке и настройке, а также информации, содержащей сведения о контрольных суммах всех файлов оперативного обновления;
3. обновлений безопасности, представляющих собой файл с совокупностью программных компонентов из состава ОС, в которые внесены изменения с целью устранения уязвимостей, а также информации, содержащей сведения о контрольных суммах всех файлов обновлений безопасности, указания по установке, настройке и особенностям эксплуатации ОС с установленными обновлениями безопасности.

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

Источник