Policykit 1 как добавить приложение

Обновлено: 22.01.2025

Polkit (прежнее название: PolicyKit) — библиотека для UNIX-подобных операционных систем. API библиотеки используется для предоставления непривилегированным процессам возможности выполнения действий, требующих прав администратора. Использование Polkit противопоставляется использованию таких систем, как sudo, но не наделяет процесс пользователя правами администратора, а позволяет точно контролировать, что разрешено, а что запрещено.

Все политики находятся в /usr/share/polkit-1/actions/ в формате *.policy Каждая политика представляет собой xml-файл, в котором описываются запросы к polkit. Каждый запрос имеет три условия, прописанных в секции defaults:

1. Запрос от любого пользователя. Тег <allow_any>

2. Запрос от неактивного пользователя. Тег <allow_inactive>

3. Запрос от активного пользователя <allow_active>

Внутри каждого тега прописывается возвращаемое значение. Используются следующие варианты значений:

yes - предоставить разрешения

no - заблокировать разрешения

auth_self - пользователь должен ввести свой пароль для аутентификации

auth_self_keep_session - пользователь должен ввести свой пароль для аутентификации один раз за сессию, разрешение предоставляется для всей сессии

auth_self_keep_always - пользователь должен ввести свой пароль для аутентификации один раз, разрешение предоставляется для текущей и будущих сессий

auth_admin - пользователь должен ввести пароль admin при каждом запросе

auth_admin_keep_session - пользователь должен ввести пароль admin, разрешение предоставляется для всей сессии

auth_admin_keep_always - пользователь должен ввести пароль admin, разрешение предоставляется для текущей и будущих сессий

По-умолчанию, запрашивается пароль пользователя, находящегося в группе wheel. Для того, чтобы запрашивался пароль root необходимо добавить правило с цифрами вначале имени больше 50 с таким содержанием:

Для начала определяем какую политику мы хотим изменить, для этого находим в /usr/share/polkit-1/actions/ требуемую.
Редактируем новый файл с политикой:

В параметре action передается объект с информацией о совершенном процессе и связанные с этим действием параметры (например, если запрошенное действие монтирование съемного диска, то в параметре action будут переданы серийный номер диска, его id, файловая система и т.д).

В параметре subject передается объект с информацией о пользователе, запустившем процесс. Этот объект имеет следующие атрибуты:

id – идентификатор процесса;
user – имя пользователя;
groups – список групп, в которые входит пользователь;
seat – местонахождение субъекта (пустое значение, если местонахождение не локальное);
session – сессия субъекта;
local – true, только если местонахождение имеет локальный характер;
active – true, только если сеанс активен.

Пользователи часто жалуются на необходимость вводить пароль при монтировании разделов в файловом менеджере и создании нового подключения в NetworkManager, а также невозможность извлечь usb-флэш или лоток оптического привода. За эти разрешения отвечают:

org.freedesktop.udisks2.filesystem-mount-system - разрешение на монтирование файловых систем системных устройств

org.freedesktop.udisks2.filesystem-mount-other-seat - разрешение на монтирование файловых систем с устройств подключенных в другое место

org.freedesktop.udisks2.eject-media-other-seat - разрешение на извлечение лотка оптического привода

org.freedesktop.udisks2.power-off-drive-other-seat - разрешение на извлечение usb-флеш

Примечание: Устройства хранения информации, делятся на системные, которые не считаются извлекаемыми, и не-системные, к которым относятся USB подключаемые накопители, Flash медиа и оптические приводы. Для каждой из групп устройств, системных и не-системных (т.н. извлекаемых - removable), для одной операции часто нужно два polkit actions, по одному на группу устройств.

Чтобы узнать является ли устройство системным, на которые распространяется действие org.freedesktop.udisks2.filesystem-mount-system, выполните сначала команду, которая выведет все подключенные накопители:

