Нет оснований считать, что сертификат ФСБ подтверждает какую-то безопасность, если в модели угроз основной угрозой являются ФСБ и другие госслужбы.
Модель угроз определяет для себя эксплуатирующая организация. Если в Вашей модели угроз основной угрозой является ФСБ и другие госслужбы (как, например, в ЦРУ), то Вам действительно необходимо использовать другие СЗИ.
Сертификат ФСБ может означать… наличие бэкдора
Сертификат ФСБ не может означать наличие бэкдора, так как сертификация направлена в том числе на их выявление. Само ФСБ в сертификации конкретного продукта участвует только при выдаче экспертного заключения на отчетные материалы, которые формирует специализированная организация. Специализированная организация хоть и может давать замечания по коду, они могут быть связанны только с невыполнением конкретных пунктов (указываются в замечаниях) регламентирующих документов, в которых про бэкдоры ни слова. Исходники правит только разработчик, бинарники собирает тоже он. Мне кажется, что у вас есть явное недопонимание процессов сертификации.
Сертификат ФСБ может означать… наличие хороших личных отношений
Если вам известны конкретные факты нарушений, просьба обратиться с ними в прокуратуру. Если нет, то вы занимаетесь либо политикой, либо словоблудием. Первое на ресурсе запрещено, второе просто глупо.
Не очень понимаю при чем тут репутация, доверие и какая-то выгода.
ФСБ является государственным регулятором. Они выпускают регламентирующие документы. Например, стандарт шифрования, методические указания по его применению, требования безопасности к СЗИ, методики исследования ПО, процедуры аккредитации и требования к компаниям-лицензиатам и т.д. Конечно, часть этих документов содержит информацию, составляющую государственную тайну, но это не значит, что она не доступна независимым экспертам, которым она необходима.
Сертфикат ФСБ подтверждает, что ПО прошло исследование на соответствие конкретному набору требований безопасности, по конкретным методикам в организации, удовлетворяющей конкретным аттестационным требованиям.
Ничто не мешает независимому эксперту (например Вам) ознакомиться с данными регламентирующими документами (естественно получив соответствующий допуск).
Например, наш стандарт шифрования (ГОСТ Р 34.12-2015), опубликованный на сайте ТК-26, проходил множество независимых проверок. В интернете полно статей на данную тему.
Считаю, что эмоции и политика в данном вопросе не уместны. Это вопрос исключительно технический.
Думаю, что там сквозное шифрование, а при покупке системы, вы покупаете и серверное ПО, которое разворачиваете у себя. Потом идет процедура аттестации АИС и т.д.
На сколько мне известно, 8 центр ФСБ генерирует ключи только для высоких классов сертификации, использующихся для защиты государственной тайны. Если государству принадлежит тайна, то ключи генерирует представитель государства, т.е. ФСБ.
Все КС1, КС2, КС3 системы пользуются ключами, генерирующимися на местах эксплуатации. ФСБ эти ключи никак получить не может, если вы их сами туда не пошлете :) Но шутку я оценил.
Именно потому, что у меня есть понимание данной системы, я доверяю ей кардинально больше, чем большинству «независимых аудитов». Вы сталкивались с сертификацией СЗИ в ФСБ РФ? Чем вызвано ваше недоверие к сертификатам ФСБ?
Написано, что имеет комплект сертификатов. Если речь про сертификат ФСБ, то независимый аудит безопасности был проведен одной из аккредитованных сертификационных лабораторий (специализированной организацией), затем отчетные материалы были изучены 8 центром ФСБ и было получено положительное заключение, а только потом ЦЛСЗ оформили сертификат.
Тогда можете пояснить, что вы имеете в виду? Просто я с ARM много работал, и, по всей видимости, просто не понял про что именно идет речь.
Может про переключение стеков при обработке прерываний/исключений?
Если вам не сложно, можете дать ссылку, где почитать?
А то я знаю, что такое Program Status Register, а вот что за MSR/PSR стэки и что за сброс PC — не слышал даже
Шелл-код написан под конкретный процесс, а не под абстрактный. Он знает всю структуру стека, так как знает какую функцию эксплуатирует и где в программе она вызывается.
Правильно, можно и делить. Просто до того как я выяснил, что syscall у них все равно есть, обсуждалось переключение контекстов через разные места.
However, potential kernel bugs can be mitigated somewhat by enforcing that each kernel entry be made only from the proper vDSO code
— не корректно. В наших процессорах (x86/ARM) нет способа проверить какой код до этого исполнялся, он историю переходов не хранит. В нем есть только текущее состояние. Поэтому тот факт, что PC указывает на какое-то смещение внутри vDSO совершенно не означает, что перед этим отработал код самого vDSO, а не зловред, который подготовил в регистрах/памяти значения для атаки на ядро.
Судя по всему, проверяют они тупо PC (RIP) на иструкции syscall.
On entry to the kernel for a system call, the kernel examines the PC location of the syscall instruction on x86 (or equivalent instruction on other machines). It subtracts the base address of the vDSO code recorded for the process at vmar_map() time from the PC, and passes the resulting offset to the validity predicate for the system call being invoked.
Это скрыть нереально. Шелл-код будет исполнятся в контексте реального потока реальной программы вызывающей ядро. На стеке лежит гора разных указателей, через которые можно выползти на vDSO.
ASLR — это способ борьбы с передачей управления на шелл-код/ROP. Если управление уже у него, ASLR, как и vDSO с рандомным адресом ничем не поможет.
Разницы между переключением контекста через syscall или pagefault на выделенной страничке я не вижу.
Так во всех современных ОС есть ASLR/аналоги.
Тогда мне не понятны выкладки про «ограниченный vDSO». Чем отсутствие кода в самом vDSO поможет от вызова «запрещенных» системных вызовов?
Например: можно запретить драйверам порождать дочерние процессы или обрабатывать проецирование областей MMIO.
Т.е. ядро с ядром у них тоже через vDSO общается? Это как? Или они драйвера в user mode утащили? А что с прерываниями делают?
update: нашел вашу ссылку, поглядел. Да, правда в user mode. Видимо правда все будет медленно но верно :)
Извините, а можно подробнее про «запрет прямого вызова»? ИМХО, валидация адреса возврата ничего не дает. Ничего не мешает сформировать какие-то левые аргументы, положить на стек свой адрес возврата и тупо прыгнуть на корректный адрес в образе vDSO, который делает syscall. Доказать, что перед этим отработал «код системной библиотеки» не получится.
Согласен. Какая-то странная логика. AES аппаратно ускоряется на любом современном проце. Если надо быстро — бери его.
Если хочется поиграть в сертификацию («православие») и Российскую криптографию, то есть ТК-26. Даже если (что очень сомнительно) криптоанализ покажет, что данный алгоритм «торт», пока не протащишь его через ТК-26, смысла в нем никакого.
Модель угроз определяет для себя эксплуатирующая организация. Если в Вашей модели угроз основной угрозой является ФСБ и другие госслужбы (как, например, в ЦРУ), то Вам действительно необходимо использовать другие СЗИ.
Сертификат ФСБ не может означать наличие бэкдора, так как сертификация направлена в том числе на их выявление. Само ФСБ в сертификации конкретного продукта участвует только при выдаче экспертного заключения на отчетные материалы, которые формирует специализированная организация. Специализированная организация хоть и может давать замечания по коду, они могут быть связанны только с невыполнением конкретных пунктов (указываются в замечаниях) регламентирующих документов, в которых про бэкдоры ни слова. Исходники правит только разработчик, бинарники собирает тоже он. Мне кажется, что у вас есть явное недопонимание процессов сертификации.
Если вам известны конкретные факты нарушений, просьба обратиться с ними в прокуратуру. Если нет, то вы занимаетесь либо политикой, либо словоблудием. Первое на ресурсе запрещено, второе просто глупо.
ФСБ является государственным регулятором. Они выпускают регламентирующие документы. Например, стандарт шифрования, методические указания по его применению, требования безопасности к СЗИ, методики исследования ПО, процедуры аккредитации и требования к компаниям-лицензиатам и т.д. Конечно, часть этих документов содержит информацию, составляющую государственную тайну, но это не значит, что она не доступна независимым экспертам, которым она необходима.
Сертфикат ФСБ подтверждает, что ПО прошло исследование на соответствие конкретному набору требований безопасности, по конкретным методикам в организации, удовлетворяющей конкретным аттестационным требованиям.
Ничто не мешает независимому эксперту (например Вам) ознакомиться с данными регламентирующими документами (естественно получив соответствующий допуск).
Например, наш стандарт шифрования (ГОСТ Р 34.12-2015), опубликованный на сайте ТК-26, проходил множество независимых проверок. В интернете полно статей на данную тему.
Считаю, что эмоции и политика в данном вопросе не уместны. Это вопрос исключительно технический.
Все КС1, КС2, КС3 системы пользуются ключами, генерирующимися на местах эксплуатации. ФСБ эти ключи никак получить не может, если вы их сами туда не пошлете :) Но шутку я оценил.
Может про переключение стеков при обработке прерываний/исключений?
А то я знаю, что такое Program Status Register, а вот что за MSR/PSR стэки и что за сброс PC — не слышал даже
И все равно какой код до этого выполнялся узнать нельзя, только откуда был последний call. Сделайте jmp (b) :)
Мы с вами говорим про малоизвестную, нераспространенную и специализированную ОС. В моем понимании, все ожидаемые атаки будут целевыми.
Правильно, можно и делить. Просто до того как я выяснил, что syscall у них все равно есть, обсуждалось переключение контекстов через разные места.
— не корректно. В наших процессорах (x86/ARM) нет способа проверить какой код до этого исполнялся, он историю переходов не хранит. В нем есть только текущее состояние. Поэтому тот факт, что PC указывает на какое-то смещение внутри vDSO совершенно не означает, что перед этим отработал код самого vDSO, а не зловред, который подготовил в регистрах/памяти значения для атаки на ядро.
Судя по всему, проверяют они тупо PC (RIP) на иструкции syscall.
ASLR — это способ борьбы с передачей управления на шелл-код/ROP. Если управление уже у него, ASLR, как и vDSO с рандомным адресом ничем не поможет.
Разницы между переключением контекста через syscall или pagefault на выделенной страничке я не вижу.
Тогда мне не понятны выкладки про «ограниченный vDSO». Чем отсутствие кода в самом vDSO поможет от вызова «запрещенных» системных вызовов?
Т.е. ядро с ядром у них тоже через vDSO общается? Это как? Или они драйвера в user mode утащили? А что с прерываниями делают?
update: нашел вашу ссылку, поглядел. Да, правда в user mode. Видимо правда все будет медленно но верно :)
Если хочется поиграть в сертификацию («православие») и Российскую криптографию, то есть ТК-26. Даже если (что очень сомнительно) криптоанализ покажет, что данный алгоритм «торт», пока не протащишь его через ТК-26, смысла в нем никакого.