LINUX.ORG.RU

systemd In Action, part 4

 


4

3

И мы опять продолжаем.

В этой части серии мы попытались оценить устойчивость бинарного формата лог-файлов journald к произвольным повреждениям, испытали передачу логов по сети с одной машины на другую (нативным для journald способом), произвели настройку сетевого соединения на тестовой машине с помощью networkd/resolved и, наконец, продемонстрировали работу с D-Bus интерфейсами systemd и вспомогательных демонов (ради чего они, собственно, и были сделаны демонами).

Помимо видеоряда также имеется подробная текстовая аннотация.

Авторы: PaulCarroty, like-all, intelfx.

(В случае проблем с доступом к tlhp.cf также имеется зеркало.)

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: intelfx (всего исправлений: 1)

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

Уже сколько раз про это писали. Но нет, надо опять по тем же граблям попрыгать.

Вполне вероятно, что ситуацию можно улучшить, исправив утилиту просмотра (или реализовав её аналог, ориентированный именно на восстановление).

Мда, упёртость фанбоев вызывает просто смех.

anonymous
()

Круто! Отдельное спасибо за текстовую аннотацию.

Sunderland93 ★★★★★
()
Ответ на: комментарий от anonymous

Тебе чёрным по белому разжевали: дело в просмотрщике, а не в формате. if (r < 0) goto finish;, понимаешь?

Но нет, упёртость дерьмохейтеров... даже смеха недостойна.

anonymous
()
Ответ на: комментарий от anonymous

Вполне вероятно, что ситуацию можно улучшить, исправив утилиту просмотра (или реализовав её аналог, ориентированный именно на восстановление).

Насчёт этого кстати в багтрекере уже ответили: wontfix. Потому что повреждение означает, что начиная с этого места лог потенциально скомпрометирован, и лучше о нём забыть, чем пытаться восстановить.

vurdalak ★★★★★
()

продемонстрировали работу с D-Bus интерфейсами systemd и вспомогательных демонов (ради чего они, собственно, и были сделаны демонами)

Из этой фразы пытливый читатель должен сделать вывод, что вспомогательных демонов в systemd наплодили ради D-Bus? Или даже для того, чтобы авторы «продемонстрировали работу с ...»?

anonymous
()
Ответ на: комментарий от vurdalak

Насчёт этого кстати в багтрекере уже ответили: wontfix.

Да кто бы сомневался.

Потому что повреждение означает, что начиная с этого места лог потенциально скомпрометирован, и лучше о нём забыть, чем пытаться восстановить.

А это не их собачье дело, решать, что кому лучше. А ну да, теперь их.

Линукс скатывается в унылое говно. И дело не только в systemd.

anonymous
()
Ответ на: комментарий от vurdalak

Насчёт этого кстати в багтрекере уже ответили: wontfix.

И кто они после этого? Мало ли из-за чего лог поломался. Железо какое-то сыпанулось - ситуацию в т.ч. по логам проясняют.

redeyedanonymous
()
Ответ на: комментарий от anonymous

Тебе чёрным по белому разжевали: дело в просмотрщике, а не в формате. if (r < 0) goto finish;, понимаешь?

«Вполне вероятно, что ситуацию можно улучшить, исправив утилиту просмотра (или реализовав её аналог, ориентированный именно на восстановление).»

Вполне вероятно, что ситуацию нельзя улучшить... Вполне вероятно, что Земля плоская, а шарообразность - иллюзия.

Вот когда утилита будет исправлена (никогда) вот тогда и будешь сказки рассказывать.

anonymous
()
Ответ на: комментарий от anonymous

А это не их собачье дело, решать, что кому лучше.

Вообще-то их. Их софт — их решения. Не нравится — форкай, опенсорс такой опенсорс.

vurdalak ★★★★★
()
Ответ на: комментарий от redeyedanonymous

Они упоролись в идею устойчивости к взлому, от этого все проблемы.

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Нет, не wontfix. Это надо чинить.

http://www.freedesktop.org/wiki/Software/systemd/journal-files/:

If any kind of corruption is noticed by a reader it should try hard to handle this gracefully, such as skipping over the corrupted data, but allowing access to as much data around it as possible.

intelfx ★★★★★
() автор топика
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от vurdalak

