The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Let's Encrypt перешёл к проверке с использованием разных под..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Let's Encrypt перешёл к проверке с использованием разных под..." +/
Сообщение от Аноним (153), 25-Фев-20, 10:47 
> Нет. Приоритетные цели -- это _потенциальные_ разработчики профайлеров, компиляторов...
> и далее по списку. В приоритете любой Васян, которому приспичит поковырять
> недра компилятора, или написать свой компилятор, или свой отладчик, или гипервизор.

Согласен.

> Любой такой Васян может напороться на странность, забить на свой проект
> компилятор-just-for-fun и заняться ковырянием непонятности, на которую он напоролся.

А вот в это верится с большим трудом.

> Тут ты сильно всё упрощаешь. Невозможно составить список всех продуктов.
>У них при этом могут быть самописные утилиты. Любые из этих утилит могут не перекомплироваться годами

Список всех самодельных и недодельных утилит действительно составить нельзя. Зато можно насоздавать заготовок таких утилит на гитхабе. Разумеется, это не гарантирует, что этими заготовками захотят пользоваться. И опять же, для работы никто не будет использовать самоделку, если есть готовая утилита и суть работы не есть в создании самоделки. Если чего-то не хватает, то скорее пропатчат готовую опенсорсную, и на неё опять же наложется патч.

>Разработчики вовсе не сидят все на одинаковых компиляторах и тем более на одинаковых версиях компиляторов.

Версий конечное число и друг от друга они мало отличаются. Большинство сидит на версиях из пакетов дистров, потому что пересобирать часами gcc/llvm самому мало кому упёрлось.


>Разработчики могут работать с нескольких машин -- ноут, домашний десктоп, десктоп на работе, сборочный сервер, и на всех этих машинах могут стоять разные версии софта. Уже здесь возникает такой зоопарк, что проблема возникнет не на этапе составления списка софта, а уже на этапе составления списка возможных режимов провала, которые надо учесть разрабатывая схему инфецирования.

Вполне возможно. Но это зависит от определения провала.

> А не надо никакой регулярности. Достаточно чтобы в год писалась бы сотня наколенных профайлеров. И даже не важна дальнейшая судьба этих профайлеров, даже не важно чтобы из них получалось что-нибудь завершённое, даже неудачная попытка написать профайлер может вскрыть странное поведение компилятора.

Согласен. Скрыть кампанию по массовому инфицированию скорее всего не получится даже при ресурсах АНБ.

> На простых тестовых программах ты можешь проверить, что твой профайлер делает именно то, что нужно. Но ты замучаешься придумывать тестовые программы, чтобы покрыть все edge cases, а если ты прогонишь свой профайлер через реалистичную нагрузку, вот тут эти самые edge cases и полезут изо всех щелей. Что позволит тебе написать тестовые программы, демонстрирующие эти edge cases.

Аргумент принят.

> Тебе придётся пропатчить все файрволлы. Для некоторых из них у тебя не будет сорцов.

Для файроволов можно патчить не сам файрвол, а механизм захвата. Для ОС можно пропатчить ядерные функции для работы с ФС: при вызове не из загрузчика вырезать маркированный код. Правда это открывает способ обхода: сделать кастомный загрузчик. Но если предположить, что это  этап "раскрутки" системы удастся, то получить исходники софта уже будет не проблема. А пропатчить их всех - это исключительно вопрос финансирования и количества специалистов достаточного уровня, готовых работать на такие организации.

Обновления не должны быть большой проблемой - модифицировать придётся относительно редко изменяемые части. Вроде считывания с диска.

> Я не исследую безопасность, но я нечаянно могу напороться на дыру в безопасности.

Абсолютно верно. Далее всё зависит от вашей решимости ковырять конкретно эту дыру и от ресурсов, требуемых на это.


> 1. Сложность проекта такого рода оценивается количеством грабель, на которые можно наступить,
> и я не уверен, что хоть одна из организаций, которое такое
> по карману, когда-нибудь сталкивалась с таким количеством граблей.

Я тоже. Но я - пессимист.

> 2. На манхеттенский проект ты смотришь, но видишь не то, что нужно.
> Манхеттенский проект было гораздо проще сокрыть, нежели инфекцию всех компиляторов, и
> тем не менее это не удалось.

Манхэтаннский проект сам по себе и его цели было невозможно скрыть. Но было возможно скрыть результаты его работы. Но это тоже сфейлили благодаря советским шпионам.


> 3. На компилятор и возможность его компрометации не всем нacpaть. Тут иногда
> проскакивают новости о компиляторе C, написанном на схеме, которая написана на
> C. Мне лень искать ссылки, но там вся фишка в том,
> чтобы сделать bootstrappable компилятор C. Как ты думаешь, зачем люди этим
> заняты? А воспроизводимые сборки софта -- это зачем, как ты думаешь?
> Одна из причин заниматься и тем и этим -- избавиться от
> влияния существующего компилятора.

Вот это - очень хороший и правильный проект. Но реально заработает только если он будет self-hosted. То есть если есть доверенная железка, типа fpga, на которой софт-процессор, на котором крутится bare metal компилятор, получающий ввод с доверенных железок типа самодельного сканнера, подключённого к gpio, и выводящий на магнитную ленту.

Одна проблема - дорого.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Let's Encrypt перешёл к проверке с использованием разных под..., opennews, 23-Фев-20, 11:05  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру