В общем в ядрышке 2.6.13 есть такая фишка, называется inotify.
(Documentation/filesystems/inotify.txt)
Суть вопроса , собственно, почему туда PID (т.е. того юзера, кто, собственно доступ осуществлял) процесса не припахали ?! Отслеживать триста тыщ файлов, это конечно, хорошо (я тащился), но ведь это ж еще не вся "хакерская мечта"


Братья линуксоиды, которые писали inotify :
John McCutchan <[email protected]>
Robert Love <[email protected]>

ЗЫ
Я б с удовольствием им сам написал, только с инглишем у меня полный "упс".

ЗЫЫ
Вот сижу и наблюдаю как какой-то процесс каждые 2 сек. дергает /etc/mtab. А отрубить не могу, ибо не знаю какой процесс


Это сообщение отредактировал(а) GrayCardinal - 27.10.2005, 11:12

вопрос1: с каких это пор PID связан с UID/GID ?
процесс - сдох, и его PID занял другой.


вопрос2: ты по-моему не догнал факт, что чаще всего до файла дотрагиваются не процессы юзера а всякие там демоны из серии kswapd и его собратья.
в таком случае - нафига тебе знать что файл засвопился или рассвопился ?
кроме того, цель проекта не создать инфраструктуру слежения за юзерами, а слежения за изменениями в файловой системе, и если тебе надо, то пиши патч, и отошли его Роберту Лову, или его товарищу по парте.
а вообще я думаю, что процесс, к-рый дергает твой mtab, имеет связь с hald-ом


пока.



Это сообщение отредактировал(а) bilbobagginz - 27.10.2005, 17:38

Начал догонять. Сегодня прям с утра. Но еще не до конца.
Не понял. как это никак не связан ? Берешь PID, лезешь в /proc/$PID и получаешь всю инфо по процессу (или тупо - "$ ps -aux"). Главное - консоль, к которой подключен. А без PID - ну никак. Ну читают твою "архиважную" информацию, а ты сидишь и тупо смотришь, а сделать ничего не можешь. Не, можно, конечно, выдернуть шнур... Нет, я могу понять, что писалось сие для того чтоб делать реакцию на изменения какого-нибудь файло. Конфига, к примеру, чтоб тупо не читать его каждые (условно) 5 сек. Но почему такая однополярность ?

Пример.
Короче делаю я слежение за созданием/удалением файлов в /etc/
Сижу, энто, администрирую. И вижу мессагу на консольке (условно)
"удален /etc/passwd"
(ну, скажем, кто-то дырку нашел на моем httpd, тупо запущенным под рутом)
и шо, мне просто идти вешаться ?

На счет второго вопроса.

Цитата

вопрос2: ты по-моему не догнал факт, что чаще всего до файла дотрагиваются не процессы юзера а всякие там демоны из серии kswapd и его собратья

Не пойму я тебя чегой-то. Ты про какой своп-то ? у меня его отродясь не было (память позволяет)

Вот что у меня при
$ cat /etc/passwd
--------------------------------------------------------------------------------
доступ к файлу /usr/share/icons/crystalsvg/16x16/actions/openterm.png
доступ к файлу /bin/cat
доступ к файлу /bin/cat
доступ к файлу /bin/cat
доступ к файлу /lib/ld-2.3.2.so
доступ к файлу /lib/ld-2.3.2.so
доступ к файлу /lib/tls/libc-2.3.2.so
доступ к файлу /etc/passwd
-----------------------------------------------------------------------------------
Это потому что я изгаляюсь, и слежу за всей системой (там "всего" 300т файлов...). Однако ведь можно включить только /etc/passwd, к примеру... А если какой демон файлы трогает, так это можно на этапе "конфигурирования" все файлики, которые должны "дергаться" в нормальном состоянии просто не включать...

ЗЫ
Письмо соображаю.

ЗЗЫ
Патч я б написал, боюсь пива не хватит

bilbobagginz
Зря волновался, 0.5 хватило. Над письмом еще думаю (это оказалось сложнее )

Наконец-то интересная дискуссия развивается.
Смотри, насколько я понимаю, inotify разрабатывали для оперделенных, сформулированных целей, и т.с. если у тебя они не соответствуют с нуждами, сам понимаешь... пиши сам, или проси Роберта. во вторых, эту систему разрабатывали как замену/оптимизацию dnotify, что об оригинальности не говорит.

допустим ты сидишь и мудро смотришь на то как у тебя на консоли написано:
изменился файл /bin/ls (установка rootkit-а)
..
..
..
..
изменился файл /sbin/zsh (...)
изменился файл /etc/shadow (поменяли пароль root)
ну и для веселости:
еще убили твой процесс оболочки, и ты с умным видом, через ssh был отключен.

