Комментарии 14
Спасибо за статью. Сходу, навеяло - https://www.youtube.com/watch?v=Kqd7k5F-YBI
Красиво написано, но даже базовой возможности работать со смарт-картами с KasperskyOS нет, используйте в место этого пароли.
Хотел входить с защищенного терминала с KasperskyOS по RDP используя смарткарту, а такого функционала нет и сказали что и не будет, только пароль.
Сложилось впечатление, что хотя статья про "безопасную ОС" абсолютно всё в статье перекладывает безопасность на компилятор и пользователя. Единственное что связано с ОС в статье это запрет исполнения стека, но такое есть в любой современной ОС.
Также насчёт совета делить всё на процессы:
лучше бы у вас был один процесс с доступом в Сеть и один с доступом к платежам
Тогда нужно будет их одного процесса передать данные в другой, то есть процесс платежей должен... Доверять данным которые ему пришли ! А это уже самое настоящее разрушение безопасности
Добезопасились
Если есть возможность, используйте memory-safe-языки
С каких пор у нас Касперский работает по советам АНБ США? Не думал что от такой компетентной компании будет такая подмена безопасности выдуманным термином memory safe
Прямо по примерам из статьи:
- на "memory-safe" языке можно выделить fd и забыть его удалить, утечка ресурсов это не то от чего защищает "memory-safe"
- долгое время в Rust не было никакой защиты от стековерфлоу. Да и до сих пор на некоторых платформах нет, это валидный способ получить "ансаунд" (УБ) в safe расте до сих пор
Спасибо за развернутый комментарий. Попробую ответить также развернуто. (1) Статья не про безопасную ОС. Я много работала по процессам безопасной разработки и хотела поделиться опытом, как можно разрабатывать ПО, которое и включает все необходимые харденинги и при этом не будет терять в производительности. Сочувствую, если заголовок ввел вас в заблуждение. (2) Доверять данным можно только после проверки их подлинности и целостности, разделение на процессы не предполагает удаление криптографических проверок. Однако, если у вас есть процесс, которому дали права и на взаимодействие с сетевой картой, и на работу с базой платежей, то взлом такого процесса по сети будет более опасным сценарием, чем взлом процесса, который только принимает данные и парсит их. Да, данные в этот момент будут поддельными. Но arbitrary code execution в процессе с доступом к базе платежей не случится. Чтоб не быть голословной, у Bishop в computer security такой пример рассматривается. А еще это выполнение принципов конструктивной безопасности, которые есть и у нас в ГОСТ (ГОСТ Р 72118-2025), и в академической статье 75ого года (https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProtectionInfo_Saltzer.pdf). (3) То, что в американских правительственных структурах рекомендуют использовать ПО, написанное на memory-safe языках, не должно означать, что мы сознательно против этого. В CWE-top (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html) постоянно фигурируют oob, а это как раз spatial memory safety. При этом, безусловно, MSL (memory-safe-languages) не панацея. И Google не спешит свои старые компоненты на Rust переписывать, и мы недавно долго решались как обезопасить парсинг ELF-а и все же оставили его на Си (https://habr.com/ru/companies/kaspersky/articles/906458/). Но MSL для некоторых задач и правда снижает число уязвимостей
когда-то давно... в 1991м вроде... компилятор Turbo Pascal 6.0 любую переменную из сегмента данных инициализировал нулями. Вот что мешало так делать в Си по умолчанию? Сразу бы один вектор атаки отвалился.
Переменных на стеке и в heap-е значительно больше, чем из сегмента .data и .bss. Ну и неинициализированные данные из .bss все инициализируются нулями (https://refspecs.linuxfoundation.org/LSB_1.1.0/gLSB/specialsections.html). А у компилятора Си есть опция vars-autoinit, которая зануляет и стековые переменные и данные из кучи, но это снижает производительность (и именно поэтому не включено по умолчанию. и именно поэтому Си в стандарте нет обязательного зануления)
неинициализированные переменные
Не знаю, как у других, а у меня если включить -Wall -Werror, код не компилируется, если переменные используются до инициализации.
-Wuninitialized, который включен в -Wall, не очень точен по нашим наблюдениям. Коллега предложил пример, где ворнинг не стреляет, а проблема присутствует https://godbolt.org/z/bY898jq98. Более детальные сведения, наверное, только из исходников gcc/clang получится извлечь. По общим соображениям warning-и (wuninitialized) процессят во фронт-енде, а кодогенерация (vars-autoinit) в мидл-енде/бэк-енде.
int square(int num) {
int a;
if (1 == num) {
a = 1;
}
return a + 1;
}
Даже так компилирует!
А я почему-то был уверен, что он проверяет ветки исполнения. Вот тут неизвестный гражданин разъясняет, что и как.
На армах еще pointer authentication полезно использовать.
Как системщику остаться в живых: харденинг, который не убьет ваш перфоманс