• 1 Post
  • 34 Comments
Joined 57 years ago
cake
Cake day: January 1st, 1970

help-circle
  • Увы, не знаю, что такое sendxml/sendjson.

    Большая часть этих идей существует с времён FidoNet, когда мейлер, тоссер, редактор - отдельные программы. Сортировка и автопересылка писем там есть.

    Если рассматривать классический email поверх SMTP, то есть git-send-email, а большинство MTA поддерживают .forward, откуда можно вызвать скрипт для разбора таких писем и применению патчей (git-am) из них в remote-ветки. Получателем таких писем может быть mailing list, рассылающий широковещательно письма, как это часто происходит в крупных opensource-проектах (например в ядре Linux).

    Отсутствие прямой связи сейчас может и выглядит комично, но offline-протоколы всё ещё востребованы. До сих пор на Земле есть места, где связь очень так себе или появляется не всегда, а с расширением на космические масштабы проблема связи вообще становится неизбежной. Тот же TCP с дефолтными таймаутами и congestion control до Марса просто сломается.

    Из интересных распределённых систем хранения (и поиска) стоит отметить IPFS, Tahoe-LAFS, YaCy. Я не знаю, как (и вообще ли) сделана в них защита от плохих участников - что случится, если кто-то будет отвечать медленно и/или неправильно.

    Другая проблема в отсутствии общепринятого протокола для обмена статически типизированных данных между программами - большинство утилит командной строки в unix-пободных системах потребляют и порождают plain text, что не всегда удобно для сложных композиций. Некоторые умеют JSON, но нигде не описывают схему. Некоторые - XML. В корпорациях и модных cloud-native программах любят Protobuf (и gRPC). Для чтения людьми хороши recfiles - если бы мне нужно было выбрать формат описания артефактов для большой сети друзей, я бы начал именно с него.

    Ещё интересный вопрос - что делать, если индексы очень большие, и вынуждают поисковую систему не скачивать сам индекс, а распределять пользовательские запросы на все системы, где потенциально могут быть искомые данные - насколько богатые запросы стоит разрешать? В мире веба похожую задачу решает GraphQL - он позволяет запрашивать, изменять или подписываться на изменения коллекций данных на удалённой машине и поддерживает фильтрацию и по вложенным полям, что обычно транслируется в запросы к локальной реляционной или объектной базе.


  • И если kernel.org в этот транспорт не умеет то что будет?

    То же самое, если попытаться связаться с тобой по телефону, если телефона у тебя никогда не было. Я про то, что git - это штука, которая синхронизирует объекты и ветки на двух машинах, если они уже смогли как-то связаться друг с другом, и git не очень интересно, как именно они это сделали.

    Так же и ты можешь прочитать моё сообщение, даже если linuxtalks.co перестанет существовать. Возможно, я найду какой-то другой способ связаться с тобой, например напишу email или ещё как-то. От этого твоя способность понимать текст никак не поменяется.

    это мета-команда которая потом передаёт управление в какой либо специализированный блок

    Проблема не в том, из одного блока состоит программа или из разных. systemd ведь тоже не из одного бинаря состоит. Проблема начинается, когда авторы комплекта программ пытаются навязать одновременно и mechanism, и policy, лишая пользователя гибкости.

    То есть если сделать git search, который делает всё, что ты предлагаешь, то придётся повторить всю эту работу для остальных задач, где полезен распределённый поиск - сделать ещё и youtube-dl search, wget --search, apt search и так далее.

    Вместо этого лучше взять отдельно транспорт, отдельно систему разрешения имён, отдельно сервер метаданных, отдельно индексатор. Тогда можно будет простым скриптом в git hook вытащить информацию об объектах/ветках/коммитах и передать её в программу, накапливающую локальные метаданные. Другая программа сможет рассказать моим соседям (по DHT или ещё как-нибудь) про всё, чем я готов поделиться. И уже поверх этих компонентов можно делать глобальный поиск.


  • git децентрализован в том смысле, что он может функционировать в сети равноправных участников. Ему всё равно, как работает DNS-резолвер и IP-маршрутизация в твоей системе. Можешь даже свой транспорт положить в /usr/libexec/git-core/git-remote-* или сделать git clone fd::7,8/astral:linux, предварительно подключив файловые дескрипторы 7 и 8 к астральному транспорту - лишь бы с другой стороны был запущен git upload-pack linux.

    Участники полностью равноправны - любой может запускать как fetch (pull), так и push.

    Команды git search в системе, которая следует парадигме “выполняй одну задачу и делай это хорошо” быть не должно. Вместо неё стоит реализовать git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1).

    git clone kernel.org:linux в текущей реализации - это краткая форма git clone ssh://kernel.org/linux, а git clone kernel.org/linux означает “сделай клон из локальной директории ./kernel.org/linux”. В первом случае можно обеспечить себе желаемый уровень децентрализации с помощью ProxyCommand %h %p в ~/.ssh/config - можно вынести в отдельную программу любую, даже самую наркоманскую логику для установки связи через децентрализованный астрал с хостом %h.

    Писать письма не обязательно через SMTP с резолвом доменов через MX-записи централизованной системы доменных имён с корнями *.root-servers.net - любой элемент этой цепочки можно заменить, если хочется избежать блокировки. Или сразу все, используя системы типа store-and-forward, например NNCP - тогда будет не важно, через какой канал пришёл пакет, главное, чтобы у него была правильная подпись, которой ты доверяешь. NNCP может работать даже поверх флоппинета или флешки, замурованной в общедоступной стене - наличие возможности для работы интерактивного протокола необязательно.

    Если он децентрализован то он всё это должен уметь по дефолту без настроек, патчей и всяких костылей.

    Если запихать все эти возможности в сам git, то это и будет огромным костылём. Такие задачи должны решаться на уровне дистрибутива, который соберёт вместе все компоненты, обеспечивающие согласованную работу децентрализованной системы.

    Наиболее важные, на мой взгляд, свойства unix-подобных систем (из списка The Art of Unix Programming, Eric Steven Raymond):

    Rule of Modularity: Write simple parts connected by clean interfaces.

    Rule of Composition: Design programs to be connected to other programs.

    Rule of Separation: Separate policy from mechanism; separate interfaces from engines.


  • Децентрализованность это когда каждый клиент является одновременно и сервером.

    Но ведь так и есть. “Отправить pull-request” в своём оригинальном значении означает “написать письмо с просьбой сделать pull со своего хоста”, а не “запросить в централизованной системе слияние двух веток”.

    Для git сервер часто запускается по требованию клиента, используя sshd в качестве безопасного транспорта и механизма запуска.



  • Своя ОС в зависимости от того, насколько закручены гайки у новой платформы либо просто не запустится, либо не сможет использовать интернет-сервисы, так как не пройдёт аттестацию. Сейчас для подавляющего большинства людей компьютер бесполезен, если не может взаимодействовать с популярными сервисами.

    А для документооборота хватит и старых компьютеров, в которых нет таких защит - можно даже не писать свою ОС. Если учесть все компьютеры, которые можно отремонтировать, то запаса того, что уже есть в стране, хватит надолго. Ну может ещё пару законов принять, чтобы старые машины не вывозили, не выкидывали и ремонтировали.

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


  • У меня как-то коллега взял модем, чтобы экономить на парковке. Он снимал квартиру в жилом комплексе, шлагбаум на въезд в который открывается по звонку, а бесплатно в базу можно добавить один городской номер. Поэтому он соорудил конструкцию из почтового клиента и звонилки, сделал себе специальный ящик, отправка письма на которого приводила к открытию доступа на парковку.

    С другим коллегой мы делали BBS для музея - тут уже потребовалось два модема и VoIP-терминал с двумя FXS.

    Если достать к модему ещё и факсовый аппарат, то можно сделать из него плохое МФУ. Некоторые факсы печатают на термобумаге - возможно, эта особенность сделает такую конструкцию интересной. Из устройства, которое печатает на термобумаге можно сделать syslog sink с аппаратным logrotate - склеить ленту в кольцо и пропустить через холодильник. Но это уже наркомания какая-то.


  • подтверждать через интернет право использовать компьютер

    То есть задача, которую мы решаем - научиться обезвреживать или обманывать (несуществующий пока) механизм удалённой аттестации, который является частью прошивки и работает до загрузки ОС?

    Увы, тогда предложенная схема не выглядит полезной. Если мы умеем легко находить коллизии для SHA1 и SHA256 одновременно, то куда перспективнее переписать BG policy, чем портить случайный модуль, превращая его в загрузчик непонятно чего - портить критичные для работы платформы модули мы не можем, значит для разлоченного биоса почти не останется работы - память, LPC и PCI уже подняты, сложных задач особо не осталось. Ну можно туда поддержку USB, NVMe и ext4 положить, вместе с красивым boot device selection.

    Не очень понятно, как “NATO/AUKUS” будет принимать решение, разрешить какой-то отдельно взятой машине работать или нет. Умельцы начнут продавать роутеры, которые через прокси пойдут до недружественной страны, а оттуда уже ходить в сервер аттестации. Если операторы этих прокси будут достаточно мотивированы, то выключить их все будет достаточно сложно - с пиратской бухтой до сих пор справиться не могут.

    Если бы мне нужно было сделать механизм защиты, запрашивающий подтверждение на право использовать компьютер, и у меня были бы огромные ресурсы и влияние, то я бы не стал использовать компоненты прошивки в качестве основы - я бы возложил на них вспомогательные функции, затрудняющие взлом. План примерно такой:

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

    2. встраиваем в эти ОС механизм удалённой аттестации - его задачей будет доказать серверу, что никакие важные компоненты запущенной ОС не были подвержены неавторизованной модификации;

    3. расширяем все популярные сетевые протоколы так, чтобы куку, выдаваемую аттестационным сервером, можно было передавать вместе с сетевыми запросами;

    4. ломаем совместимость новых ОС со старым железом;

    5. меняем поведение популярных интернет-сервисов так, чтобы они пессимизировали пользователей, которые не проходят аттестацию - это вынуждает их постепенно перейти на новое железо и новую ОС;

    6. когда достаточное число пользователей перестали использовать старые системы, дёргаем рубильник - отказываем в обслуживании тем, кто нам не нравится.

    Важный код крутим в SGX, к средствам администрирования и разработки допускаем только авторизованный персонал, аудио/видео пропускаем через PAVP и показываем только на HDCP-мониторах (чтобы из старых компьютеров не делали терминалы к новым).

    Ещё надо IPv6 и P2P запретить, каналы для потребителей сделать ещё более ассиметричными, а запуск серверного ПО объявить лицензируемой деятельностью, требующей регистрации.


  • Тогда я совсем не понимаю смысла этой затеи.

    Когда вендор собирает прошивку и конфигурирует платформу, он решает, какие диапозоны адресов флеша он хочет защищать. Для каждого диапозона считаются SHA1 и SHA256, которые записываются в табличку. Эта табличка подписывается ключом, который подписывается ещё одним ключом, который прошивается в efuse.

    Получается, что есть области флеша, которые менять можно - там обычно хранятся настройки, перезаписываемая часть файловой системы ME, MAC-адрес и кастомизируемая часть прошивки - всякие логотипы и картинки - те самые незначительные части, которые можно менять, как угодно, но при этом chain of trust не сломается, в критический путь загрузки ничего лишнего не встанет. И есть области флеша, которые защищены - бутблок, SEC core, прочие исполняемые модули. Если поменять, то ACM это заметит и что-то (в зависимости от настроек) сделает - например, отключит платформе питание.

    Внутри той части, которая защищена, есть модули, без которых конечному пользователю в общем-то легко обойтись - их как раз dxe-cleaner и выкидывает. Предположим, что каким-то удивительным образом мы научились записывать туда такой мусор, что случилась коллизия, и SHA1 с SHA256 не поменялись.

    А какая конечная цель? Что будет находиться в том неподписанном коде, который хочется запустить? DXE-драйвер для какой-нибудь новой файловой системы или блочного устройства UEFI и так умеет грузить с внешних носителей. coreboot запустить так не получится - платформа уже проинициализирована. Разве что буткит можно какой-нибудь подкинуть.



  • А какую задачу хочется решить таким сложным способом?

    Чем-то похожим занимается вот эти ребята, но не с целью поиска коллизий, а чтобы выкинуть потенциально дырявые блобы, затратив на это меньше усилий, чем на честное портирование своей прошивки: https://github.com/linuxboot/fiano#dxe-cleaner

    Железо уже давно умеет проверять весь критический путь. Если защита настроена правильно (по рекомендациям от Intel), то в прошивке нет каких-то “незначительных” кусков, которые можно менять так, чтобы это влияло на работу системы. Весь “важный” код участвует в вычислениях, проверяющих подпись. В зависимости от настроек и используемых технологий похаченная система либо вовсе не загрузится, либо не пройдёт аттестацию.

    Неломаемых систем, как известно, не бывает, поэтому дыры находят и патчат, а новые версии прошивок выжигают efuse, не давая совершить атаку даунгрейдом. Бывают косяки в ROM, их можно поправить только заменой CPU, но дружественного к пользователю способа их эксплуатации я не знаю - там потребуется железо типа SPIspy, которое может поменять флешку на злодейскую, что в первый раз в момент вычисления подписи отдаст чистые данные, а потом из неё читается другая прошивка. Google и Apple решают такие проблемы добавлением нового чипа, который они могут обновлять дешевле и быстрее, чем Intel патчит свои дыры.

    На декстопных материнках почти никогда не включают никакие защиты. Можно взять программатор и зашить всё, что хочется в SPI flash. В ноутах часто включен BootGuard, и такое проделать уже не получится без замены PCH. System76 продаёт ноуты с ненастроенной защитой - можно прошить свой ключ.


  • помимо ядра Linux есть куча возможного непредугадываемого легаси удаление поддержки которого можно было делать только после того как его вывели из эксплуатации при переходе на win10/11

    Тогда я не понимаю опасения того, что раз убрали легаси, то последует залочка, и “рынку обычных ПК каким мы его знаем придёт конец”.

    Я рассуждаю с позиции, что всем, кому залочка была нужна, делали её и раньше, legacy boot тут не помеха. При желании можно и в MSDOS такой параметр вкрутить, и в win7 - вопрос лишь в том, сколько ресурсов надо на это потратить. Как мне кажется, для большинства применений проще взять почти готовый Linux, но допускаю существование сценариев, когда трата ресурсов на допиливание других систем оправдана.

    а если кому не продадут, то значит тому человеку не нужен разлоченный компьютер

    Это тоже уже давно происходит, и никак от x86S не зависит. Были, например, планшеты на Intel Z2560, которые вполне успешно лочились производителем, и неподписанный загрузчик после этого не запускали. То есть появление x86S и невозможность на новых машинах запустить DOS и Win7 тоже не является необходимостью для продажи залоченных планшетов конечному потребителю - они и раньше могли такое делать. Правда назвать компьютером общего назначения получившийся продукт нельзя.

    с чего это с ними буут считаться и как-то приспосабливать для них свои товары?

    С того, что часть их хотелок совпадают с хотелками корпораций, покупающей рабочие станции для сотрудников. На предприятии нужны компьютеры, на которых можно будет запустить любой нужный предприятию софт (который сильно отличается в разных отраслях), защитить получившийся программно-аппаратный комплекс от промышленного шпионажа и кривых рук сотрудника и дать возможность обслуживать такое рабочее место своему IT-департаменту.

    Корпорации может быть были бы и рады сократить свой IT-департамент и покупать готовые залоченные компьютеры у производителей железа, но не могут - требования к софту слишком отличаются. А иногда ещё и закон корпорациям запрещает отдавать наружу контроль над своей инфраструктурой. Поэтому каждый занимается своим делом - корпорации с использованием компьютеров создают отраслевой продукт, а производители железа делают универсальные компьютеры общего назначения.

    Если рассуждать с позиции конечного пользователя, который хочет как можно меньше запретов против себя на компьютере, который он сам для себя купил, то ни x86S, ни TPM, ни SecureBoot, ни UEFI запретов сами по себе не создают - только дают новые возможности по защите себя от злоумышленников.

    Вот Intel Boot Guard действительно может вредить любителям свободы, они coreboot поставить на свою машину из-за него не смогут без замены микросхемы PCH, что дома у себя может далеко не каждый проделать - и то это происходит лишь тогда, когда Boot Guard производителем настроен (сам сталкивался с этим только в ноутбуках). Но почему-то про него никто не вспоминает, а вред в UEFI с SecureBoot в каждом треде про них обнаруживают.


  • в сами ОС и программы то добавлять проверку подписей бинарей тоже надо

    Тоже уже есть, ядру надо сказать ima_appraise=enforce - тогда ядро откажется запускать неподписанные программы. Ещё вроде был какой-то флажок, который запрещает рутовым бинарям читать неподписанные файлы, чтобы важные конфиги нельзя было поправить снаружи. Или можно совсем упороться и увести корень в readonly, покрыв его слоем dm-verity.

    иметь возможность подгружать бинари в которые исправления вносили хексовым редактором

    Так залочить или дать такую возможность? Если очень хочется на залоченной системе это делать, то можно подключиться отладчиком к живому процессу и делать POKETEXT/POKEUSER. Бороться с этим можно с помощью lockdown=confidentiality

    залочивание решили отложить до полного окончания использования легаси

    Работоспособность IMA не зависит от того, как загрузили ядро. Легаси тут никак не мешает. Предыдущим комментарием я говорил про то, что измерять MBR, загрузчик, ядро и initrd тоже можно, а значит легаси залочке компа никак не мешает.

    Так что возможности по залочиванию своих систем существует достаточно давно, все желающие могут дать своей паранойе разгуляться в довольно широком диапозоне. Например, сделать себе “безопасный” ноутбук для работы со всякими ключами и криптокошельками.

    Производителю компьютеров общего назначения лочить свои продукты прямо с завода(*) вредно - их корпоративные пользователи покупать перестанут, потому что на предприятии залочить со своими ключами уже не получится. DRM на удалённой аттестации этими инструментами слишком дорого делать - возможных “легитимных” конфигураций железа и системного софта слишком много, поддержать весь зоопарк (даже хотя бы только все Windows 10) уж очень непросто.

    (*) есть контрпример - BootGuard, но корпорациям пока не очень интересно залезать в прошивки. Если будет нужно, то я уверен, что они договорятся.