Защищённая передача параметров , Linux, межпрограмное взаимодействие

[Pavia]

Я знаю что тут продвинутые мастера и они то должны знать всё.
Подскажите в какую сторону копать?

Всё дело происходит в нашем любимом Linux ветка Debian(нужное подчеркнуть ).

Есть программа1 запущенная от User1.
Есть программа2 которая должна работать с SSH. Хочу для неё завести учётку User2(или root)

Если первая программа будет взломана, то она не должна получить доступ к ключам программы 2. Думаю что их надо разделить при помощи пользователей и организовать между ними передачу параметров.

Программа2 предназначена для выполнения некоторой команды которой ей сообщает программа1.
Собственно вопрос кто в этом разбирается как это организовать? Достаточно ли программу2 поместить в sbin и использовать системный вызов system()? Тогда по идеи ключи у неё будут храниться в хранилище суперпользователя и первая программа не сможет к ним получить доступ.

Или же ACL настроить разрешения на запуск? Но тогда от какого пользователя она будет запущена, случаем не от User1?

Или надо как-то хитро это всё вызывать? Честно ума не приложу как и куда копать.

Сообщение отредактировано: Pavia - 16.05.17, 05:22

[XandoX]

Цитата

Достаточно ли программу2 поместить в sbin и использовать системный вызов system()?

То что она лежит в sbin еще не гарантирует, что она будет запущена от суперпользователя. Или еще от какого-нибудь пользователя отличного от того кто запустил на исполнение.
Не говоря уже про то, что в таких случаях system лучше не использовать, особенно если ты формируешь команду из пользовательского ввода.

Цитата

Или же ACL настроить разрешения на запуск? Но тогда от какого пользователя она будет запущена, случаем не от User1?

Есть suid для исполняемых фалов, которые при запуске меняет эффективный uid у процесса на тот, кому принадлежит исполняемый файл. И кажется это не совсем то что тебе нужно.

Я бы делал так:
При запуске command1 он должна запускаться с эффективным uid от root-а.
Дальше она порождает два процесса
1) Интерфейсный - с uid от пользователя user1 (этот процесс не обязательно порождать, можно просто основной в правах понизить)
2) Командный - c uid от пользователя user2
Интерфейсный с командным может общаться по любому IPC и командный может в любой момент дергать command2.

[Pavia]

Цитата

Я бы делал так:

А как понизить? Через setuid?

Цитата XandoX @ 16.05.17, 08:32

Есть suid для исполняемых фалов, которые при запуске меняет эффективный uid у процесса на тот, кому принадлежит исполняемый файл. И кажется это не совсем то что тебе нужно.

Вроде как эта устаревшая фишка и она более не работает и надо делать через SUDO.

[XandoX]

Цитата Pavia @ 16.05.17, 10:50

Вроде как эта устаревшая фишка и она более не работает и надо делать через SUDO.

Не, само sudo как по твоему работает.

Цитата Pavia @ 16.05.17, 10:50

А как понизить? Через setuid?

ага, ну и про группу не забыть.

[Pavia]

Цитата XandoX @ 16.05.17, 10:52

Не, само sudo как по твоему работает.

http://www.unix.com/apropos-man/all/0/suid/
Я так думаю путь /SBIN был заменён на бит S-бит в FS а затем на эффективный SUID

SUDO работает и без этого оно просто проверяет права и выполняет команды.
Хотя при смене прав она проверяет пароль и после этого меняет пользователя через
setuid().

Я так понимаю проверку пользователя она должна делать через pam_chauthtok()

setuid() - прооверяет системный пользователь или не системный если не системный то проверяет есть ли разрешение на смена uid.
Так как SUDO имеет выставленный SUID бит то она запускается от супер-пользователя и у ней нет проблем с setuid().

В принципе можно было-бы работать без SUID, но тогда нужен какой-то ещё механизм.

Добавлено 16.05.17, 12:15
Себе на заметку https://www.freebsd.org/doc/en/articles/pam...ample-appl.html

[XandoX]

Цитата

SUDO работает и без этого оно просто проверяет права и выполняет команды.

Цитата

Так как SUDO имеет выставленный SUID бит то она запускается от супер-пользователя и у ней нет проблем с setuid().

Кажется противоречие. Или я не правильно понял без чего работает SUDO?

[Pavia]

XandoX
Это я в первом случае мысль не до конца развил. Не работает, а гипотетически может.
А так SUID там однозначно стоит. проверяется ls -L /usr/bin/sudo