Когда использовать pkexec против gksu/gksudo?
Существует два основных способа графического запуска приложений от имени пользователя root (или, в более общем случае, от имени другого пользователя). Такие программы, как gksu
, gksudo
, а также kdesudo
графические интерфейсы для sudo
, По сравнению, pkexec
графический интерфейс для PolicyKit.
При ручном запуске программ от имени пользователя root (или другого пользователя, не являющегося пользователем root), каковы преимущества / недостатки (если есть) использования pkexec
по сравнению с более традиционным методом использования sudo
внешний интерфейс?
3 ответа
PolicyKit более настраиваемый, хотя pkexec
не использует эту настраиваемость. Также, pkexec
показать пользователю полный путь к программе, которая будет запущена, чтобы пользователь был немного уверен в том, что произойдет. Так называемые "политики" PolicyKit могут быть использованы для установки дополнительных параметров. Например, должен ли пароль быть запомненным.
Что-то, что я получил от pkexec
руководство:
Среда, в которой PROGRAM будет его запускать, будет установлена на минимально известную и безопасную среду, чтобы избежать внедрения кода через LD_LIBRARY_PATH или аналогичные механизмы. Кроме того, для переменной среды PKEXEC_UID задан идентификатор пользователя процесса, вызывающего pkexec. В результате pkexec не позволит вам запускать, например, приложения X11 от имени другого пользователя, поскольку переменная окружения $DISPLAY не установлена.
Больше информации о политиках или определениях действий от pkexec
руководство:
To specify what kind of authorization is needed to execute the program /usr/bin/pk-example-frobnicate as another user, simply write an action definition file like this <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE policyconfig PUBLIC "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> <policyconfig> <vendor>Examples for the PolicyKit Project</vendor> <vendor_url>http://hal.freedesktop.org/docs/PolicyKit/</vendor_url> <action id="org.freedesktop.policykit.example.pkexec.run-frobnicate"> <description>Run the PolicyKit example program Frobnicate</description> <description xml:lang="da">Kør PolicyKit eksemplet Frobnicate</description> <message>Authentication is required to run the PolicyKit example program Frobnicate</message> <message xml:lang="da">Autorisering er påkrævet for at afvikle PolicyKit eksemplet Frobnicate</message> <icon_name>audio-x-generic</icon_name> <defaults> <allow_any>no</allow_any> <allow_inactive>no</allow_inactive> <allow_active>auth_self_keep</allow_active> </defaults> <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/pk-example-frobnicate</annotate> </action> </policyconfig> and drop it in the /usr/share/polkit-1/actions directory under a suitable name (e.g. matching the namespace of the action). Note that in addition to specifying the program, the authentication message, description, icon and defaults can be specified. For example, for the action defined above, the following authentication dialog will be shown: [IMAGE][2] +----------------------------------------------------------+ | Authenticate [X] | +----------------------------------------------------------+ | | | [Icon] Authentication is required to run the PolicyKit | | example program Frobnicate | | | | An application is attempting to perform an | | action that requires privileges. Authentication | | is required to perform this action. | | | | Password: [__________________________________] | | | | [V] Details: | | Command: /usr/bin/pk-example-frobnicate | | Run As: Super User (root) | | Action: org.fd.pk.example.pkexec.run-frobnicate | | Vendor: Examples for the PolicyKit Project | | | | [Cancel] [Authenticate] | +----------------------------------------------------------+ If the user is using the da_DK locale, the dialog looks like this: [IMAGE][3] +----------------------------------------------------------+ | Autorisering [X] | +----------------------------------------------------------+ | | | [Icon] Autorisering er påkrævet for at afvikle | | PolicyKit eksemplet Frobnicate | | | | Et program forsøger at udføre en handling der | | kræver privilegier. Autorisering er påkrævet. | | | | Kodeord: [___________________________________] | | | | [V] Detaljer: | | Bruger: Super User (root) | | Program: /usr/bin/pk-example-frobnicate | | Handling: org.fd.pk.example.pkexec.run-frobnicate | | Vendor: Examples for the PolicyKit Project | | | | [Annullér] [Autorisering] | +----------------------------------------------------------+ Note that pkexec does no validation of the ARGUMENTS passed to PROGRAM. In the normal case (where administrator authentication is required every time pkexec is used), this is not a problem since if the user is an administrator he might as well just run pkexec bash to get root. However, if an action is used for which the user can retain authorization (or if the user is implicitly authorized), such as with pk-example-frobnicate above, this could be a security hole. Therefore, as a rule of thumb, programs for which the default required authorization is changed, should never implicitly trust user input (e.g. like any other well-written suid program).
С помощью sudo вы можете установить политики для каждого пользователя и программы для сохранения или сброса среды вызывающих в контексте sudo. Политика env_reset установлена по умолчанию.
Вы не можете запускать графические приложения через pkexec без явной настройки для этого. Поскольку это всего лишь результат перезагрузки среды, это, очевидно, верно и для sudo. Однако обратите внимание, что ни pkexec, ни sudo не могут помешать злонамеренному приложению, работающему от имени root, получить всю необходимую информацию из диспетчера отображения или из файла X11-cookie пользователя. Последнее, оба или похожее, может даже быть сделано некорневыми приложениями в зависимости от обстоятельств.
Sudo не требует явных списков пользователей. Перечисление любой группы пользователей или даже установка разрешения для всех пользователей в целом может быть сделано. Директива target_pw позволяет этим пользователям проходить аутентификацию с учетными данными пользователя в том контексте, в котором они хотят запустить приложение, то есть root. Кроме того, одинаково традиционная программа su (su / gtksu / kdesu) может использоваться для того же самого без специальной настройки.
sudo также позволяет пользователю оставаться аутентифицированным в течение указанного времени. Опция называется тайм-аут, настраивается глобально, для пользователя или для приложения. Аутентификация может быть сохранена для tty или глобально для пользователя.
Хотя pkexec может не проверять аргументы, переданные в PROGRAM, sudo действительно имеет эту функцию. Признаюсь, однако, вы можете легко запутаться с этим, и это обычно не делается.
Вы можете немного настроить то, как вы хотите, чтобы программы запускались через pkexec: значок, текст для отображения, вы даже можете иметь материал для локализации и все такое. В зависимости от обстоятельств это может быть действительно изящно. Грустно, однако, что кто-то почувствовал необходимость изобретать велосипед для этой функции. Вероятно, это было бы чем-то, что можно поместить в графические оболочки gtksudo/kdesu.
Policykit - это только централизованная конфигурация. К сожалению, не очень. XML-файлы PK намного сложнее, чем то, что приложение может предоставить изначально без двоичных файлов. И никто не будет настолько безумным, чтобы использовать двоичные файлы... о, gconf... не бери в голову.
Несколько вещей, как pkexec
отличается от sudo
и его интерфейсы:
- Вы не можете запускать графические приложения через
pkexec
без явной настройки для этого. - Вы можете немного настроить, как вы хотите, чтобы программы запускались через
pkexec
: значок, текст для отображения, запоминать ли пароль или нет, разрешать ли ему графический запуск и многое другое. - Любой может запустить суперпользователя "Запуск от имени" (при условии, что он может аутентифицироваться как таковой), с
sudo
Вы должны быть перечислены вsudoers
подать в качестве администратора. gksudo
блокирует клавиатуру, мышь и фокус при запросе пароля,pkexec
не делает. В обоих случаях нажатия клавиш сниффы.- С
pkexec
Вы работаете в немного более санированной среде.
Попробуйте например:
cd /etc/init.d
sudo cat README
# and now the same with pkexec
pkexec cat README
# nice, huh?