стабильность системы наживается при помощи многих факторов и систем ( как лук или капуста, много слоев и т.д. ); если тебе нужна безопасная система, а не утилитка для размонтирования дискетки или КД, то я думаю одним inotify все равно не обойдешься - с selinux нужно повозиться, вставить всякие пакости для проверки файлов и т.д., короче полный пакет, и особенно - восстановление из бекапов, ну и сами бекапы. Чтобы в случае того, что тебе делают вот эту сверху операцию без наркоза - реабилитация была с минимальный срок.

Цитата

Не пойму я тебя чегой-то. Ты про какой своп-то ? у меня его отродясь не было (память позволяет)

не важно, какой-то другой демон файловой системы ( kjournald) могет дергать все файлы.

я думаю, что проблема вот в чем: ты используешь inotify "не поназначению". насколько я вижу, это не инструмент безопасности, по планировке.

Патч ушел... С жуткой пометкой WHY NOT ? Надеюсь этого хватит. Если нет - будем думать дальше.

ЗЫ
А я таки достучался до "ядерщиков". Короче в -mm ветке последней не будет бага при добвлении модуля который уже встроен в систему. Короче, если у вас vfat встроена в систему, а вы пытаетесь подгрузить, vfat.ko, то BUG-а на два экрана больше не будет.

Цитата

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

То, что одним inotify тут не обойтись (тяжелый случай ), это понятно, конечно. Однако вариант с PID дает гораздо больше возможностей (и областей применения), не находишь ?
.

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

P.S. если кто несогласен ( кроме GrayCardinal ) опровергните меня - тема - открыта.

не надо привата. Этот топик интересно читать

Это сообщение отредактировал(а) Mayk - 29.10.2005, 13:34

bilbobagginz
Ответ таки пришел. (видать часто ему этот вопрос задавали )

Цитата

> 1) Security >       Letting processes know which pid is working with an inode is a huge > security leak. > > 2) ABI >       If we extend the event structure that will break every application that > uses inotify. That's unacceptable at this point.   Agreed.

На второе, мне честное слово ... с большой колокольни Не нашел я что-то ни одной проги, котороя пользует inotify. Прошло каких-то пару месяцев всего. Пришлось свою писать
Насчет первого. У кого паранойя ? У меня ? Понятно, что против стандартов не попрешь. Но, к примеру, кто мешает сделать эту фишку только для рут-а ?
Я тебе "патч" отправил по асе. Не смотри патч, смотри суть

Это сообщение отредактировал(а) GrayCardinal - 30.10.2005, 07:46

Вторая версия патча ушла, короче . Все "пожелания" были учтены. Посмотрим что они на _это_ скажут.

Короче, братцы, не будет у вас PID'а. Видно не судьба

Цитата

процесс - сдох, и его PID занял другой.

_Они_ мне то же самое написали. Млин, я ж не собераюсь координаты запуска ядерных ракет определять по этому долбаному PID
Просто, к примеру, если мой бровзер загрузит страницу с ява-скриптом и начнет отсылать мой /etc/shadow на www.xakep.ru, я буду знать
1. Что /etc/shadow ушел налево
2. Дырка именно в этом бровзере
Что, только мне это надо ?

ЗЫ
если прогу слежения найснуть (nice -n -20), черта-с два успеет умереть старый и создаться новый процесс.

Это сообщение отредактировал(а) GrayCardinal - 3.11.2005, 12:07

Cardinal, пардон:

Цитата(GrayCardinal)

ЗЫ если прогу слежения найснуть (nice -n -20), черта-с два успеет умереть старый и создаться новый процесс.

"черта-с два"!="никогда"

когда ты найсишь процесс к-рый пишет на терминал/в файл, в конце концов ты увидишь в файле данные ПОСЛЕ того как произошел напр. fflush().
если когда изменение происходит в лог файл пишет кто-то длинную запись, то никто не обещает что твой write() или syslog() успеет написать в файл до того как произойдет следующий resched().
так, что ... не думаю что ты можешь такое утверждать. и вообще все записывается в какой-то буфер. обещается, что в конце концов запись будет в порядке сообщения, но когда именно функции записи вернутся - никто тебе не может сказать ( если ты используешь стандартную политику scheduling )

ладно изголятся: твоя утилитка полезна

пока.

ОК. Кто мешает на этапе програмки ? Получил event-у, СРАЗУ снял всю нужную инфу по процессу. И вообще. Просто строчку дописать в документашку что "правильность не 100%-ная". И усе.

ЗЫ.
просто обидно стало за свое творчество