19 Jun
2024
19 Jun
'24
6:27 p.m.
ГОСТ
====
1 апреля 2024 года был введён в действие ГОСТ Р 71206-2024 «Защита
информации. Разработка безопасного программного обеспечения. Безопасный
компилятор языков С/С++. Общие требования».
SAFEC выполняет требования, предъявляемые этим стандартом к безопасному
компилятору третьего, второго и первого классов.
База данных компиляции по ГОСТ: опция --dump-sbom
=================================================
ГОСТ Р 71206-2024 требует, чтобы для безопасного компилятора была
реализована функция по журналированию процесса трансляции. Результат
журналирования — база данных компиляции. В ней должны фиксироваться
имена файлов—единиц трансляции и подключаемых файлов, их хэш-коды по
ГОСТ 34.11-2018, команды компиляции. Также должна быть включена
информация, позволяющая идентифицировать программы, задействованные в
трансляции исходных текстов в исполняемый код, их настройки и
конфигурационные файлы.
Для создания подробной базы данных компиляции в виде JSON файлов
безопасный компилятор предоставляет опцию --dump-sbom <DIR>.
https://safecompiler.pages.ispras.ru/changelog/gcc/#introduce-sbom
Подробное описание опции с примером работы можно найти в руководстве
пользователя (README) безопасного компилятора в разделе «Журналирование
процесса трансляции: --dump-sbom».
Скрипт comp_db_parser из поставки SAFEC позволяет проанализировать
«состав» ПО на уровне отдельных файлов. Он обходит полученную с помощью
--dump-sbom базу данных компиляции от заданного результирующего файла и
выводит множество «листовых» файлов, участвовавших в качестве входных
при компиляции, и их хэши.
Эта реализация журналирования выполнена на уровне драйвера (программа
gcc) и компилятора (вспомогательные программы cc1/cc1plus). При этом
она имеет ограничения — случаи, которые не поддержаны или принципиально
не могут быть учтены в таком подходе. Например:
- Если утилиты (ассемблер/компоновщик) вызываются напрямую, а не через
gcc, эти команды не будут учтены.
- Для генерируемых исходных файлов с точки зрения получаемой базы данных
компиляции исходными будут считаться результаты генерации.
- Если при компоновке используется linker script, меняющий имя выходного
файла, оно будет учтено неправильно.
- В режиме создания precompiled header'ов (.pch/.gch файлов) выходные
файлы не учитываются правильно. (Пока не поддерживается.)
- Набор конфигурационных файлов утилит в некоторой степени «угадывается»
т.е. строится на основе наших знаний о тулчейне. Если потребуется его
расширить, нужно будет внести изменения в компилятор.
Sbom-trace — отдельная утилита, не зависящая от компилятора
===========================================================
Перечисленные выше ограничения побудили нас создать инструмент, решающий
задачу в общем виде. Рабочее название этого инструмента — sbom-trace.
Он учитывает требования ГОСТ Р 71206-2024 в части журналирования
процесса трансляции.
Этот инструмент не зависит от компилятора и используемых языков
программирования. Принцип его работы основан на перехвате системных
вызовов с помощью ptrace. Его использование выглядит таким образом:
sbom-tracer -p sbom-postprocessor.py <build...>
где <build...> — команда сборки, sbom-postprocessor.py — скрипт,
входящий в состав инструмента.
Этот инструмент имеет свои ограничения: работает только под Linux, и его
не получится применить, если в процессе сборки уже используется ptrace.
Артемий Гранат представит этот инструмент в докладе «Идентификация
реквизитов сборки через отслеживание системных вызовов» 21 июня на
конференции OS DAY 2024. Аннотация и тезиcы:
https://osday.ru/granat.html