Bug 38903

Created attachment 8942 [details]
Патч, добавляющий опцию READ_ONLY в pipe.conf

Прикладываю патч.

(Ответ для manowar@altlinux.org на комментарий #0)
> В некоторых случаях требуется, чтобы osec продолжал сообщать об изменениях в
> файловой системе до тех пор, пока эти изменения не будут исправлены или пока
> они не будут явно разрешены администратором. Однако сейчас каждый запуск
> osec по расписанию приводит к обновлению базы даннных и поэтому об
> изменениях сообщается только 1 раз.

Всё правильно. Если не обновлять, то потреряется информация о том когда были внесены изменения. Osec не ведёт лог, а только формирует отчёт о разнице состояний. cron обеспечивает фиксацию времени.

Я не вижу сценария использования, когда READ_ONLY мог бы быть полезен.

(Ответ для manowar@altlinux.org на комментарий #1)
> Создано вложение 8942 [details] [подробности]
> Патч, добавляющий опцию READ_ONLY в pipe.conf
> 
> Прикладываю патч.

Я бы назвал этот параметр в конфиге IMMUTABLE_DATABASE (If specified then osec will not try to modify the database)

(In reply to Alexey Gladkov from comment #2)
> Всё правильно. Если не обновлять, то потреряется информация о том когда были
> внесены изменения. Osec не ведёт лог, а только формирует отчёт о разнице
> состояний. cron обеспечивает фиксацию времени.

Время, когда были внесены изменения == это какой-то момент времени, между двумя запусками cron? В точности мы этот момент установить не можем?
Если так, то почему ты говоришь, что ситуация становится хуже, если мы допускаем повторные отчёты о том же самом изменении? Мне кажется, что в этом случае мы по-прежнему можем ориентироваться по времени _первого_ сообщения о данном изменении.

Смысл использования опции READ_ONLY в том, что состояние файловой системы, которое записано в базе данных osec, мы считаем эталонным. В этом случае мы вправе ожидать, что integrity check будет выводить предупреждение всякий раз, когда состояние отличается от эталонного, вне зависимости от того, сколько раз integrity check запускалась до этого, правда? Иными словами, osec, как ты правильно сказал, должен только формировать отчёт о разнице состояний — только информировать (!), но не вносить изменения в эталонное состояние. По крайней мере если его специально об этом не попросили.

Иначе имеем парадоксальную ситуацию: integrity check сначала предупреждает нас о нарушении целостности, но при повторном прогоне говорит, что всё в порядке! В этом случае мы можем не то, что информацию о времени изменения потерять, а и совсем не узнать о том, что были произведены какие-то незапланированные изменения: если мы пропустим первый и единственный (!) отчёт, в котором говорилось о нарушении целостности. То есть, если мы допускаем обновление эталона вместе с генерацией отчёта, то а) имеем единственный шанс отследить изменение (если потеряли письмо, то всё); б) автоматически санкционируем любое изменение ФС.

(Ответ для manowar@altlinux.org на комментарий #3)
> Время, когда были внесены изменения == это какой-то момент времени, между
> двумя запусками cron?

Да. Чем чаще cron запускает osec, тем точнее.

> В точности мы этот момент установить не можем?

Нет.

> Если так, то почему ты говоришь, что ситуация становится хуже, если мы
> допускаем повторные отчёты о том же самом изменении? Мне кажется, что в этом
> случае мы по-прежнему можем ориентироваться по времени _первого_ сообщения о
> данном изменении.

Давай я продемонстрирую.

Без readonly:

# сron report in time T0
/tmp/root	stat	changed	old mtime=1599644162.3507495200	new mtime=1599644172.5866302030
/tmp/root/aaa	checksum	new	 checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709
/tmp/root/aaa	stat	new	 uid=legion gid=legion mode=100644 inode=3139548 mtime=1599644172.5866302030
/tmp/root/bbb	checksum	changed	old checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709	new checksum=sha1:adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
/tmp/root/bbb	stat	changed	old mtime=1599644162.3507495200	new mtime=1599644211.9341715230

# сron report in time T1
/tmp/root	stat	changed	old mtime=1599644172.5866302030	new mtime=1599644256.8696477030
/tmp/root/bbb	checksum	changed	old checksum=sha1:adc83b19e793491b1c6ea0fd8b46cd9f32e592fc	new checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709
/tmp/root/bbb	stat	changed	old mtime=1599644211.9341715230	new mtime=1599644273.2334569470
/tmp/root/aaa	checksum	removed	 checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709
/tmp/root/aaa	stat	removed	 uid=legion gid=legion mode=100644 inode=3139548 mtime=1599644172.5866302030

с readonly:

# сron report in time T0
/tmp/root	stat	changed	old mtime=1599644256.8696477030	new mtime=1599644350.1245606150
/tmp/root/aaa	checksum	new	 checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709
/tmp/root/aaa	stat	new	 uid=legion gid=legion mode=100644 inode=3144748 mtime=1599644350.1245606150
/tmp/root/bbb	checksum	changed	old checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709	new checksum=sha1:adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
/tmp/root/bbb	stat	changed	old mtime=1599644273.2334569470	new mtime=1599644356.5204860570

# сron report in time T1
/tmp/root	stat	changed	old mtime=1599644256.8696477030	new mtime=1599644387.9321198870
/tmp/root/bbb	stat	changed	old mtime=1599644273.2334569470	new mtime=1599644382.8321793370

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

Если osec не сохраняет новое состояние, то вполне вероятно, что он сможет не заметить изменений вообще. Ещё раз, он делает diff, а не пишет лог изменений. Для второго используется auditd.

> Смысл использования опции READ_ONLY в том, что состояние файловой системы,
> которое записано в базе данных osec, мы считаем эталонным. В этом случае мы
> вправе ожидать, что integrity check будет выводить предупреждение всякий
> раз, когда состояние отличается от эталонного, вне зависимости от того,
> сколько раз integrity check запускалась до этого, правда?

Нет. как я показал выше.

> Иначе имеем парадоксальную ситуацию: integrity check сначала предупреждает
> нас о нарушении целостности, но при повторном прогоне говорит, что всё в
> порядке! В этом случае мы можем не то, что информацию о времени изменения
> потерять, а и совсем не узнать о том, что были произведены какие-то
> незапланированные изменения: если мы пропустим первый и единственный (!)
> отчёт, в котором говорилось о нарушении целостности. То есть, если мы
> допускаем обновление эталона вместе с генерацией отчёта, то а) имеем
> единственный шанс отследить изменение (если потеряли письмо, то всё); б)
> автоматически санкционируем любое изменение ФС.