Потому что повреждение означает, что начиная с этого места лог потенциально скомпрометирован, и лучше о нём забыть, чем пытаться восстановить.

Так и запишем: разработчики считают себя умнее пользователей и сами решают что им нужно, а что нет. Спасибо, жрите сами.

mandala ★★★★★
()
Ответ на: комментарий от redeyedanonymous

И кто они после этого?

Хорошие парни, делают очень нужное дело для опенсорса.

Мало ли из-за чего лог поломался.

Проблемы негров.

mandala ★★★★★
()
Ответ на: комментарий от mandala

Так и запишем: разработчики считают себя умнее пользователей и сами решают что им нужно, а что нет.

Пойми, глупая девочка, что так всегда было, есть и будет.

anonymous
()

Спасибо за работу.

tlx ★★★★★
()
Ответ на: комментарий от anonymous

Тебе чёрным по белому разжевали: дело в просмотрщике, а не в формате. if (r < 0) goto finish;, понимаешь?

Тупым фанбоям уже ответили официально «wontfix», но нет будут пытаться насиловать труп и поливать всех дерьмом.

Но нет, упёртость дерьмохейтеров... даже смеха недостойна.

Грустные и унылые фанбои, это же мечта любого хейтера!

anonymous
()
Ответ на: комментарий от anonymous

упёртость дерьмохейтеров

Словно ненавидеть дерьмо - это что-то плохое... Хм.

anonymous
()
Ответ на: комментарий от intelfx

Это надо чинить.

Может кто-то из фанбоев соизволит прибрать дерьмо за своим кумиром?

anonymous
()

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

Jameson ★★★★★
()

systemd - мракобесие! systemd In Action - новости секты свидетелей! Изыди!

anonymous
()
Ответ на: комментарий от vurdalak

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

gaga
()
Ответ на: комментарий от gaga

У тебя странная логика. Вот есть локалхост, нам нужны логи. Мы их подписываем, чтобы хацкер не стёр. Что не так? Или безопасность бывает только там, где 9000 серверов на каждый чих?

vurdalak ★★★★★
()
Ответ на: комментарий от redeyedanonymous

Есть 2 вида сисадминов: которые уже бэкапят...

Мало ли из-за чего лог поломался. Железо какое-то сыпанулось - ситуацию в т.ч. по логам проясняют.

Если информация не резервируется — она тебе не особо нужна. К логам это тоже относится.

x3al ★★★★★
()
Ответ на: комментарий от vurdalak

Подписывание не спасет от стирания. Логи помогут только в том случае, если у тебя настроен их анализ и мониторинг, что нетривиально само по себе. На локалхосте никто этим не занимается, по крайней мере я такого не встречал. А там, где это реализовано, есть и лог-сервер.

gaga
()
Ответ на: комментарий от gaga

Да, я имел в виду защиту от подделывания, а не стирания.

На локалхосте никто этим не занимается

Вот, а теперь будут заниматься. Потому что из коробки.

vurdalak ★★★★★
()

Если информация не резервируется — она тебе не особо нужна. К логам это тоже относится.

Так если мы их бакапим и все такое, то на коего художника репина мы их подписываем ? Ради чего там вообще этот бинарный формат ? Бывает безопасность для работы а бывает безопасность ради безопасности, т.е. избыточная. И systemd - как раз эта крайность. systemd создает проблемы на ровном месте. Там, где их, по сути, и не было.

anonymous
()
Ответ на: комментарий от vurdalak

И куда ты денешься, котик?

Вот пока не определился, у дебиана поддержка еще не скоро кончится, есть время определиться. А там глядишь или ишак, или падишах.

mandala ★★★★★
()
Ответ на: комментарий от mandala

у дебиана поддержка еще не скоро кончится

я думаю у дебиановцев хватит ума оставить как есть - т.е. возможность использовать System V init останется, пусть он и не дефолтный.

CryAngel
()

В этой части серии мы попытались оценить устойчивость бинарного формата лог-файлов journald к произвольным повреждениям

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

Napilnik ★★★★★
()
Ответ на: комментарий от anonymous

Так если мы их бакапим и все такое, то на коего художника репина мы их подписываем ?

Чтобы не бекапить скомпрометированные логи.

