>> Список архитектур, процессор + ядро OS которые обеспечивают __корректную__ работу с памятью со ссылками на исходники ядер?
> Такие гарантии реально получить разве что для тривиальных математически верифицивароных штуках типа какого ядра seL4, но даже там будет швах как только на этом захочется запустить какие-то реальные задачи, драйвера железа (умеющие в опасные операции by design) и все такое.Кореектную работу с памятью в плане W^X https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351
Корректная работа с памятью необходима для уровня C1 - минимум для ОС.
Речи о верификации, соотведствие уровню A, не идёт.
> Для более-менее крупной операционки такая верификация от и до - нереализуема из-за
> "комбинаторного взрыва", все варианты взаимодействий компонентов невозможно просчитать
> за разумные времена.
Там для верификации используются языки типа SPARK. Люди не верифицируют, это делает компьютер.
>> W^X это фундаментальный и принципиальный момент для безопасности архитектуры
> К сожалению некоторый софт в результате перестает работать или работает плохо. Как JIT в браузере допустим. Совсем это отключить можно, но за это придется очень дорого заплатить. Либо отказом от набитых JS сервисов (отличная идея но не для всех) либо крайне печальной скоростью загрузки многих сайтов (тоже не для всех).
JIT - зло и его надо выкинуть. ПО c JIT не использовать. Корпорашки специально внедряют JIT чтобы вы отключили безопасность с W^X!
> Теоретики от секурити забавные. Ну вот например, ваша пакость IIRC требует питон.
Не ставлю пользовательское ПО требующие интерпреаторы. Использую альтернативы.
> В нем уже есть такая чудная штука как eval(), суть обход W^X по смыслу. А еще ему вооооон те права - пофиг!
У меня патченый python, требование W^X строго соблюдает.
> Он поди еще и на noexec разделов забьет - это же интерпретер, он "читает" а не "выполняет" с точки зрения ос. С его фичами не так уж и важно что это интерпретируемый код. Если он в кучу сисколов и проч может, какая в общем то разница. Он даже сисколы может попытаться огревать левыми аргументами не сильно хуже нативного кода, да и половина эксплойтов у кидизов на питоне как раз. Отсутствие в системе питона поэффективней W^X пожалуй может быть, если у кидиза сплойт не запустился - прикольно, да? :)
У меня интерпретаторы заблокированы DAC:
$ getfacl /usr/bin/python3.6
getfacl: Removing leading '/' from absolute path names
# file: usr/bin/python3.6
# owner: root
# group: python
user::rwx
group::r-x
mask::r-x
other::---
> А конкретно вон то комбо CFLAGS иногда ломается с очень прикольными сообщениями компилера.
Чтоб не ломалось больше:
USE="pic pie"
>> Держи пример x86-32 где всё работает правельно:
> И чего мне с этим мусором делать предлагается? У меня давно уже нет x86-32.
Это эталонный пример правельно собраной OS с крутыми фичами, которых сегодня уже нет и небудет .
>> Ах не может архитектура W^X ?!!
> Это что за бред? В качестве "пруфа" приведены какие-то измышлизмы какого-то анона опеннета, с "претензиями" что битики прав R, W и X отдельные видите ли. Я не понимаю что операционке мешает "софтварно" форсить W^X между этими битиками при программировании прав MMU, если решено что должно быть именно так, поэтому заявление этого гражданина - технически некорректное.
Спроси разрабов RISC-V чем они бредели когда вместо бита запрета исполнения засунули ТРОЯН - бит изменения памяти: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#351
>> Теперь покажи мне пример дистра для RISC-V который может пройти эти тесты
> где вот эти тесты верифицируют корректность работы ос с памятью от и до и почему они истина в последней инстанции? Они чекают какие-то наиболее очевидные случаи, не более того.
Тесты: https://www.opennet.ru/openforum/vsluhforumID3/129886.html#309 показывают принадлежность архитектуры (процесор + ОС) к уровню C2. Этот уровень кроме прочего требует строгое W^X и для файлов на диске и для процессов в оперативке.
Да тесты W^X корректны. И если какойто *NIX их не проходит, то его архитектура уровень C не тянет.
> Я могу с десяток примеров некорректной работы с памятью за пределами этих тестов с наскока придумать.
Жду.
> Убедить драйвер или фирмвару железки DMA некорректные адреса допустим отдать - и MMU вообще в пролете. Он между процом и RAM и ничего не говорит что будет если это железка и DMA в рам обращаются.
Убрал по максимому DMA c ядра Linux. Далее стоит Linux запускать в https://muen.sk/
> А адреса для этого всего софт програмит. Верифицировать это?
Софт который програмит, flashrom можно проверять.
> Современный GPU по сложности - как большой город. Верифицируйте мне что на улице Пердяевка коллектор не протекает. А, его даже на карте города нет и про него все забыли? Ну вот все ваши гарантии на x86 - примерно столько же стоят. Ваши заявы о "безопасности" х86 стоят и того меньше.
С проприетарной фирмварью есть БОЛЬШАЯ проблема с безопасностью. Сегодня уже нельзя доверять подписаным BIOS/UEFI/Firmware
Корпорашки:
ASUS
JMicron
Realtek
подписывают вирусные BIOS/UEFI/Firmware (и список наверняка не полный).
Делаю сколько есть возможность и на чем есть возможность. Да работаю на проце x86_64 c NX и PAE. Заметь результат - выполнение тестов аудита; не работоспособность эксплоитов! Текущая система удолетворяет уровню C2, а могу и B3 сделать и даже чуть с A1.
Есть другой вариант безопасности - послушать эффективных менеджеров, меркетологов о модели угроз, накупить всякой дряни ничего не умеющей, понатрахать всем вокруг мозги и быть уверенным что все безопасно. Но, тесты аудита проходить не будут, а эксплоиты работать будут все. А почему так? Что не то с этой безопасностью? Что не так с моделью угроз? Ах да, надо быстро обновлятся (не проверяя обновления) и все срочно переписать на "самый безопасный" Rust!
> Приличный человек вообще постеснялся бы расписываться за поведение платформы с проприетарными фирмварами в самых критичных местах, подымаюших чего доброго платформу (ME, PSP) и обладающими правами супербога относительно x86 ядра - оно даже загружать этот ваш x86 не будет, если решит что ему что-то не нравится. То что оно по всей системе шариться может... ээээ... в современных системах оно ранний старт делает. И поэтому настоящий мастер - это вот оно. А вы так, в гостях.
LibreBOOT для всех приличных людей!
> И да, вы знаете, вон тот мастер-ключ, вшитый в фузы проца или чипсета, прописывающий гранд-ауторити которая реально получает ПОЛНЫЙ контроль над системой - на x86 вам "почему-то" вписать не дадут. Права бога Intel и AMD зарезервировали себе и делиться не собираются особо.
Раскажу большую военную тайну от Intel если проц и мамку покупать отдельно, то ключ Intel Boot Guard непрошит и если мамка и проц разрешают, то его иожно прошить при первом старте компа. Далее ключом Intel Boot Guerd надо подписать все компонента UEFI включая свой ключ UEFI для подписи загрузчика OS.
> А вот на ARM или RISCV - такого механизма или нет, или он не активен, или можно самому СВОЙ ключ вписать, став таким себе OEM.
> И как бы разглагольствовать о безопасности с чужим мастерключом дающим полный оверрайд все и вся в системе - забавно, конечно, но врядли очень секуно.
А ты лжец!
Я всех учу другому: https://www.linux.org.ru/forum/security/16550382?cid=16564526
> Тем более что ME и PSP так то еще и вызовы делать позволяют, а прошивки обновляемые и то что вы там что-то где-то реверснули ничего не говорит о том что будет через год в новых мамках и апдейтах биосов.
LibreBOOT !
> Libreboot это прекрасно но реально полный деблоб только для древнего железа. Для более современного упс.
Да, нагибают: https://www.opennet.ru/openforum/vsluhforumID3/130135.html#515
> А вот тривиальный ROM сабжа можно и прочекать. Через год он будет такой же. А дальше мой опенсорсный системный софт.
Теория говорит:
1 DAC
2 MAC
3 Верификация
И я прислушаюсь к мнению людей 60-70 годов. Не надо заниматся MAC не настроив DAC и не надо верифицировать софт не настроив MAC.
> И если мне надо хардварный root of trust, я какому-нибудь uboot даже могу наглухо readonly media организовать. И вот он таки чеканет мне что кернель и что там еще легитимные. И при этом единственной гранд-ауторити в системе я. А остальные идут в пень, и снять это реально разве что физическим доступом, и то не прямо сразу.
Глянь это: https://www.linux.org.ru/forum/security/16550382?cid=16567100
>> Странный взгляд на безопасность у вас с виртуализацией, MAC, .... и без настройки минимальных требований DAC.
> Есть бесконечное количество способов попытаться приблизиться к желаемой цели. ИМХО,
> 1) Хочу чтобы было просто и удобно мне, сложно и неудобно атакующему. Все что я делаю преследует оптимизацию вот того соотношения в мою пользу.
> 2) В более менее реальной системе векторов атак дочерта и больше. Все их предусмотреть малореально. А пользоваться примитивным микрокернелом, с примерно 0 задач и драйверов чтобы это реально верифицировано было - мне не катит. А чуть более фичасто, даже вот просто баш какой - и вот DHCP сервер получает у меня рут. Потому что баш фичастый а програмер сделал какую-то ерунду. А права памяти и страницы вообще не часть этой абстракции, внезапно. А вот рут у левого скрипта вполне реальный, это проблема.
> 3) Из пункта 2 следует что я предпочту иметь какой-то понятный мне план на случай если что-то все-таки пошло не так. Этот план опять же подразумевает что атакующий должен застрять и не достичь своих целей, получив минимум профита с атаки при максимуме возни.
> 4) В идеально надежные железки и системы я не верю. Современное железо и софт сложные, хрупкие, это правда жизни. Она неприятная но какая есть, странно ее игнорить. Предпочтение систем где я могу получить full view и гранд-ауторити - минимизация этого фактора. Это не про x86. Особенно современный.
> 5) Конопатинг 1 проблемы до идеала не затыкает более 9000 иных векторов атак. Атакующий может зайти на проблему с другого бока, наконец. Поэтому я не вижу смысла фиксироваться на 1 проблеме до упора, предпочитая иные подходы и соотношения, апгрейдящие эти соотношения в мою пользу сразу по ряду направлений.
PAX+GRSecurity собирают векторы атаки, и вырабатывают правельные и эффективные противодействия.
Векторов много. С появлением нового вектора, до оптимальной промышленной защиты проходит <5 лет разработки.
Затраты на внедрения GRSecurity минимальны, если архитектура проца правельная.
DAC как не крути все равно необходимо настроить.
Вот на изоляции с MAC можно экономить. Сервисы которые в инете торчат все-же изолировать придется.
Мне нравится в GNU/Linux подсистема Integrity https://www.linux.org.ru/forum/security/16550382?cid=16567177 безопасность даст, а настраивать много меньше чем у MAC, кроме того для уровня B2 она и так необходима.
> Как идеальная работа с памятью спасет меня от вон того JS который проламывается в контекст браузера и сканирует мой жесткий диск? А вот контейнер да с виртуалочкой подсунут этому негодяю очень печальный view, а урон будет так то здорово минимизирован. Ну, окей, он даунлоады браузера сопрет.
Да, DAC это не вытянет. Надо изоляцию каким-то из MAC..
> А каких там ключей ssh или ценных данных там чисто технически нету, например.
Настроить DAC необходимо как не крути: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