Мне кажется ты неправильно понимаешь отчёты osec. Это отчёт об изменениях с предыдущего состояния в _базе_, а не все изменения, которые были произведены с файловой системой. Чувствуешь разницу ? Изменения на файловой системе могут привести к первоначальному состоянию базы и разницы в  отчётах не будет. Создание нового состояния базы как раз и фиксирует изменения на файловой системе.

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

(In reply to Alexey Gladkov from comment #4)
> (Ответ для manowar@altlinux.org на комментарий #3)
> 
> с readonly:
> 
> # сron report in time T0
> /tmp/root	stat	changed	old mtime=1599644256.8696477030	new
> mtime=1599644350.1245606150
> /tmp/root/aaa	checksum	new	
> checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709
> /tmp/root/aaa	stat	new	 uid=legion gid=legion mode=100644 inode=3144748
> mtime=1599644350.1245606150
> /tmp/root/bbb	checksum	changed	old
> checksum=sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709	new
> checksum=sha1:adc83b19e793491b1c6ea0fd8b46cd9f32e592fc
> /tmp/root/bbb	stat	changed	old mtime=1599644273.2334569470	new
> mtime=1599644356.5204860570
> 
> # сron report in time T1
> /tmp/root	stat	changed	old mtime=1599644256.8696477030	new
> mtime=1599644387.9321198870
> /tmp/root/bbb	stat	changed	old mtime=1599644273.2334569470	new
> mtime=1599644382.8321793370
> 

  Я правильно понимаю, что содержимое aaa и bbb ты уже вернул к первоначальному
перед запуском T1? И поэтому контрольные суммы сходятся?

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

  Для этого нужно сказать touch -m -d 1599644256.8696477030, верно? То есть
вернуть всё, как было, включая mtime?

> Если osec не сохраняет новое состояние, то вполне вероятно, что он сможет не
> заметить изменений вообще. Ещё раз, он делает diff, а не пишет лог
> изменений. Для второго используется auditd.
> ...
> Мне кажется ты неправильно понимаешь отчёты osec. Это отчёт об изменениях с
> предыдущего состояния в _базе_, а не все изменения, которые были произведены
> с файловой системой. Чувствуешь разницу ? Изменения на файловой системе
> могут привести к первоначальному состоянию базы и разницы в  отчётах не
> будет. Создание нового состояния базы как раз и фиксирует изменения на
> файловой системе.

  Я начинаю подозревать, что словом "изменение" ты называешь факт вмешательства
в систему. И по этой причине ты ставишь в пример ситуацию, когда вмешательство было,
но следы удалось замести. У нас же сложилась совершенно иная практика использования
osec.
  И, между прочим, я не совсем понимаю, почему, запуская osec.cron раз в сутки мы
должны рассчитывать на то, что злоумышленник не успеет за это время замести следы.
А если он их заметёт, тогда и запуск T0 ничего не покажет.

> Я бы ещё понял, если бы кому-то захотелось сохранять состояния базы как лог
> и строить отчёты между двумя разными выбранными состояниями, но для 
> readonly я применения придумать не могу.

  Требуется аналог git diff и git status, но для всей файловой системы. Представляешь,
как было бы весело, если бы git diff каждый раз автоматически делал git commit?
А osec.cron так сейчас и делает. Хочется его от этого отучить.

(Ответ для manowar@altlinux.org на комментарий #5)
>   Я правильно понимаю, что содержимое aaa и bbb ты уже вернул к
> первоначальному
> перед запуском T1? И поэтому контрольные суммы сходятся?

В /tmp/root был файл `bbb` и он же был в индексе. В T0 я добавил `aaa` и изменил содержимое `bbb`, а в T1 я удалил `aaa` и вернул содержимое обратно в `bbb`.

>   Для этого нужно сказать touch -m -d 1599644256.8696477030, верно? То есть
> вернуть всё, как было, включая mtime?

Да.
 
> > Если osec не сохраняет новое состояние, то вполне вероятно, что он сможет не
> > заметить изменений вообще. Ещё раз, он делает diff, а не пишет лог
> > изменений. Для второго используется auditd.
> > ...
> > Мне кажется ты неправильно понимаешь отчёты osec. Это отчёт об изменениях с
> > предыдущего состояния в _базе_, а не все изменения, которые были произведены
> > с файловой системой. Чувствуешь разницу ? Изменения на файловой системе
> > могут привести к первоначальному состоянию базы и разницы в  отчётах не
> > будет. Создание нового состояния базы как раз и фиксирует изменения на
> > файловой системе.
> 
>   Я начинаю подозревать, что словом "изменение" ты называешь факт
> вмешательства
> в систему. И по этой причине ты ставишь в пример ситуацию, когда
> вмешательство было,
> но следы удалось замести. У нас же сложилась совершенно иная практика
> использования
> osec.

У кого у "нас" ?

>   И, между прочим, я не совсем понимаю, почему, запуская osec.cron раз в
> сутки мы
> должны рассчитывать на то, что злоумышленник не успеет за это время замести
> следы.
> А если он их заметёт, тогда и запуск T0 ничего не покажет.

osec сам по себе это просто довольно быстрая утилита для снятия состояния метаданных файловой системы и ничего больше. Когда-то давно inger@ придумал вот такое применение этой утилиты для отслеживания закладок на файловой системе. Собственно это и делает osec-cronjob. Но это не единственное возможное примененение osec.

Разумеется, я не рассчитываю, что таким образом можно поймать что-нибудь кроме закладок или опасного изменения атрибутов файлов. Для аудита изменений фс используется audit, но с ним есть другие тонкости.

"Раз в сутки" это компромис, который был сделан ещё когда были hdd.

>   Требуется аналог git diff и git status, но для всей файловой системы.
> Представляешь,
> как было бы весело, если бы git diff каждый раз автоматически делал git
> commit?
> А osec.cron так сейчас и делает. Хочется его от этого отучить.

Ты как-то странно относишься к его отчётам. Если тебе очень нужно, то я не против добавить IMMUTABLE_DATABASE как интерфейс к опции -r хоть я и не вижу в этом пользы.

(In reply to Alexey Gladkov from comment #6)
> Ты как-то странно относишься к его отчётам. Если тебе очень нужно, то я не
> против добавить IMMUTABLE_DATABASE как интерфейс к опции -r хоть я и не вижу
> в этом пользы.

Да, добавь пожалуйста. Лично я бы предпочёл чтобы опция называлась READ_ONLY просто потому, что так она называется в CLI osec.

(Ответ для manowar@altlinux.org на комментарий #7)
> Да, добавь пожалуйста. Лично я бы предпочёл чтобы опция называлась READ_ONLY
> просто потому, что так она называется в CLI osec.

Когда используется опция, то понятно в каком контексте имеется в виду read-only. В конфиге мне уже не настолько очевидно о чём речь.

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

(In reply to Alexey Gladkov from comment #8)
> (Ответ для manowar@altlinux.org на комментарий #7)
> > Да, добавь пожалуйста. Лично я бы предпочёл чтобы опция называлась READ_ONLY
> > просто потому, что так она называется в CLI osec.
> 
> Когда используется опция, то понятно в каком контексте имеется в виду
> read-only. В конфиге мне уже не настолько очевидно о чём речь.

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

osec-1.3.1-alt1 -> sisyphus:

 Tue Sep 29 2020 Alexey Gladkov <legion@altlinux.ru> 1.3.1-alt1
 - New version (1.3.1);
 - Cronjob changes:
   + Add config parameter to disallow database changes (ALT#38903).
   + Summarize more types of changes in the report (ALT#38771).
 - Fixed extra space in the reported string.
 - contrib: Add systemd-specific files.