> Объясните мне скорбному, как криптография может защитить от подделки логов на локальной
> машине?Да.
> В рабочей системе, очевидно, имеется всё необходимое и достаточное для
> создания записей в логах, ведь как-то эти логи ведутся.
Да.
> А цепочки
> хэшей лишь гарантируют, что нельзя изменить стараю запись, не затронув более
> новые записи.
Нет.
> Но ничто не мешает злоумышленнику стереть N последних записей
> и заменить их своими.
Вполне можно сделать так, что изменение N предыдущих записей влияет на параметры защищённого заголовка файла к примеру. Хотя во внутренней архитектуре Journal ещё не разбирался, так что как именно это реализовано Поттерингом не знаю.
> Как и в git, собственно, можно изменить
> любую ревизию, изменив все последуюдие.
В git не ставилась задача неизменности истории ревизий.
> А в случае службы логов на изолированной машине
> этот последний хэш хранится где-то на этой же машине.
Совершенно не факт, что этого будет достаточно для изменения всех записей в логи начиная с произвольного места.
> В общем, мы приходим к выводу, что единственный доступный способ защиты логов
> от подделки - хранить контрольный хэш на удалённой машине.
А мы приходим к выводу, что рассуждения о безопасности архитектуры Journal без её изучения и без знания основ криптографии - бессмысленны.
> А далее
> приходим к выводу, что один контрольный хэш не спасает от полного
> уничтожения логов, то есть, лучше на удалённой машине хранить весь лог
> целиком.
А далее приходим к выводу, что рассуждения о новости без её вдумчивого чтения это лёгкий способ выставить себя идиотом: journal не ставит задачу защиты логов от уничтожения - только от их модификации.
Поздравляем тов. Анонима с очередным газопусканием в лужу и желаем ему дальнейших творческих успехов.
