QR код в systemd
Айсед вынудил таки почитать, что за QR код сунул поттеринг в systemd: http://lwn.net/Articles/512895/
На данный момент то что там описано, для меня выглядит как жуткий security theater:
* 15 минут подписи логов по умолчанию. Это овердохера - аттакер в среднем имеет 7.5 минут чтобы стереть из текущего неподписанного лога свое присутствие
* мутный алгоритм брата поттеринга
* возможность проебать старый ключик в памяти-свопе
* возможность просто нахрен вытереть логи - и вся информация, которая у нас останется это "логи кем-то были стерты".
На данный момент то что там описано, для меня выглядит как жуткий security theater:
* 15 минут подписи логов по умолчанию. Это овердохера - аттакер в среднем имеет 7.5 минут чтобы стереть из текущего неподписанного лога свое присутствие
* мутный алгоритм брата поттеринга
* возможность проебать старый ключик в памяти-свопе
* возможность просто нахрен вытереть логи - и вся информация, которая у нас останется это "логи кем-то были стерты".
no subject
родственников в бизнес потащил? :)
no subject
no subject
no subject
выживают только параноеги (с)
no subject
Ковырять systemd вряд ли у кого есть жэлание.
Впрочем, там всё можно сделать довольно банально, так что вряд ли тут он нарвался.
no subject
Из последних работ "братца" -- совместная статья с djb о RC4 в TLS: http://www.isg.rhul.ac.uk/tls/
no subject
Подсказка: как получить цепочку невнятных чисел так, что с открытым ключом можно по ней двигаться в одну сторону (из x(n) в x(n+1)), а с закрытым в другую (из x(n+1) в x(n))?
no subject
no subject
no subject
no subject
вот нужно например узнать дату/время неудачных попыток залогиниться по ssh
кошерный и юниксвейный syslog считает, что показаний системных часов достаточно, чтобы однозначно идентифицировать время события
раздутый и переинженернутый journald пишет в нечитаемый юниксвейным catом бинарник показания часов + monotonic timestamp, тем самым страхуя нас от всяких неожиданностей вроде DST или leap second
кошерный и юниксвейный syslog пишет в файл тупо строку, из которой ещё а) надо выдрать IP б) формат которой может меняться при апгрейде. Само собой, каждый интегратор пишет регэкспы для парсинга сам.
раздутый и переинженернутый journald поддерживает произвольные поля в сообщении лога, куда клиент (ssh-сервер в нашем случае) может складывать любую потенциально интересную информацию (IP, reverse hostname, public key и т.п. в нашем случае)
ну и да, любому недоумку очевидно, что смотрелки текстовых файлов cat и less весом 47 и 155 Кб помещаются на аварийную
дискетуфлешку, а вот journalctl (смотрелка логов journald) весом 151 Кб — уже нет.no subject
Тем не менее, отличие "текстовых логов" от "бинарных" есть. Это набор инструментов для работы. У "текстовых" - миллион различных редакторов, включая поточные, лёгкая поддержка в языках общего назначения.
У "бинарных" - сами можете перечислить. А зная любовь П. к модернизации без сохранения обратной совместимости, можете прикинуть время жизни "бинарных" логов до полного протухания инструментов считывания.
no subject
no subject
Круто! Дальше нам с вами беседовать не о чем.
no subject
no subject
Типа нечто новое.
no subject
Отличие ровно в одной операции.
<имя конвертера> < банарный_лог > текстовый лог. А дальше все как обычно.
Причему вызвать это можно и изнутри языка общего назначения - потоки ввода-вывода еще не отменяли.
no subject
А вы уверены, что формат не будет меняться? Что конвертор не вылетит на логах со специфическими повреждениями структуры? (файловые системы, как и жесткие диски не идеальны)
no subject
Смотрелки могут быть на самом деле синонимом какого-нибудь BusyBox.
no subject
таки що там с monotonic timestamp?ага, вроде как наколхозить можно Я правильно понимаю, что по умолчанию их значения всё равно не попадают никуда? то есть проблема на самом деле в том, что класть journalctl, как и less, в busybox Не Принято, так?no subject
Хотя в идеале, конечно, логи должны складываться в базу.
no subject
no subject
а) endianess возможные глюки не исчерпываются. б) Заранее неизвестно, с какой платформы будут смотреть.
> schemaless БД.
Пожалуйста, не материтесь в приличном обществе.
>было бы здорово подкрепить этот тезис примерами из реального мира
Эм... Я затрудняюсь подкрепить примерами самоочевидный тезис.
no subject
no subject
Ну так почему нельзя сразу текстовый формат использовать?
>уверен, разработчики PostgreSQL
Разработчики постргреса большие мальчики и ограничения hstore они знают.
>поправьте меня,
Поправляю: когда у человека спрашивают 'покажи белый снег', стоя посередине заснеженного поля, как-то затруднительно решить, во что ткнуть пальцем. Потому что если не видно сразу, то скорее всего не увидят и после тыканья.
no subject
вертите жоюли́те. Иначе трактовать некорректную аналогию вместо прямого ответа на прямой вопрос я затрудняюсь.no subject
==
==
Аналогия как раз корректная.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
Олсо сложность seeking по plaintext — минимум O(n), по journal — O(log(n)*log(n))…O(n) (зависит от поля, по которому фильтруем).
Export format обратно совместим, JSON обратно совместим. Сам .journal — предположительно нет, и внезапно быть таковым не обязан.
no subject
no subject
Я писал сериализацию-десериализацию ручками.
> journalctl — не «конвертор в текст», а CLI-обёртка
Т.е. вместо простого и понятного конвертора (а еще лучше - просто текстовых логов) предлагается изучать еще одну утилиту. Это ж как надо ненавидеть себя и людей.
>разве что из политических, а не рациональных соображений — исходники-то открыты
Тем не менее, проблема существует.
no subject