[linux] intercepting system calls
там есть спец механизм, называется system call accounting кажется.
а можно задачу полнистью?
что мешает пропатчить - я так всегда и делаю
что мешает пропатчить - я так всегда и делаю
Зачем пересобирать ядро?
Пишешь небольшой модуль.
Он загрузившись вырезает несколько первых инструкций интересующего тебя system call'а.
Записывает на их место прыжок на свою функцию.
В этой свей функции ставишь себе галочку, что произошел такой-то вызов.
Затем исполняешь вырезанные инструкции.
Затем прыгаешь обратно и исполняешь оставшиеся инструкции.
Пишешь небольшой модуль.
Он загрузившись вырезает несколько первых инструкций интересующего тебя system call'а.
Записывает на их место прыжок на свою функцию.
В этой свей функции ставишь себе галочку, что произошел такой-то вызов.
Затем исполняешь вырезанные инструкции.
Затем прыгаешь обратно и исполняешь оставшиеся инструкции.
> Записывает на их место прыжок на свою функцию.
В это время на другом процессоре этот недозаписанный код пытается выполниться.
В это время на другом процессоре этот недозаписанный код пытается выполниться.
А big kernel lock на что?
Уж явно не для того, чтобы брать его при каждом системном вызове.
Ядро патчится один раз. Что не так?
> > Записывает на их место прыжок на свою функцию.
> В это время на другом процессоре этот недозаписанный код пытается выполниться.
А что, в процессе подгрузки модуля могут выполняться сисколлы?
> В это время на другом процессоре этот недозаписанный код пытается выполниться.
А что, в процессе подгрузки модуля могут выполняться сисколлы?
> А что, в процессе подгрузки модуля могут выполняться сисколлы?
А как ты им запретишь?
А как ты им запретишь?
Можно запретить прерывания, например.
И что, по-твоему, будет?
Эээээ... Разве linux уже не сидит на 80h? Или я что-то проспал?
1) Что делает int при запрещённых прерываниях?
2) Не забыл, что запретить их нужно на _остальных_ процессорах?
2) Не забыл, что запретить их нужно на _остальных_ процессорах?
1) Вероятно пропадает впустую. Хотя это наверное от платформы зависит.
2) Я этого не знал
А что этому мешает?
2) Я этого не знал
А что этому мешает?PS: в конце концом можно отменить шедулинг процессов на это время. Тогда никто из них не сможет выполнить syscall.
> Вероятно пропадает впустую.
А мне вот интуиция подсказывает, что выполнится как обычно.
А если бы и пропало, это лучше?
> Я этого не знал.
Это написано выше.
> А что этому мешает?
Они другие, у них есть свои команды, которые они выполняют.
А мне вот интуиция подсказывает, что выполнится как обычно.
А если бы и пропало, это лучше?
> Я этого не знал.
Это написано выше.
> А что этому мешает?
Они другие, у них есть свои команды, которые они выполняют.
Это уже лучше, но почему-то так не сделали.
1) ? Это как? Как может выполниться прерывание если они запрещены?
2) Не написано. Я например думал что прерывания запрещаются сразу на всех процессорах. Видимо я ошибался.
2) Не написано. Я например думал что прерывания запрещаются сразу на всех процессорах. Видимо я ошибался.
Если это делается только для подсчета, то может быть проще будет libc подхачить? Конечно, это будет обходиться, но в случае подсчета наплевать.
А в линуксе int80h попадает на случайный процессор?
Я честно говоря имею весьма слабое представление как происходят прерывания на мультипроцессорных машинах. Но я не понимаю какое отношение имеет этот вопрос к теме.
Ну типа если оно зароучено на один процессор, то можно запрещать только на нём. Вряд ли конечно это так.
Это всё только для внешних прерываний.
А те, что генерирует инструкция int, и исключения --- работают по-другому.
Кроме того, int 80 - это только на i386.
А те, что генерирует инструкция int, и исключения --- работают по-другому.
Кроме того, int 80 - это только на i386.
вы отдалились от темы вопроса.
перехват системеного вызова раньше делали просто записью в массив указателя на другую функцию обработчик, что начинает криво работать если таких хуков много а мы потом ещё хочум их убирать.
а теперь они нагородили что-то новое...
перехват системеного вызова раньше делали просто записью в массив указателя на другую функцию обработчик, что начинает криво работать если таких хуков много а мы потом ещё хочум их убирать.
а теперь они нагородили что-то новое...
по большому счету ничего не мешает
просто мне потом процесс инсталла как то не очень нравится
просто мне потом процесс инсталла как то не очень нравится
Мне важно, чтобы никакой процесс не мог избежать учести быть посчитанным =)
Иначе смысл подсчета теряется
Иначе смысл подсчета теряется
а теперь они нагородили что-то новое...Такое впечатление, что они ничего не городили, а просто волевым решением убрали из экспортов этот сис_колл_тейбл и все. И никаких альтернатив не предлагают пока.
Вчера беглый поиск по "system call accounting" ничего не дал, пойду сейчас еще покопаюсь...
В данном случае избежать сможет только статически слинкованный.
Вообще эта шняжка по слежению за процессами, чтобы потом инфу отсылать некой программе, претендующей на функциональность IDS.
Посему, любая возможность избежать учести быть посчитанным, сводит на нет весь смысл шняжки.
Посему, любая возможность избежать учести быть посчитанным, сводит на нет весь смысл шняжки.
Понятно. Я думал это не для security, а что бы провести какой-то benchmark.
Можно попробовать написать LSM-модуль.
И кажется, недавно какое-то API специально для аудита добавили.
И кажется, недавно какое-то API специально для аудита добавили.
Ну в конце-концов тебе никто не может помешать добавить в ядре в нужном сисколле
Изменение собственно ядра в этом случае минимально.
И написать модуль который будет подменять этот хук.
lock(my_hook_mutex)//нужно еще понять какой lock/unlock
if ( my_hook )
{
my_hook;
}
unlock(my_hook_mutex)
....blavlabla
EXPORT_SYMBOL(my_hook); //точно не помню :)
EXPORT_SYMBOL(my_hook_mutex); //точно не помню :)
Изменение собственно ядра в этом случае минимально.
LSM вроде для ветки 2.6 нету, по крайней мере на http://lsm.immunix.org/ про это ни слова
А вот про апи как раз я и спрашивал. подсказал что есть audit syscall опция в ядре. похоже что это то что надо, вроде даже есть сурс это дело юзающий, правда туда еще не глядел. Так что если бы кто еще ткнул носом в доку по этому делу, было бы вообще замечательно, и вопрос был бы исчерпан =)
А вот про апи как раз я и спрашивал. подсказал что есть audit syscall опция в ядре. похоже что это то что надо, вроде даже есть сурс это дело юзающий, правда туда еще не глядел. Так что если бы кто еще ткнул носом в доку по этому делу, было бы вообще замечательно, и вопрос был бы исчерпан =)
Ну просто сурсы ядра вообще не хочется править =)
То, что его можно поправить и не париться, это я еще в первом посте написал =)
То, что его можно поправить и не париться, это я еще в первом посте написал =)
Как тебе ответили, есть такая штука как LSM. При любом системном вызове есть следующая проверка:
capable вызывает функцию проверки из соответствующего загруженного модуля. Можно написать LSM модуль, который еще ко всему прочему делает то что тебе нужно.
if ( !capable( BLABLABLA ) )
{
return SOMETHING_BAD;
}
PS: взгляни на security/security.c
Оставить комментарий
katrin2201
субж есть bad practice, в ветке ядер 2.6 так вообще deprecatedтипа, ищите другие пути
Хорошо, предложите другой путь получения уведомления о создании нового процесса, кроме как перехват sys_execve? Ткните носом хотя бы куда-нибудь...
Не патчить же сорсы ядра и пересобирать ядро...