2010-01-27 5 views
4

Предположим, Linux, двоичное foobar, который имеет два различных режима работы:Ограничение доступа системного вызова для приложения Linux

  • Режим A: хорошо себя режим, в котором системные вызовы a, b и c используются.
  • Режим B: Неверный режим, в котором используются системные вызовы a, b, c и d.

a системные вызовы, b и c безвредны, в то время как системный вызов d является потенциально опасным и может привести к нестабильности в машине.

Предположим, что какой из двух режимов запуска приложения является случайным: приложение запускается в режиме A с вероятностью 95% и в режиме B с вероятностью 5%. Приложение поставляется без исходного кода, поэтому его нельзя модифицировать, работать только как есть.

Я хочу убедиться, что приложение не может выполнить syscall d. При выполнении syscall d результат должен быть либо NOOP, либо немедленным завершением приложения.

Как достичь этого в среде Linux?

+0

Не могли бы вы пояснить смысл «вероятности» в вашем вопросе в случае, если есть что-то, чтобы неправильно понять это? –

+0

Паскаль: Конечно! Сообщение отредактировано с уточнением. Для целей этих вопросов «выбор режима» является случайным. – knorv

ответ

6

Прилагается ли приложение статически?

Вы можете переопределить некоторые символы, например, позволяет переопределить socket

int socket(int domain, int type, int protocol) 
{ 
     write(1,"Error\n",6); 
     return -1; 
} 

Затем построить библиотеку:

gcc -fPIC -shared test.c -o libtest.so 

Бежим:

nc -l -p 6000 

Ok

А теперь:

$ LD_PRELOAD=./libtest.so nc -l -p 6000 
Error 
Can't get socket 

Что происходит при запуске с переменной LD_PRELOAD=./libtest.so переопределяет символов, определенных в libtest.so над тыс определены в библиотеке.

+0

Это действительно не соответствует требованиям безопасности? Достаточно легко получить код для загрузки соответствующего номера системного вызова в «eax» или независимо от того, какие соглашения о процессоре есть, а затем передать управление в конец «a», «b» или «c» syscalls. Изменение таблицы syscall для каждого процесса и изменений загрузчика (например, SELinux) - единственный способ остановить повреждение пользовательского пространства. См. Например, [ROP в wikipedia] (https://en.wikipedia.org/wiki/Return-oriented_programming). По крайней мере, этот ответ предполагает, что некоторые вещи в системе находятся вне компромиссов. –

3

Это одно из возможных применений sandboxing (в частности, выполнение на основе правил). Одна популярная реализация - SELinux.

Вам понадобится write the policy, что соответствует тому, что вы хотите разрешить процессу.

+0

Это, безусловно, прецедент для SELinux. Имеются другие технологии песочницы. – stsquad

+0

@stsquad Я включил ваш комментарий. Возможно, вы отреагировали частично на «претензии» в предыдущей версии ... Я сформулировал это так, потому что услышал, что SELinux не так полезен на практике именно из-за необходимости адекватной политики. Не пробовав это, у меня нет мнения так или иначе, поэтому, возможно, новая версия лучше с этой точки зрения. –

6

Кажется, что systrace делает именно то, что вам нужно. От Wikipedia page:

Приложение допускает выполнение только тех системных вызовов, которые указаны как разрешенные в политике. Если приложение пытается выполнить системный вызов, который явно не разрешен, возникает сигнал тревоги.

Смежные вопросы