+100500! :)Никак не спасёт. Поттеринг просто немного перегрелся.
Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога на отдельный, недоступный из Интернета сервер. Всё.
Вообще, у Поттеринга, как и у любого другого человека, есть идеи удачные, и не очень.
Небольшой debriefing лично от меня, как от человека, администрирующего Юникс последние лет 15 (или больше уже?):
I. systemd. В принципе, идея верная, но это reinvention of wheel. Был же launchd от Apple, чем плох? Ах, да, лицензия, как же, как же...
Но init, действительно, давно и безнадёжно устарел. В старые добрые времена особенно много зависимостей сервисов друг от друга сделать было просто физически невозможно: машинки были слабыми. Как правило, на одной физической машине работал Apache, на другой -- SQL, на третьей -- почтовка, ну и так далее. Поэтому, по большому счёту, всё равно, что там, как и когда запускалось. Не работает -- саппорт машину перезагрузит по звонку админа, и дело с концом. Другие сервисы не пострадают (они на другом физическом железе), а этот и так упал.
Но времена изменились, и теперь на одном физическом хосте можно собрать всё вместе и сразу.
Нет, конечно, это не очень правильно -- правильно сделать облако, виртуалки на нём и т.д. Но в 70-80% случаев оверхед от администрирования облачной инфраструктуры будет сравним с затратами на администрирование того, что на этой инфраструктуре крутится.
Кто его оплатит? Теоретики "облачности"? Сомневаюсь.
Так что интеллектуальный пускач-следилка по сути. Но, опять-таки, systemd -- это изобретение колеса.
II. Сломанная загрузка без /usr. Не стреляйте в Поттеринга -- это не его рук дело. Дело в корявых софтоархитекторах.
Директории /sbin и /usr/sbin имеют буковку "s" в своём названии не зря -- они имеют оную буковку потому, что подразумевалось, что все бинарники в них -- STATICALLY linked.
Тот, кто это сломал -- сломал и загрузку без /usr. Да, можно вынести часть библиотек в /lib, без проблем, но библиотеки написаны так, что без /usr/share половина из них не работает. Ну и так далее.
III. PulseAudio. Ну, опять-таки, reinvention of wheel. Был NAS. Он СПЕЦИАЛЬНО был сделан для ремотного проброса аудио. Использует аутентификацию X'ов. Но лих же, нет! Надо было своё, с шахматами и поэтессами, придумать!
А те, кто кричит, что звуковой сервер в UNIX'е не нужен, идут в сад. Тривиальности про Terminal Server мы опустим сразу, тут и так всё понятно.
Вот смотрите: у вас есть, к примеру, Asterisk. Стоит он чёрт-те где, за семью замками, за семью дверями, рядом с SDH'ным барахлом ГТС. Ходят к нему абоненты. Через SIP. И начинают вам жаловаться, что у них-де "плохо слышно". Как проверить? Правильно, встать столом на линию абонен... Ой, про что это я? Ах, да. Позвонить абоненту со станции, вот. Да-да, "console dial ...". И как вы это будете без звукового сервера слушать? За семь замков, за семь дверей пешком пойдёте?
Идея подключиться к станции SIP-клиентом и позвонить порочна по сути. Ну услышите вы, что плохо слышно. Это у вас SIP-клиент кривой, или у абонента?
IV. Логгер. Ну, тут всё вообще хорошо. Во-первых, msyslog тыщщу лет как умеет криптографически логи подписывать. Во-вторых, для того, чтобы что-то подписывать, совершенно необязательно перетаскивать всё это в бинарный формат. В третьих, "каждый процесс может представиться Apache с PID 4321" -- ну да. Вы от remote logging'а откажетесь, или по сети будете проверять?
Ну и таки да -- от "cat /dev/null > /var/log/whatever" это всё равно не спасёт. :)