Ради чего там вообще этот бинарный формат ?

Почему бы и нет, если это удобнее?

x3al ★★★★★
()
Ответ на: комментарий от vurdalak

Если даже не учесть того, что проникнув в систему, можно с логгером сделать что угодно, подделывать лишнее. Это локалхост, а не сервак. Защита от дурака: замок с шифром на картонную дверь.

Deleted
()
Ответ на: комментарий от Deleted

можно с логгером сделать что угодно, подделывать лишнее

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

vurdalak ★★★★★
()
Ответ на: комментарий от vurdalak

Мы их подписываем, чтобы хацкер не стёр.

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

Harald ★★★★★
()
Ответ на: комментарий от x3al

Так если мы их бакапим и все такое, то на коего художника репина мы их подписываем ?

Чтобы не бекапить скомпрометированные логи.

Лолчто ? Теперь, для альтернативно так сказать одаренных, ситуация. Вашу систему ломанули и намерянно попортили ваши бинарные логи. Соответственно, вы можете помахать этим логам платочком, синим сопливым, так сказать. При чем не только ту часть, где имел место быть процесс взлома, а ваще усе :) Чуете разницу ? При всем при этом разработчики вам так и говорят - идите лесом-полем с востановлением логов. И не кажется ли вам, мон шер, что стоит мб проще сделать онлайн копирование с шифрованием текстовых логов, чем плодить черт знает какого монстра. И кстати, раз уж мы так печемся о безопасности, может проще сделать реагирование в системе на тему подозрительной активности а ? Это не так сложно, между прочим. Но нет. Мы наплодим за каким-то лешим СИСТЕМУ, напишем ей бинарных формат, а потом подпишем этого неуклюжего слона. При чем если этот слон не дай-то пог, выдаст в результате жизнедеятельности, что-то, отличное от того, что он должен, то мы скажем. Ну извините, слон обо-ся :) Восстановить из г-на назад конфету мы не в состоянии :)

anonymous
()
Ответ на: комментарий от Harald

и почему у хацкера нету к нему доступа, чтобы подписать новый лог, почти как оригинальный?

Новый можно. Старый нельзя. Там какая-то хитрая инкрементальная подпись, я не помню всех подробностей.

vurdalak ★★★★★
()
Ответ на: комментарий от Deleted

так то умные люди давно сказали: если есть физический доступ, любые защиты бесполезны (в общем случае. в частных случаях защита может уберечь от «мамкиного какира». с другой стороны, уже сам факт линукса так же может уберечь), но некоторые продолжают забавляться. в случае платного софта это объяснить легко - там разработчику важнее задекларировать «защищенность», что бы привлечь покупателей (хотя по факту там может быть даже примитивный XOR). а вот с открытым - на знаю. может, привычка?

CryAngel
()

Почему у меня на обоих машинах логи поломанные? На одной за пол-года логи, на другой за 9 месяцев, и везде journalctl --verify печатает красным ошибки. CentOS 7, s-d 208. Оно само ломается при случайном выключении питания что ли, или что? Зачем тогда защита от подмены, если нет защиты от поломки.

d_a ★★★★★
()
Ответ на: комментарий от anonymous

Убунту вчера поставил и теперь эксперт в линуксах?

Вашу систему ломанули и намерянно попортили ваши бинарные логи.

И это сразу заметно. Больше ничего и не требуется.

При всем при этом разработчики вам так и говорят - идите лесом-полем с востановлением логов

Нафига тебе заведомо скомпрометированные логи? Ложная информация хуже, чем никакой.

онлайн копирование

Оно не всегда получается онлайн... И онлайн — понятие относительное.

реагирование в системе на тему подозрительной активности

Ты предлагаешь нечто масштабов SELinux и называешь это «не так сложно».

x3al ★★★★★
()
Ответ на: комментарий от vurdalak

Он так устроен, что нельзя

на самом деле, при наличии физического доступа, можно, можно что угодно. вопрос только времени и квалификации взломщика. что бы в этом убедиться, можно даже не влезать в глубокие дебри, а посмотреть на эпичную битву игроделов с «пиратством».

CryAngel
()
Ответ на: комментарий от CryAngel

может, привычка?

всех привлекают обещания) Кандидат, который ничего не обещает - не будет выбран.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.