Затем команду с именем вашего устройства. Например /dev/sdb. Статус true для HintSystem, в выводе команды говорит, что это системное устройство:

Для несистемных устройств, на которые распространяется действие org.freedesktop.udisks2.filesystem-mount-other-seat, для HintSystem статус будет false

Сделаем так, чтобы если пользователь находится в системной группе xgrp, то для него запросы пароля не должны будут выполняться для этих действий. Для этого (все действия выполняются от root):

Пример создания правила, разрешающего пользователю выполнять монтирование и извлечение устройств — с запросом пароля (при указании polkit.Result.AUTH_SELF — будет запрошен пароль текущего пользователя, polkit.Result.AUTH_ADMIN — администратора). При подключении съемного устройства записывать в системный журнал какое устройство было подключено и каким пользователем:

При монтировании USB-диска в системном журнале появятся записи:

Просмотреть факты подключения конкретного носителя, можно выполнив команду:

PolicyKit присутствует практически в любом современном дистрибутиве Linux. Он является хорошо отлаженной частью операционной системы и в то же время постоянно развивается вместе с ней. Как правило, работа PolicyKit почти незаметна для пользователя и редко требует вмешательства. Вопросы могут возникать лишь в тех случаях, когда на экране монитора появляются окна, подобные показанному ниже, и это кажется не совсем обоснованным.

Окно авторизации.

Назойливое требование ввода пароля для выполнения обыденного, хорошо понятного или часто повторяющегося действия может стать поводом для коррекции работы PolicyKit.

Немного о том, что это и как работает

PolicyKit дополняет базовую модель разграничения прав доступа DAC (Discretionary Access Control), принятую в UNIX-подобных операционных системах. С небольшими упрощениями основную идею модели DAC можно изложить буквально в нескольких словах. Например, так: любой объект операционной системы является файлом и для каждого файла определены права на чтение, запись и выполнение отдельно для владельца, для членов группы и для всех остальных.

Модель DAC проста и эффективна. Но надо понимать, что она разрабатывалась во времена майнфрэймов, когда пользователь и администратор системы на самом деле были разными людьми и имели полномочия разного уровня. Очевидно, что для операционной системы, установленной на персональном компьютере требуется более гибкая модель. Для пользователя персонального компьютера такие действия как установка системного времени или даты, подключение носителей, настройка сетевого соединения, монитора или клавиатуры являются обыденными. Но по своей сути - это системные операции и они требуют прав суперпользователя. Как правило, на персональном компьютере их выполняет пользователь, который скорее всего не имеет в этот момент нужных привилегий. Но, несмотря на это, если ему все же требуется выполнить подобную операцию, то это во многих случаях не должно быть связано с необходимостью ввода административного пароля. Ввод пароля в таких ситуациях наверняка будет восприниматься как помеха, даже как признак враждебного поведения системы.

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

Работает это следующим образом. Любой запрос на выполнение действия в системном контексте, поступивший от работающего пользовательского процесса, отслеживается с помощью PolicyKit. В соответствии с имеющимися правилами PolicyKit принимает решение о том, может ли быть выполнено это действие, и, если может, то - при выполнении каких условий. Это решение - запрет, разрешение или разрешение с условием - передается системной программе, которая затем действует соответствующим образом. Другими словами, хотя непривилегированный пользовательский процесс (Subject) и привилегированный системный процесс (Mechanism) общаются между собой напрямую, решение принимает третья сторона - PolicyKit.

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

Логика работы PolicyKit.

Условием выполнения действия может быть, например, ввод оператором пароля. Для взаимодействия с оператором используется агент (Authentication agent), который при необходимости показывает оператору окно с соответствующим требованием. Агент предоставляется пользовательским окружением, например, агент PolicyKit для GNOME. Практически все современные пользовательские окружения, такие как GNOME, KDE, MATE, Xfce и другие, имеют в своем составе соответствующих агентов для взаимодействии с PolicyKit.

