38903 2020-09-08 19:31:10 +0300 Добавить опцию в pipe.conf для управления -r 2020-09-29 23:24:09 +0300 1 1 4 Development Sisyphus osec-cronjob unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 manowar legion ldv legion manowar nbr qa-sisyphus oldest_to_newest 192301 0 manowar 2020-09-08 19:31:10 +0300 В некоторых случаях требуется, чтобы osec продолжал сообщать об изменениях в файловой системе до тех пор, пока эти изменения не будут исправлены или пока они не будут явно разрешены администратором. Однако сейчас каждый запуск osec по расписанию приводит к обновлению базы даннных и поэтому об изменениях сообщается только 1 раз. В самом osec есть опция, которая запрещает изменение базы: -r. Но в pipe.conf не преждусмотрено соответствующей переменной. 192302 1 8942 manowar 2020-09-08 19:31:52 +0300 Created attachment 8942 Патч, добавляющий опцию READ_ONLY в pipe.conf Прикладываю патч. 192307 2 legion 2020-09-08 19:45:54 +0300 (Ответ для manowar@altlinux.org на комментарий #0) > В некоторых случаях требуется, чтобы osec продолжал сообщать об изменениях в > файловой системе до тех пор, пока эти изменения не будут исправлены или пока > они не будут явно разрешены администратором. Однако сейчас каждый запуск > osec по расписанию приводит к обновлению базы даннных и поэтому об > изменениях сообщается только 1 раз. Всё правильно. Если не обновлять, то потреряется информация о том когда были внесены изменения. Osec не ведёт лог, а только формирует отчёт о разнице состояний. cron обеспечивает фиксацию времени. Я не вижу сценария использования, когда READ_ONLY мог бы быть полезен. (Ответ для manowar@altlinux.org на комментарий #1) > Создано вложение 8942 [подробности] > Патч, добавляющий опцию READ_ONLY в pipe.conf > > Прикладываю патч. Я бы назвал этот параметр в конфиге IMMUTABLE_DATABASE (If specified then osec will not try to modify the database) 192310 3 manowar 2020-09-08 22:35:20 +0300 (In reply to Alexey Gladkov from comment #2) > Всё правильно. Если не обновлять, то потреряется информация о том когда были > внесены изменения. Osec не ведёт лог, а только формирует отчёт о разнице > состояний. cron обеспечивает фиксацию времени. Время, когда были внесены изменения == это какой-то момент времени, между двумя запусками cron? В точности мы этот момент установить не можем? Если так, то почему ты говоришь, что ситуация становится хуже, если мы допускаем повторные отчёты о том же самом изменении? Мне кажется, что в этом случае мы по-прежнему можем ориентироваться по времени _первого_ сообщения о данном изменении. Смысл использования опции READ_ONLY в том, что состояние файловой системы, которое записано в базе данных osec, мы считаем эталонным. В этом случае мы вправе ожидать, что integrity check будет выводить предупреждение всякий раз, когда состояние отличается от эталонного, вне зависимости от того, сколько раз integrity check запускалась до этого, правда? Иными словами, osec, как ты правильно сказал, должен только формировать отчёт о разнице состояний — только информировать (!), но не вносить изменения в эталонное состояние. По крайней мере если его специально об этом не попросили. Иначе имеем парадоксальную ситуацию: integrity check сначала предупреждает нас о нарушении целостности, но при повторном прогоне говорит, что всё в порядке! В этом случае мы можем не то, что информацию о времени изменения потерять, а и совсем не узнать о том, что были произведены какие-то незапланированные изменения: если мы пропустим первый и единственный (!) отчёт, в котором говорилось о нарушении целостности. То есть, если мы допускаем обновление эталона вместе с генерацией отчёта, то а) имеем единственный шанс отследить изменение (если потеряли письмо, то всё); б) автоматически санкционируем любое изменение ФС. 192318 4 legion 2020-09-09 13:05:42 +0300 (Ответ для 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 я применения придумать не могу. 192320 5 manowar 2020-09-09 13:43:34 +0300 (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 так сейчас и делает. Хочется его от этого отучить. 192323 6 legion 2020-09-09 14:28:01 +0300 (Ответ для 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 хоть я и не вижу в этом пользы. 192326 7 manowar 2020-09-09 14:51:20 +0300 (In reply to Alexey Gladkov from comment #6) > Ты как-то странно относишься к его отчётам. Если тебе очень нужно, то я не > против добавить IMMUTABLE_DATABASE как интерфейс к опции -r хоть я и не вижу > в этом пользы. Да, добавь пожалуйста. Лично я бы предпочёл чтобы опция называлась READ_ONLY просто потому, что так она называется в CLI osec. 192328 8 legion 2020-09-09 15:48:30 +0300 (Ответ для manowar@altlinux.org на комментарий #7) > Да, добавь пожалуйста. Лично я бы предпочёл чтобы опция называлась READ_ONLY > просто потому, что так она называется в CLI osec. Когда используется опция, то понятно в каком контексте имеется в виду read-only. В конфиге мне уже не настолько очевидно о чём речь. 192330 9 legion 2020-09-09 15:57:02 +0300 Вообще, мне кажется что, этот тип проверки системы немного подустарел. 192332 10 manowar 2020-09-09 16:24:19 +0300 (In reply to Alexey Gladkov from comment #8) > (Ответ для manowar@altlinux.org на комментарий #7) > > Да, добавь пожалуйста. Лично я бы предпочёл чтобы опция называлась READ_ONLY > > просто потому, что так она называется в CLI osec. > > Когда используется опция, то понятно в каком контексте имеется в виду > read-only. В конфиге мне уже не настолько очевидно о чём речь. Может, пусть тогда будет READ_ONLY_DATABASE? Мне было бы удобно определиться с названием сейчас, чтобы потом, когда выйдет новая версия, не менять его в обёрточных скриптах. 192904 11 repository-robot 2020-09-29 23:24:09 +0300 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. 8942 2020-09-08 19:31:52 +0300 2020-09-08 19:31:52 +0300 Патч, добавляющий опцию READ_ONLY в pipe.conf osec-1.3.0-readonly.patch text/plain 1248 manowar IGRhdGEvb3NlYy5jcm9uIHwgOCArKysrKysrKwogZGF0YS9waXBlLmNvbmYgfCA2ICsrKysrKwog MiBmaWxlcyBjaGFuZ2VkLCAxNCBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvZGF0YS9vc2Vj LmNyb24gYi9kYXRhL29zZWMuY3JvbgppbmRleCA4ZGFlZDQ5Li4xMmI4ZWNhIDEwMDc1NQotLS0g YS9kYXRhL29zZWMuY3JvbgorKysgYi9kYXRhL29zZWMuY3JvbgpAQCAtMTEwLDYgKzExMCwxMyBA QCBjYXNlICIke1BSRVNFUlZFX1BSSVZJTEVHRVMtfSIgaW4KIAkJOzsKIGVzYWMKIAorcmVhZF9v bmx5PQorY2FzZSAiJHtSRUFEX09OTFktfSIgaW4KKwkxfFtZeV18W1l5XVtFZV1bU3NdKQorCQly ZWFkX29ubHk9MQorCQk7OworZXNhYworCiAoCiAJcmM9MAogCSRjbWQgL3Vzci9iaW4vb3NlYyBc CkBAIC0xMTcsNiArMTI0LDcgQEAgZXNhYwogCQkke0lHTk9SRV9GSUVMRFM6Ky1pICIkSUdOT1JF X0ZJRUxEUyJ9IFwKIAkJJHtIQVNIX1RZUEU6Ky10ICIkSEFTSF9UWVBFIn0gXAogCQkke2FsbG93 X3Jvb3Q6Ky1SfSBcCisJCSR7cmVhZF9vbmx5Oistcn0gXAogCQktRCAiJERBVEFCQVNFX0RJUiIg XAogCQktZiAiJERJUlNfRklMRSIgfHwKIAkJcmM9JD8KZGlmZiAtLWdpdCBhL2RhdGEvcGlwZS5j b25mIGIvZGF0YS9waXBlLmNvbmYKaW5kZXggMzZiM2IyOC4uZTcyOWNjOSAxMDA2NDQKLS0tIGEv ZGF0YS9waXBlLmNvbmYKKysrIGIvZGF0YS9waXBlLmNvbmYKQEAgLTI2LDYgKzI2LDEyIEBAIElH Tk9SRV9GSUVMRFM9CiAjIHRoZW4gbGVhdmUgdGhpcyB2YXJpYWJsZSBlbXB0eSBvdGhlcndpc2Ug d3JpdGUgJ3llcycuCiBQUkVTRVJWRV9QUklWSUxFR0VTPQogCisjIFJlYWQtb25seSBtb2RlIGZv ciByZXBvcnQtb25seSBvc2VjIHJ1bnMuIFdoZW4gb3NlYyBpcyBydW5uaW5nIGluCisjIHJlYWQt b25seSBtb2RlIGl0IGRvZXNuJ3QgdXBkYXRlIHRoZSBkYXRhYmFzZSBmaWxlcyBtYWtpbmcgZWFj aAorIyBydW4gcmVwb3J0IGFib3V0IGNoYW5nZXMgdW50aWwgdGhlIGRhdGFiYXNlIGlzIHVwZGF0 ZWQgKGJ5IHJ1bm5pbmcKKyMgb3NlYyBpbiByZWFkLXdyaXRlIG1vZGUpLgorUkVBRF9PTkxZPQor CiAjIERvIG5vdCBnZW5lcmF0ZSBhIHJlcG9ydCwgaWYgdGhlcmUgd2FzIG5vIGNoYW5nZS4KICMg V0FSTklORzogVGhpcyBpcyB2ZXJ5IGRhbmdlcm91cyB0byBlbmFibGUgdGhpcyBvcHRpb24sCiAj IGJlY2F1c2UgaWYgdGhlIG9zZWMgd2lsbCBiZSBkaXNhYmxlZCBieSBpbnRydWRlciwK