#objective-c #shell #root #nstask #suid
#objective-c #оболочка #root #nstask #suid
Вопрос:
Я работаю над приложением, которому необходимо использовать dd (я делаю это с помощью сценария оболочки в комплекте приложений, который собирает параметры из самого приложения, выполняет некоторые проверки и затем запускает dd).
Чтобы выполнить эту операцию, мне нужно вызвать dd с помощью root, и я уже просмотрел несколько решений в StackOverflow. Самым простым в реализации мне показался этотhttp://www.sveinbjorn.org/STPrivilegedTask
Проблема в том, что моя NSTask выполняет некоторые сложные операции чтения / записи (отсутствующие в STPrivilegedTask) и не обязательно должна быть полностью привилегированной.
Итак, я написал небольшой вспомогательный инструмент на c, который вызывает мой скрипт с правильными параметрами из моего приложения. Решение, о котором я подумал, состоит в том, чтобы использовать STPrivilegedTask для SUID при запуске моего небольшого вспомогательного инструмента, чтобы я мог запустить его (и, следовательно, мой скрипт и dd) с root, и вскоре после успешного запуска я вернул вспомогательному инструменту значение, отличное от SUID (и я делаю то же самое, если какая-либо ошибка при выходе из приложения, запуске приложения и т.д. Для большей безопасности).).
Я реализовал это и работает довольно хорошо, может быть, это не идеально, но я думаю, что нахождение всего внутри пакета и работа со вспомогательным инструментом в SUID только для запуска звучит достаточно безопасно.
Есть мысли?
Спасибо!
Ответ №1:
Вы можете использовать изолированную среду для запуска нового процесса в вашей NSTask
sandbox-exec -f <profile> <command>
sandbox-exec -f my_profile.sb "/bin/dd -if=/dev/disks01 of=/dev/target"
Здесь есть несколько примеров профилей
/usr/share/sandbox/
Вы должны предоставить достаточный доступ для работы dd, я не пробовал и не проверял, что требуется для dd, я бы начал с чего-то вроде этого:
(version 1)
(deny default)
(debug deny)
(import "system.sb")
(allow file-read-data file-write-data file-ioctl (regex #"^/dev/.*$"))
(allow process-exec (literal "/usr/sbin/helper"))
Обновить:
Стоит упомянуть, что вы можете использовать
изолированная среда-команда exec -p
Комментарии:
1. Привет, Jsmp, я попробовал систему изолированной среды, как я использовал ее в прошлом, но это не то, что мне нужно, мне просто нужно выполнить задачу от имени root (также для других команд, которые мне нужны, таких как mount и umount и т.д.). У кого-нибудь есть предложения по поводу моего решения helperTool для временного SUID? Возможные пробелы и альтернативы?
2. В дополнение к этому, я реализовал в helperTool также код для изменения самого себя с suided на non suided в конце его собственного процесса. Таким образом, он получает SUID из приложения, запускает скрипт с правильными параметрами и сразу после этого автоматически отключает SUID. Кажется, это хороший дополнительный шаг в области безопасности..
3. Привет, opoloko, я вижу, тебе просто нужен способ сохранить файл в безопасности. С моей точки зрения, все еще существует случай, когда пользователь может завершить работу приложения, оставив ему SUID, прежде чем оно отключит его.
4. Я нашел это bdunagan.com/2008/11/23 /… может быть, это полезно для вас. Вы можете использовать sudo в своей задаче и запросить авторизацию пользователя для запуска такой задачи с помощью платформы безопасности.