2016-02-02 10 views
0

ну, я просто хотел понять механизм setuid.so я написал программу C (prog1), которая запускает bash (я использовал system("/bin/sh") при исполнении & Я установил бит setuid для исполняемый файл (как root). Поэтому обычно, когда он выполняется другим пользователем, но не root, он устанавливает эффективный идентификатор работающего процесса равным 0 (корневой идентификатор), но реальный uid остается таким, каким он есть (в моем случае 1000 для пользователя тест).запуск root только с процессом без корня id

Теперь я написал еще один исполняемый (за ходом работы Prog2) & я дал разрешение только для выполнения корня -rwx------.

Я вошел в систему как пользователь «тест» & я казнен «PROG1» так Баш был введен, как задумано, я выполнил команду «идентификатор» & получил следующий результат, который также был предназначен:

uid=1000(test) gid=1001(test) euid=0(root)groups=1001(test),27(sudo) 

, как это показывает реальный UID 1000 и эффективный идентификатор id 0 (root), это именно то, что делает setuid-бит. Теперь мне нужно выполнить prog2 (может выполняться только корень) & Я был удивлен, что выполнение выполнено успешно & Я даже мог прочитать/etc/shadow ... это не проблема безопасности ??? ... я имею в виду, что обычно корневая программа чтения/записи/выполнения root никогда не может быть прочитана/записана/выполнена другим пользователем? ... так что, пожалуйста, можете ли вы дать мне полезную информацию об этом?!

ответ

0

При работе с linux при проверке разрешений файловой системы консультируется fsuid. Если не указано явно иначе, это fsuid соответствует euid процесса.

Действительно, почти все разрешения проверяются на действительный идентификатор пользователя (вот почему он называется ). Идентификатор реального пользователя используется, например, для проверки того, может ли быть отправлен сигнал (чтобы вы могли убить запущенные процессы suid). Многие оболочки также делают что-то вроде seteuid(getuid()); для повышения безопасности.