LINUX.ORG.RU

Как написать setuid программу?

 , , ,


0

1

Задача предельно ясная: внутри программы, запускаемой любым пользователем сделать setuid на любого другого пользователя (в т.ч. root).

Сразу приходят в голову такие варианты решения:

  • Демон-процесс, запущенный под root и делающий fork->setuid->exec. И небольшой клиент, который говорит демону что делать
    Недостатки:
    • Потенциальная дыра в безопасности в линиях связи клиент-сервер
    • Порождённый процесс не будет потомком процесса исполняемого файла (т.е. клиента) со всеми вытекающими
  • Модуль ядра, который передает управление юзерспейсу с uid=0. И так же небольшой клиент для него.
    Недостатки:
    • Опять же дыра в связи
    • Дыра в безопасности: передача управления юзерспейсу из кернелспейса.
    • Зависимость от сборки ядра.
  • SUID-бит. Просто, элегантно, легко.
    Недостатки:
    • Бинарник должен принадлежать root
    • No (shebang) scripts allowed
    • Требуется вмешательство извне: установка соответствующих прав и владельца
  • Exploit. Недостатки:
    • Nuff said.

И попутно объясните пожалуйста чем отличается программа запущенная с (uid=***, euid=0) от той же программы но запущенной с (uid=0, euid=0) (кроме собственно uid)?

P.S. Да, я знаю, что это потенциальная дыра в безопасности, что уже есть sudo/PolicyKit и что при запуске такой программы в мире будет умирать котёнок. По этому избавьте от этих рассуждений.

Требуется вмешательство извне

Типа для демона и модуля не требуется? Еще 4): добавление правила для sudo. А если нужна только специфическая возможность - есть capabilities.

anonymous
()

Задача предельно ясная: внутри программы, запускаемой любым пользователем сделать setuid на любого другого пользователя

Если ты не пишешь линлокер с неграми и расчленёнкой, то это не задача.

Задача это работать с оборудованием, писать в логи и т.д. Все такие задачи обычно решаются однотипно: «добавьте пользователя в группу *-operator».

ziemin ★★
()
Ответ на: комментарий от Extraterrestrial

Пытаешься переизобрести sudo/su?

В постскриптуме всё сказано.

KennyMinigun ★★★★★
() автор топика
Ответ на: комментарий от ziemin

Все такие задачи обычно решаются однотипно: «добавьте пользователя в группу *-operator».

Да мне чисто в академических целях: почитал (еще раз) про setuid, стало интересно, как устроены su/sudo/PolicyKit/PowerBrocker/etc. А точнее вокруг чего они построены.

KennyMinigun ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Типа для демона и модуля не требуется?

Ну, демон и модуль — это некий стандарт: одно *должно* запускаться с-под root, а второе вообще в kernelspace. А вот ставить SUID бит на бинарниках — я редко встречал такую практику (разве что /sbin/poweroff)

KennyMinigun ★★★★★
() автор топика

Забавно, а у sudo/su оказывается просто выставлен suid-бит:

$ ls -l $(which sudo)
-rwsr-xr-x 1 root root 155008 Фев 10 21:16 /usr/bin/sudo

$ ls -l $(which su)
-rwsr-xr-x 1 root root 36936 Фев 17 04:42 /bin/su

Т.е. никаких заморочек с получением superuser извне. Запускаемся с EUID=0 -> проверяем-что-там-надо (пароль) -> setuid().

У меня убунта, в других дистрибутивах так же?

KennyMinigun ★★★★★
() автор топика
Ответ на: комментарий от KennyMinigun

У меня убунта, в других дистрибутивах так же?

Хы, а ты думал sudo работает через специальный модуль в ядре или отдельный демон?:)

xtraeft ★★☆☆
()
Ответ на: комментарий от xtraeft

Хы, а ты думал sudo работает через специальный модуль в ядре или отдельный демон?:)

Надо признать, да. Точнее — не знал как именно sudo работает.

KennyMinigun ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.