> Список архитектур, процессор + ядро OS которые обеспечивают __корректную__ работу с
> памятью со ссылками на исходники ядер?Такие гарантии реально получить разве что для тривиальных математически верифицивароных штуках типа какого ядра seL4, но даже там будет швах как только на этом захочется запустить какие-то реальные задачи, драйвера железа (умеющие в опасные операции by design) и все такое.
Для более-менее крупной операционки такая верификация от и до - нереализуема из-за "комбинаторного взрыва", все варианты взаимодействий компонентов невозможно просчитать за разумные времена.
> W^X это фундаментальный и принципиальный момент для безопасности архитектуры
К сожалению некоторый софт в результате перестает работать или работает плохо. Как JIT в браузере допустим. Совсем это отключить можно, но за это придется очень дорого заплатить. Либо отказом от набитых JS сервисов (отличная идея но не для всех) либо крайне печальной скоростью загрузки многих сайтов (тоже не для всех).
> USE="pic pie"
> CFLAG="-fPIE -fPIC"
> Трудно, да...
Теоретики от секурити забавные. Ну вот например, ваша пакость IIRC требует питон. В нем уже есть такая чудная штука как eval(), суть обход W^X по смыслу. А еще ему вооооон те права - пофиг! Он поди еще и на noexec разделов забьет - это же интерпретер, он "читает" а не "выполняет" с точки зрения ос. С его фичами не так уж и важно что это интерпретируемый код. Если он в кучу сисколов и проч может, какая в общем то разница. Он даже сисколы может попытаться огревать левыми аргументами не сильно хуже нативного кода, да и половина эксплойтов у кидизов на питоне как раз. Отсутствие в системе питона поэффективней W^X пожалуй может быть, если у кидиза сплойт не запустился - прикольно, да? :)
А конкретно вон то комбо CFLAGS иногда ломается с очень прикольными сообщениями компилера. Хотя если программа не компильнется, хакеры обломятся ее хакнуть, вот тут спора нет.
> Держи пример x86-32 где всё работает правельно:
И чего мне с этим мусором делать предлагается? У меня давно уже нет x86-32.
> Ах не может архитектура W^X ?!!
Это что за бред? В качестве "пруфа" приведены какие-то измышлизмы какого-то анона опеннета, с "претензиями" что битики прав R, W и X отдельные видите ли. Я не понимаю что операционке мешает "софтварно" форсить W^X между этими битиками при программировании прав MMU, если решено что должно быть именно так, поэтому заявление этого гражданина - технически некорректное. А то что ядро
> Теперь покажи мне пример дистра для RISC-V который может пройти эти тесты
Какой прыткий анон. Сам на себя сослался 100500 раз, почему-то решил что это кому-то что-то доказывает, и если уж мы об этом самом, где вот эти тесты верифицируют корректность работы ос с памятью от и до и почему они истина в последней инстанции? Они чекают какие-то наиболее очевидные случаи, не более того.
Я могу с десяток примеров некорректной работы с памятью за пределами этих тестов с наскока придумать. Убедить драйвер или фирмвару железки DMA некорректные адреса допустим отдать - и MMU вообще в пролете. Он между процом и RAM и ничего не говорит что будет если это железка и DMA в рам обращаются. А адреса для этого всего софт програмит. Верифицировать это? Современный GPU по сложности - как большой город. Верифицируйте мне что на улице Пердяевка коллектор не протекает. А, его даже на карте города нет и про него все забыли? Ну вот все ваши гарантии на x86 - примерно столько же стоят.
> Где аудит и результаты тестов? Без них для меня у конкретно RISC-V меньше всего безопасности.
Ваши заявы о "безопасности" х86 стоят и того меньше. Приличный человек вообще постеснялся бы расписываться за поведение платформы с проприетарными фирмварами в самых критичных местах, подымаюших чего доброго платформу (ME, PSP) и обладающими правами супербога относительно x86 ядра - оно даже загружать этот ваш x86 не будет, если решит что ему что-то не нравится. То что оно по всей системе шариться может... ээээ... в современных системах оно ранний старт делает. И поэтому настоящий мастер - это вот оно. А вы так, в гостях.
И да, вы знаете, вон тот мастер-ключ, вшитый в фузы проца или чипсета, прописывающий гранд-ауторити которая реально получает ПОЛНЫЙ контроль над системой - на x86 вам "почему-то" вписать не дадут. Права бога Intel и AMD зарезервировали себе и делиться не собираются особо. А вот на ARM или RISCV - такого механизма или нет, или он не активен, или можно самому СВОЙ ключ вписать, став таким себе OEM. И как бы разглагольствовать о безопасности с чужим мастерключом дающим полный оверрайд все и вся в системе - забавно, конечно, но врядли очень секуно. Тем более что ME и PSP так то еще и вызовы делать позволяют, а прошивки обновляемые и то что вы там что-то где-то реверснули ничего не говорит о том что будет через год в новых мамках и апдейтах биосов.
Libreboot это прекрасно но реально полный деблоб только для древнего железа. Для более современного упс. А вот тривиальный ROM сабжа можно и прочекать. Через год он будет такой же. А дальше мой опенсорсный системный софт. И если мне надо хардварный root of trust, я какому-нибудь uboot даже могу наглухо readonly media организовать. И вот он таки чеканет мне что кернель и что там еще легитимные. И при этом единственной гранд-ауторити в системе я. А остальные идут в пень, и снять это реально разве что физическим доступом, и то не прямо сразу.
> Странный взгляд на безопасность у вас с виртуализацией, MAC, .... и
> без настройки минимальных требований DAC.
Есть бесконечное количество способов попытаться приблизиться к желаемой цели. ИМХО,
1) Хочу чтобы было просто и удобно мне, сложно и неудобно атакующему. Все что я делаю преследует оптимизацию вот этого соотношения в мою пользу.
2) В более менее реальной системе векторов атак дочерта и больше. Все их предусмотреть малореально. А пользоваться примитивным микрокернелом, с примерно 0 задач и драйверов чтобы это реально верифицировано было - мне не катит. А чуть более фичасто, даже вот просто баш какой - и вот DHCP сервер получает у меня рут. Потому что баш фичастый а програмер сделал какую-то ерунду. А права памяти и страницы вообще не часть этой абстракции, внезапно. А вот рут у левого скрипта вполне реальный, это проблема.
3) Из пункта 2 следует что я предпочту иметь какой-то понятный мне план на случай если что-то все-таки пошло не так. Этот план опять же подразумевает что атакующий должен застрять и не достичь своих целей, получив минимум профита с атаки при максимуме возни.
4) В идеально надежные железки и системы я не верю. Современное железо и софт сложные, хрупкие, это правда жизни. Она неприятная но какая есть, странно ее игнорить. Предпочтение систем где я могу получить full view и гранд-ауторити - минимизация этого фактора. Это не про x86. Особенно современный.
5) Конопатинг 1 проблемы до идеала не затыкает более 9000 иных векторов атак. Атакующий может зайти на проблему с другого бока, наконец. Поэтому я не вижу смысла фиксироваться на 1 проблеме до упора, предпочитая иные подходы и соотношения, апгрейдящие эти соотношения в мою пользу сразу по ряду направлений.
Как идеальная работа с памятью спасет меня от вон того JS который проламывается в контекст браузера и сканирует мой жесткий диск? А вот контейнер да с виртуалочкой подсунут этому негодяю очень печальный view, а урон будет так то здорово минимизирован. Ну, окей, он даунлоады браузера сопрет. А каких там ключей ssh или ценных данных там чисто технически нету, например.
