 |
|
|
|
Контролируем и ограничиваем системные вызовы с помощью systrace
Контролируем и ограничиваем системные вызовы с помощью systrace Наверняка вы не раз задумывались о том, как именно работает та или иная используемая вами программа. Разобраться помогут исходные текcты программы. Но что делать, если они недоступны? Как всегда быть в курсе того, что происходит у вас в системе? Systrace – инструмент для ограничения и контроля системных вызовов. Изначально systrace был написан для NetBSD, позже был портирован под OpenBSD, а в настоящий момент ведутся работы по переносу на Linux, FreeBSD и OpenDarwin. Любая программа в процессе свой работы использует системные вызовы. Что такое системный вызов? Его можно определить как некую функцию, которая позволяет вашей программе обращаться к ядру ОС для выполнения некого действия. В современных версиях UNIX-систем реализовано около 300 различных системных вызовов. И если такие инструменты, как ktrace (kernel process tracing) и truss (tracing system call), позволяют нам выступать лишь в качестве наблюдателей, systrace позволяет нам вмешиваться в происходящее. Пример использования Перейдем к практике. В качестве примера напишем простую программу: #include <stdio.h> void proc1(); int main() { printf("just a message\n"); mkdir(«test»); proc1(); } void proc1() { printf("just a dumb procedure\n"); } Как ясно из исходного текста, наша подопытная программа выполняет следующие действия:
Скомпилируем программу: #gcc -o proga proga.c На первый взгляд при выполнении нашей программы используются два системных вызова: mkdir и write. Хотя логично предположить, что, перед тем как «что-то» «куда-то» записать с помощью write, это самое «куда-то» нужно сначала открыть, а после записи закрыть, а значит, задействованы системные вызовы open и close . Также не лишено смысла предположение, что используется еще один системный вызов – exit. Итого пять вызовов. Посмотрим, как обстоят дела на самом деле: #systrace -A /path/to/program/proga Ключ -A указывает systrace автоматически создать политику для указанного исполняемого файла. Автоматический режим предполагает создание правил в режиме «разрешить все». После выполнения команды в домашнем каталоге пользователя появится подкаталог .systrace, в который будет помещен файл c правилами. Рассмотрим его:
Синтаксис правил достаточно прост: [системный вызов] [условие] [действие] Мы видим, что в процессе исполнения нашей программы используется несколько больше системных вызовов, чем можно было бы предположить с самого начала. Рассмотрим полученные правила.
Указывается, для какого бинарного файла политика описана ниже. Полный путь к исполняемому файлу нужен для того, чтобы исключить возможность применения политики для файла с таким же именем, но располагающимся в другом месте. Emulation: netbsd показывает, что будет использоваться ABI ОС NetBSD.
Как видно из названия, системному вызову mmap разрешено исполняться. Для позволения выполнения системного вызова используется действие – permit, для запрещения deny.
Тут мы видим, что системному вызову fsread будет разрешено выполниться в том случае, если запрошенный им файл будет /etc/ld.so.conf. Стоп, скажет внимательный читатель, системного вызова fsread не существует! И будет абсолютно прав. По умолчанию в systrace применяется использование псевдонимов для системных вызовов. Например: fsread является псевдонимом для stat, lstat, readlink, access, open. Но при желании режим использования псевдонимов можно отключить. В дальнейшем комментировании всего файла конфигурации смысла не вижу – все должно быть понятно и без этого. Что ж, политика для нашей программы создана, давайте попробуем ее выполнить под чутким руководством systrace: #systrace -a /home/01mer/labs/systr/proga
Как мы видим, все функции нашей программы выполнились. Предположим, что логика нашей программы изменилась, что будет происходить в этом случае? Давайте для примера изменим функцию proc1 в нашей программе. Для начала мы должны точно знать, что будем менять. Просто изменить пару строчек в исходном коде и перекомпилировать программу, конечно, можно, но я предлагаю более интересный подход. #objdump -d proga > proga.lst Программа objdump показывает информацию из бинарных/объектных файлов. Ключ -d указывает, что файл нужно дисассемблировать. Вывод информации для удобства произведем в proga.lst В полученном листинге находим нашу процедуру proc1.
Если не вдаваться в подробности, мы видим тут «подготовку» стека, выполнение вывода на экран текста, очищение стека и возврат в «основную» программу. Итого 25 байт, которые мы должны изменить на что то свое. Негусто, но вполне хватит для классического shell-кода вызывающего /bin/sh, он занимает как раз 23 байта (не забывайте, что 2 байта нам нужны для возврата в «основную программу»). А это именно то, что нам нужно – используется системный вызов, описания которого нет в наших правилах. Читаем man 2 execve. Для запуска /bin/sh через execve мы должны написать следующие: execve("/bin/sh/",0,0); Что можно свести к следующему коду на ассемблере: xorl %eax,%eax pushl %eax pushl $0x68732f2f pushl $0x6e69622f movl %esp,%ebx pushl %eax pushl %esp pushl %ebx pushl %eax movb $0x3b,%al int $0x80 Все это можно представить в следующих опкодах: 31 c0 50 68 6e 2f 73 68 68 2f 2f 62 69 89 e3 50 54 53 50 b0 3b cd 80 Вооружившись hex-редактором, открываем исполняемый файл с нашей программой и меняем содержимое proc1 на представленные выше опкоды. Само собой, нам нужно оставить команды возврата в «основную» программу. После успешного редактирования проверяем результат: # home/01mer/labs/systr/proga
Как вы видите, вместо вывода на экран «just a dumb procedure» у нас запустился /bin/sh. А теперь попробуем выполнить то же самое, но уже под контролем systrace: # systrace -a /home/01mer/labs/systr/proga
Как мы видим, попытка запустить модифицированную программу провалилась. Автоматизируем создание правил Доверить автоматическое создание правил systrace допустимо только в том случае, когда есть уверенность на 99,9% в том, что мы запускаем. Во всех остальных случаях рекомендуется создавать правила в интерактивном режиме. Рассмотрим пример: # systrace -t /home/01mer/labs/systr/newproga Ключ -t указывает, чтобы интерактивное создание правил проходило в текстовом режиме. Если у вас на машине установлены x-windows, вы можете воспользоваться xsystrace.
Тут systrace ожидает от нас ввода permit, в случае если мы желаем разрешить системный вызов или deny для запрета. Конечно, интерактивное создание правил – процесс достаточно трудоемкий и занимает много времени, но полученный результат того стоит. Вы будете точно знать, когда и какие системные вызовы использует программа. Дополнительные «полезности» В синтаксисе правил вы можете использовать необязательные опции протоколирования. Например: netbsd-fsread: filename eq "/lib/libc.so.12.114.1" then permit log параметр log указывает systrace протоколировать каждое обращение к указанному фильтру. По умолчанию протоколируются лишь попытки выполнить системные вызовы, о которых нет ни слова в правилах. Для протоколирования systrace использует syslogd. А это значит, что мы можем немного поправить /etc/syslog.conf, чтобы все сообщения от systrace размещались в отдельном файле. При желании даже можно написать маленький парсер для получаемых логов. Но это уже по желанию, все в ваших руках. Нельзя не отметить еще одну необязательную опцию – errorcode. С её помощью мы можем указать, какая ошибка будет возвращаться при обращении к запрещенному системному вызову. Например: netbsd-fswrite: filename eq "/some/where/file" then deny[EIO] В данном случае при попытке записи в файл системному вызову будет возвращена ошибка – input/outpu error. Для ознакомления с полным списком errno-кодов возврата вы можете прочитать man errno. Заключение Мы рассмотрели простой пример использования systrace. Изложенных сведений вам будет достаточно и для создания более сложных собственных правил для различных программ. Применение политик ограничения системных вызовов для конкретных программ поможет вам существенно повысить степень защиты ОС в целом. |
АЛЕКСАНДР БАЙРАККомментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