PolicyKit включает в себя соответствующий программный интерфейс (API), предназначенный для того, чтобы приложения могли использовать его возможности. Именно в приложениях определяются те действия (Action), которые будет отслеживать PolicyKit. На практике могут встретится программы, которые не умеют взаимодействовать с PolicyKit. Но это скорее исключение.

Для действий, которые определены в приложении, существуют соответствующие правила их выполнения (Authorization Rules). Набор таких правил для конкретного приложения называется политикой (Authorization policy).

Примерно с 2007 года PolicyKit начал использоваться во всех наиболее популярных дистрибутивах Linux и их производных - в Debian, Ubuntu, Fedora, Red Hat, OpenSUSE, Gentoo, Slackware, Archlinux и многих других. Фактически он стал стандартом в своей области.

Все изложенное ниже относится у дистрибутиву Fedora 21, но может с успехом использоваться для понимания принципов настройки PolicyKit в любых системах Linux. В данном случае использовалось пользовательское окружение MATE, но это также не принципиально.

Разработчики дистрибутивов настраивают работу PolicyKit исходя из своих представлений о безопасности. Понятно, что сервер и рабочая станция будут иметь разные настройки. При адекватном выборе дистрибутива пользователь обычно не сталкивается с какими-либо неожиданными проблемами. Но иногда все же имеет смысл внести в работу PolicyKit некоторые изменения. Это один из тех немногих случаев, когда простыми средствами можно сделать собственный компьютер чуть более отзывчивым и дружелюбным.

Явные и неявные разрешения

Явные разрешения (Explicit privileges) относятся к конкретным пользователям или группам пользователей. При этом явные разрешения могут содержать ограничения. Например, ограничением может быть требование использовать только локальную консоль.

Явные разрешения можно предоставлять или запрещать. Это похоже на всем известные списки доступа (ACL). Запрет имеет приоритет. Другими словами, если пользователю в одних политиках разрешено какое-либо действие, а в других оно запрещено, то выполнить это действие он не сможет.

Неявные разрешения (Implicit privileges) определяются для пользовательской сессии в целом. Эти разрешения, в свою очередь, могут относится к активным или к неактивным сессиям. Активная сессия - это та, в которой пользователь работает в настоящий момент.

Для принятия решения PolicyKit располагает информацией двух видов: описанием возможных действий и описанием правил для их выполнения.

Файлы действий

Список всех возможных действий содержится в файлах, которые находятся в каталоге /usr/share/polkit-1/actions. Эти файлы записаны в формате XML, что позволяет просматривать их в текстовом редакторе или даже в браузере.

Имена файлов действий составлены из названия разработчика программного обеспечения (вендора), названия программы или группы действий и заканчиваются словом policy. Имя каждого файла вполне соответствует той группе действий, которые в нем перечислены. Средняя часть имени файла - название программы или группы действий - является в данном случае смысловой. Именно на нее надо обращать внимание, если требуется определить, в каком файле описано требуемое действие.

Для примера посмотрим на содержание файла org.x.xf86-video-intel.backlight-helper.policy.

Видно, что кроме собственно описания действия такие файлы содержат описание правил авторизации для выполнения этих действий. Причем эти правила являются правилами по умолчанию. Именно эти правила составляются разработчиками дистрибутива. Данные правила можно изменять редактированием XML-файлов .policy, но этот метод не является правильным из-за того, что при обновлении программ сделанные изменения пропадут.

Файлы и правила

/etc/polkit-1/rules.d - предполагается, что здесь располагаются некоторые файлы правил, подготовленные разработчиками дистрибутива и все файлы правил, подготовленные администратором системы. При персональной настройке правил располагать соответствующие файлы надо именно в этом каталоге.
/usr/share/polkit-1/rules.d - данный каталог содержит файлы правил, которые написаны разработчиками приложений и дистрибутива. Размешать файлы со своими правилами здесь настоятельно не рекомендуется из-за того, что при обновлении программ сделанные изменения скорее всего пропадут.

