QR код в systemd

[metaclass]

Айсед вынудил таки почитать, что за QR код сунул поттеринг в systemd: http://lwn.net/Articles/512895/

На данный момент то что там описано, для меня выглядит как жуткий security theater:
* 15 минут подписи логов по умолчанию. Это овердохера - аттакер в среднем имеет 7.5 минут чтобы стереть из текущего неподписанного лога свое присутствие
* мутный алгоритм брата поттеринга
* возможность проебать старый ключик в памяти-свопе
* возможность просто нахрен вытереть логи - и вся информация, которая у нас останется это "логи кем-то были стерты".

Comments

[nealar.livejournal.com]

Для упрощения разбора и выцепления нужной инфы постфактум.

[develop7]

да
вот нужно например узнать дату/время неудачных попыток залогиниться по 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 Кб — уже нет.

[rdia.livejournal.com]

Вообще-то "текстовые логи", как известно, тоже бинарные. Всё, что на компутере есть - это числа.

Тем не менее, отличие "текстовых логов" от "бинарных" есть. Это набор инструментов для работы. У "текстовых" - миллион различных редакторов, включая поточные, лёгкая поддержка в языках общего назначения.

У "бинарных" - сами можете перечислить. А зная любовь П. к модернизации без сохранения обратной совместимости, можете прикинуть время жизни "бинарных" логов до полного протухания инструментов считывания.

[develop7]

смотреть лог в редакторе? но зачем?

лёгкая поддержка в языках общего назначения

поддержка логирования или чтения? inb4: journald умеет прикидываться syslogd

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

Неа, не могу, т.к. не знаком с проявлениями любви П. к ломанию BC. Не затруднит ли вас поделиться ссылками на?

[rdia.livejournal.com]

> смотреть лог в редакторе? но зачем?

Круто! Дальше нам с вами беседовать не о чем.

[develop7]

«ну и отлично»©

[inkelyad.livejournal.com]

Тем не менее, отличие "текстовых логов" от "бинарных" есть. Это набор инструментов для работы. У "текстовых" - миллион различных редакторов, включая поточные, лёгкая поддержка в языках общего назначения.

Отличие ровно в одной операции.

<имя конвертера> < банарный_лог > текстовый лог. А дальше все как обычно.
Причему вызвать это можно и изнутри языка общего назначения - потоки ввода-вывода еще не отменяли.

[rdia.livejournal.com]

Вы не учитываете хрупкость этой операции. Скажем, есть ли этот "имя конвертора" под Windows? А под MacOSX?

А вы уверены, что формат не будет меняться? Что конвертор не вылетит на логах со специфическими повреждениями структуры? (файловые системы, как и жесткие диски не идеальны)

[serbod.livejournal.com]

Сислог - штука гибкая. Любой формат даты, структурированный текст сообщения. И это в "старом", BSD формате. В новом еще лучше. Просто многим это нафиг не надо. Произвольные поля? Почитайте уже RFC 5424.

Смотрелки могут быть на самом деле синонимом какого-нибудь BusyBox.

[develop7]

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

Любой формат даты

таки що там с monotonic timestamp?ага, вроде как наколхозить можно

Произвольные поля? Почитайте уже RFC 5424.

Я правильно понимаю, что по умолчанию их значения всё равно не попадают никуда?

Смотрелки могут быть на самом деле синонимом какого-нибудь BusyBox.

то есть проблема на самом деле в том, что класть journalctl, как и less, в busybox Не Принято, так?