В июне 2012 года David Zeuthen сообщил в своем блоге, что собирается переписать ту часть PolicyKit, которая работает с файлами правил. После проведения предварительных тестов он остановился на варианте с использованием языка программирования JavaScript. Такой выбор David обосновал тем, что ему хорошо знаком SpiderMonkey, интерпретатор JavaScript, а также тем, что он постоянно общается с людьми, которые имеют опыт его внедрения в GNOME Shell.

David привел достаточно веские аргументы в пользу намечавшегося кардинального изменения PolicyKit - повышение гибкости и увеличение скорости работы. Несмотря на это, по тем ответам, которые он получил, видно, что разразилась настоящая буря. Потому что минусов тоже хватало. Совершенно ясно, что среди обычных пользователей, да и среди системных администраторов Linux не так уж много тех, кто умеет программировать на JavaScript. Сам язык имел не очень хорошую репутацию в плане безопасности. К тому же считалось, что его место - Web. Кроме того, были опасения, что новый PolicyKit будет требовать установки большого количества дополнительного программного обеспечения из-за зависимостей, связанных с использованием JavaScript. При этом, как предполагали оппоненты, возможно значительное снижение скорости его работы. Накал обсуждения был велик.

Однако, решение было принято. Новая версия PolicyKit 0.106 работала уже с новыми файлами правил. Предполагалось, что именно эта версия будет включена в дистрибутив Fedora начиная с номера 18.

Посмотреть версию установленного в системе PolicyKit можно, например,так:

На самом деле указанная в выводе версия относится к утилите pkcheck, которая входит в комплект PolicyKit. Но она же соответствует всему комплекту в целом.

Да, с некоторых пор файлы правил для PolicyKit выглядят не как традиционные файлы конфигурации, а как небольшие программы. Это несколько затрудняет написание собственных правил для тех, кто далек от программирования. Но задача облегчается тем, что во многих случаях можно использовать простой шаблон и не особенно задумываться о том как он работает. Шаблон может выглядеть, например, следующим образом:

Конечно, это не единственный возможный шаблон. Но, похоже, один из самых простых. Немного разобравшись в конструкциях языка программирования JavaScript можно при желании составлять более сложные правила. Например, поставить выполнение действия в зависимость от таких условий как время суток или серийный номер устройства.

Шаблон очень просто использовать. Если вместо элементов, выделенных цветом, подставить нужные значения, то приведенный шаблон может быть оформлен в виде отдельного файла .rules в каталоге /etc/polkit-1/rules.d. Ниже, в секции "Практика" рассматриваются примеры того как это можно сделать.

Для тех, кому требуется быстрый результат, а не погружение в программирование на языке JavaScript, можно дать совсем краткие пояснения того, что делает приведенный в шаблоне программный код. В данном случае используется метод addRule (), который описывает некоторую функцию. Эта функция обеспечивает проверку возможности выполнения действия и выбирает для этого нужный тип авторизации в соответствии с правилом . Это правило действительно только для определенной группы пользователей .

Действие - это значение id в элементе action в нужном файле действий .policy. Например, в приведенном выше файле это - org.x.xf86-video-intel.backlight-helper. При выборе нужного действия полезно внимательно прочитать его описание, приведенное в элементе description.

Группа пользователей - это одна из реально существующих в операционной системе групп. Например, это может быть та группа, которая была создана при заведении пользователя в системе.

Формулировка правил в целом совпадает с той, что используется в XML-файлах действий, которые были рассмотрены выше. Это - NO, YES, AUTH_SELF, AUTH_SELF_KEEP, AUTH_ADMIN, AUTH_ADMIN_KEEP. Они имеют тот же смысл, но в данном случае записываются в верхнем регистре.

20 июл 2018, 16:13

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

последняя на сегодня версия 2.02 была выпущена еще в 2009 году , после чего патчилась уже мейнтенерами дистрибутивов
На сегодня известна как минимум одна немолодая уязвимость данного пакета, компрометирующая безопасность системы
В отличии от sudo - подменялся идентификатор пользователя, и корректировал права и владельца по умолчанию.
На странице проекта gksu кррасуется мощная надпись "gksu is being replaced by PolicyKit"
Выпилен сначала из debian testing, следом не вошел в очередной LTS Ubuntu 18.04 и LM 19, Arch Linux выкинул пакет из основного репозитория в AUR

Для этого достаточно только описать его разрешения в отдельном xml-конфиге. для xed - cоздадим файлик /usr/share/polkit-1/actions/org.gnome.xed.policy

Вот и все, в общем-то Для запуска редактора с нужными правами достаточно выполнить pkexec xed (этот вызов можно использовать в кнопках запуска и пунктах меню)
окошко с полиси org.gnome.xed запросит пароль и отдаст приложение

Если же мы хотим разрешить пользователю запускать данный экземпляр софта вовсе без запроса пароля - то проставим поле <allow_active>yes</allow_active> , и программа будет запущена привилегированной сразу и без лишних вопросов. Аккуратней с такими разрешениями, желательно не перестараться в угоду своей лени

В завершении можно отметить, что большинство приложений как и xed норм отработает от sudo appname , а те которые действительно требовали для запуска этих манипуляций - уже обычно несут в пакете файлы полиси, например Gparted (ранее работавший от gksu):

но в мышетыкательных сценариях run as root может вполне пригодиться

UPD. Для любителей старых привычек - можно сделать симлинк с pkexec на gksu , чтоб было почти "как раньше"
sudo ln /usr/bin/pkexec /usr/bin/gksu

Polkit используется для управления привилегиями в дистрибутивах Linux. При помощи Polkit можно разрешить пользователю / процессу запускать приложения, которые для запуска требуют привилегированных полномочий. В разрезе некоторых административных задач, это очень полезная функция системы, которая позволяет достаточно гибко разрешать те или иные действия "простым" учетным записям.

Разрешить монтирование дисков в Linux, через Polkit

Например раньше, когда приходилось разрешать монтировать диск, добавлялась специальная запись в sudoers файл, что то типа такого:

Наверняка многие с этим сталкивались, на сегодня для этих целей можно использовать Polkit, для этого можно создать группу, назовем ее diskusers :

После в нее необходимо добавить пользователя(ей):

Далее создать разрешающее правило:

Для вступления настроек в силу, если пользователь добавленный в группу залогинен в систему, нужно совершить logoff / logon процедуру, после чего все должно заработать.

Разрешить работать простым пользователям с Virtual Manager

Многие сталкивались с тем, что при запуске KVM Virt Manager постоянно просит рутовый пароль, по аналогии можно создать группу, например virtusers , создать Polkit правило:

Кейс о том, как разрешить запуск Pritunl сервиса юзеру без привилегий

Сервис запускается после ввода OTP кода, для пользователя это окно выглядит так:

Из скрина видно, что процесс polkit, пытается выполнить действие com.pritunl.client.profile_start , при детальном рассмотрении правила /usr/share/polkit-1/actions/com.pritunl.client.policy можно увидеть, что запуск разрешается только в случае использования auth_admin_keep , что означает проверку подлинности пользователя с правами администратора:

.
<action >
<description>Start pritunl connection</description>
.
<allow_any>auth_admin_keep</allow_any>
<allow_inactive>auth_admin_keep</allow_inactive>
<allow_active>auth_admin_keep</allow_active>
.
</action>
.

Самым простым методом было-бы изменить auth_admin_keep на yes и все заработало без каких-либо проблем, но в таком случае этот процесс можно будет запускать всем, кому угодно, поэтому был выбран более правильный на мой взгляд путь:

Читайте также: