Polkit linux что это
PolicyKit присутствует практически в любом современном дистрибутиве Linux. Он является хорошо отлаженной частью операционной системы и в то же время постоянно развивается вместе с ней. Как правило, работа PolicyKit почти незаметна для пользователя и редко требует вмешательства. Вопросы могут возникать лишь в тех случаях, когда на экране монитора появляются окна, подобные показанному ниже, и это кажется не совсем обоснованным.
Назойливое требование ввода пароля для выполнения обыденного, хорошо понятного или часто повторяющегося действия может стать поводом для коррекции работы PolicyKit.
Немного о том, что это и как работает
PolicyKit дополняет базовую модель разграничения прав доступа DAC (Discretionary Access Control), принятую в UNIX-подобных операционных системах. С небольшими упрощениями основную идею модели DAC можно изложить буквально в нескольких словах. Например, так: любой объект операционной системы является файлом и для каждого файла определены права на чтение, запись и выполнение отдельно для владельца, для членов группы и для всех остальных.
PolicyKit служит одним из способов временной и частичной передачи административных полномочий обычному, непривилегированному пользователю. Для похожих целей существуют и другие программные средства, например, sudo. Но, в отличие от sudo, PolicyKit не предоставляет администраторских полномочий на весь процесс, а следует принципу минимальных разрешений. Другими словами, он дает права суперпользователя только для выполнения конкретного действия.
Примечание. Здесь и далее по тексту в скобках приведены англоязычные термины, которые используются в документации PolicyKit и с которыми можно столкнуться при чтении статей на эту тему.
Условием выполнения действия может быть, например, ввод оператором пароля. Для взаимодействия с оператором используется агент (Authentication agent), который при необходимости показывает оператору окно с соответствующим требованием. Агент предоставляется пользовательским окружением, например, агент PolicyKit для GNOME. Практически все современные пользовательские окружения, такие как GNOME, KDE, MATE, Xfce и другие, имеют в своем составе соответствующих агентов для взаимодействии с PolicyKit.
PolicyKit включает в себя соответствующий программный интерфейс (API), предназначенный для того, чтобы приложения могли использовать его возможности. Именно в приложениях определяются те действия (Action), которые будет отслеживать PolicyKit. На практике могут встретится программы, которые не умеют взаимодействовать с PolicyKit. Но это скорее исключение.
Для действий, которые определены в приложении, существуют соответствующие правила их выполнения (Authorization Rules). Набор таких правил для конкретного приложения называется политикой (Authorization policy).
Все изложенное ниже относится у дистрибутиву Fedora 21, но может с успехом использоваться для понимания принципов настройки PolicyKit в любых системах Linux. В данном случае использовалось пользовательское окружение MATE, но это также не принципиально.
Разработчики дистрибутивов настраивают работу PolicyKit исходя из своих представлений о безопасности. Понятно, что сервер и рабочая станция будут иметь разные настройки. При адекватном выборе дистрибутива пользователь обычно не сталкивается с какими-либо неожиданными проблемами. Но иногда все же имеет смысл внести в работу PolicyKit некоторые изменения. Это один из тех немногих случаев, когда простыми средствами можно сделать собственный компьютер чуть более отзывчивым и дружелюбным.
Явные и неявные разрешения
Явные разрешения (Explicit privileges) относятся к конкретным пользователям или группам пользователей. При этом явные разрешения могут содержать ограничения. Например, ограничением может быть требование использовать только локальную консоль.
Явные разрешения можно предоставлять или запрещать. Это похоже на всем известные списки доступа (ACL). Запрет имеет приоритет. Другими словами, если пользователю в одних политиках разрешено какое-либо действие, а в других оно запрещено, то выполнить это действие он не сможет.
Для принятия решения PolicyKit располагает информацией двух видов: описанием возможных действий и описанием правил для их выполнения.
Файлы действий
Список всех возможных действий содержится в файлах, которые находятся в каталоге /usr/share/polkit-1/actions. Эти файлы записаны в формате XML, что позволяет просматривать их в текстовом редакторе или даже в браузере.
Файлы и правила
В июне 2012 года David Zeuthen сообщил в своем блоге, что собирается переписать ту часть PolicyKit, которая работает с файлами правил. После проведения предварительных тестов он остановился на варианте с использованием языка программирования JavaScript. Такой выбор David обосновал тем, что ему хорошо знаком SpiderMonkey, интерпретатор JavaScript, а также тем, что он постоянно общается с людьми, которые имеют опыт его внедрения в GNOME Shell.
Однако, решение было принято. Новая версия PolicyKit 0.106 работала уже с новыми файлами правил. Предполагалось, что именно эта версия будет включена в дистрибутив Fedora начиная с номера 18.
На самом деле указанная в выводе версия относится к утилите pkcheck, которая входит в комплект PolicyKit. Но она же соответствует всему комплекту в целом.
Да, с некоторых пор файлы правил для PolicyKit выглядят не как традиционные файлы конфигурации, а как небольшие программы. Это несколько затрудняет написание собственных правил для тех, кто далек от программирования. Но задача облегчается тем, что во многих случаях можно использовать простой шаблон и не особенно задумываться о том как он работает. Шаблон может выглядеть, например, следующим образом:
Конечно, это не единственный возможный шаблон. Но, похоже, один из самых простых. Немного разобравшись в конструкциях языка программирования JavaScript можно при желании составлять более сложные правила. Например, поставить выполнение действия в зависимость от таких условий как время суток или серийный номер устройства.
polkit
polkit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications.
Polkit is used for controlling system-wide privileges. It provides an organized way for non-privileged processes to communicate with privileged ones. In contrast to systems such as sudo, it does not grant root permission to an entire process, but rather allows a finer level of control of centralized system policy.
Polkit works by delimiting distinct actions, e.g. running GParted, and delimiting users by group or by name, e.g. members of the wheel group. It then defines how – if at all – those users are allowed those actions, e.g. by identifying as members of the group by typing in their passwords.
Contents
Installation
Authentication agents
An authentication agent is used to make the user of a session prove that they really are the user (by authenticating as the user) or an administrative user (by authenticating as an administrator). The polkit package contains a textual authentication agent called ‘pkttyagent’, which is used as a general fallback.
If you are using a graphical environment, make sure that a graphical authentication agent is installed and autostarted on login.
Cinnamon, Deepin, GNOME, GNOME Flashback, KDE, LXDE, LXQt, MATE, theShell and Xfce have an authentication agent already. In other desktop environments, you have to choose one of the following implementations:
Configuration
Polkit definitions can be divided into two kinds:
Actions
The actions available to you via polkit will depend on the packages you have installed. Some are used in multiple desktop environments (org.freedesktop.*), some are DE-specific (org.gnome.*) and some are specific to a single program (org.gnome.gparted.policy). The command pkaction lists all the actions defined in /usr/share/polkit-1/actions for quick reference.
To get an idea of what polkit can do, here are a few commonly used groups of actions:
The attribute id is the actual command sent to D-Bus, the message tag is the explanation to the user when authentication is required and the icon_name is sort of obvious.
The defaults tag is where the permissions or lack thereof are located. It contains three settings: allow_any, allow_inactive, and allow_active. Inactive sessions are generally remote sessions (SSH, VNC, etc.) whereas active sessions are logged directly into the machine on a TTY or an X display. allow_any is the setting encompassing both scenarios.
For each of these settings the following options are available:
These are default setting and unless overruled in later configuration will be valid for all users.
As can be seen from the GParted action, users are required to authenticate as administrators in order to use GParted, regardless of whether the session is active or inactive.
Authorization rules
Authorization rules that overrule the default settings are laid out in a set of directories as described above. For all purposes relating to personal configuration of a single system, only /etc/polkit-1/rules.d should be used.
Inside the function, we check for the specified action ID (org.gnome.gparted) and for the user’s group (admin), then return a value «yes».
Administrator identities
The addAdminRule() method is used for adding a function that may be called whenever administrator authentication is required. The function is used to specify what identities may be used for administrator authentication for the authorization check identified by action and subject. Functions added are called in the order they have been added until one of the functions returns a value.
The default configuration for administrator identities is contained in the file 50-default.rules so any changes to that configuration should be made by copying the file to, say, 40-default.rules and editing that file.
The only part to edit (once copied) is the return array of the function: as whom should a user authenticate when asked to authenticate as an administrative user? If she herself is a member of the group designated as admins, she only need enter her own password. If some other user, e.g. root, is the only admin identity, she would need to enter in root’s password. The format of the user identification is the same as the one used in designating authorities.
The Arch default is to make all members of the group wheel administrators. A rule like below will have polkit ask for the root password instead of the users password for Admin authentication.
Examples
Debugging/logging
The following rule logs detailed information about any requested access.
Disable suspend and hibernate
The following rule disables suspend and hibernate for all users.
Bypass password prompt
Globally
Create the following file as root:
Replace wheel by any group of your preference.
This will result in automatic authentication for any action requiring admin rights via Polkit. As such, be careful with the group you choose to give such rights to.
There is also AUTH_ADMIN_KEEP which allows to keep the authorization for 5 minutes. However, the authorization is per process, hence if a new process asks for an authorization within 5 minutes the new process will ask for the password again anyway.
For specific actions
Create the following file as root:
The || operator is used to delimit actions (logical OR), and && means logical AND and must be kept as the last operator.
Udisks
File managers may ask for a password when trying to mount a storage device, or yield a Not authorized or similar error. See Udisks#Configuration for details.
Allow management of individual systemd units by regular users
By checking for certain values passed to the polkit policy check, you can give specific users or groups the ability to manage specific units. As an example, you might want regular users to start and stop wpa_supplicant:
Polkit linux что это
Polkit используется для управления привилегиями в дистрибутивах Linux. При помощи Polkit можно разрешить пользователю / процессу запускать приложения, которые для запуска требуют привилегированных полномочий. В разрезе некоторых административных задач, это очень полезная функция системы, которая позволяет достаточно гибко разрешать те или иные действия «простым» учетным записям.
Разрешить монтирование дисков в Linux, через Polkit
Например раньше, когда приходилось разрешать монтировать диск, добавлялась специальная запись в sudoers файл, что то типа такого:
Наверняка многие с этим сталкивались, на сегодня для этих целей можно использовать Polkit, для этого можно создать группу, назовем ее diskusers :
После в нее необходимо добавить пользователя(ей):
Далее создать разрешающее правило:
Для вступления настроек в силу, если пользователь добавленный в группу залогинен в систему, нужно совершить logoff / logon процедуру, после чего все должно заработать.
Разрешить работать простым пользователям с Virtual Manager
Кейс о том, как разрешить запуск Pritunl сервиса юзеру без привилегий
Сервис запускается после ввода OTP кода, для пользователя это окно выглядит так:
Самым простым методом было-бы изменить auth_admin_keep на yes и все заработало без каких-либо проблем, но в таком случае этот процесс можно будет запускать всем, кому угодно, поэтому был выбран более правильный на мой взгляд путь:
Polkit
Содержание
Polkit [ править ]
Polkit (прежнее название: PolicyKit) — библиотека для UNIX-подобных операционных систем. API библиотеки используется для предоставления непривилегированным процессам возможности выполнения действий, требующих прав администратора. Использование Polkit противопоставляется использованию таких систем, как sudo, но не наделяет процесс пользователя правами администратора, а позволяет точно контролировать, что разрешено, а что запрещено.
Политики polkit [ править ]
Все политики находятся в /usr/share/polkit-1/actions/ в формате *.policy Каждая политика представляет собой xml-файл, в котором описываются запросы к polkit. Каждый запрос имеет три условия, прописанных в секции defaults:
1. Запрос от любого пользователя. Тег
2. Запрос от неактивного пользователя. Тег
3. Запрос от активного пользователя
Внутри каждого тега прописывается возвращаемое значение. Используются следующие варианты значений:
По-умолчанию, запрашивается пароль пользователя, находящегося в группе wheel. Для того, чтобы запрашивался пароль root необходимо добавить правило с цифрами вначале имени больше 50 с таким содержанием:
Правила polkit [ править ]
Менять напрямую политики нельзя, так как при обновлении системы они затрутся. Необходимо создавать собственные правила в /etc/polkit-1/rules.d/ в формате *.rules. Правила выполняются в порядке названия по алфавиту, поэтому вначале пишутся цифры, чтобы указать приоритет правила. Алгоритм создания правила (все действия выполняются от root):
Журналирование действий polkit [ править ]
Используя правила polkit можно также делать записи в системный журнал. Метод log() записывает сообщение в системный журнал. Пример:
В параметре action передается объект с информацией о совершенном процессе и связанные с этим действием параметры (например, если запрошенное действие монтирование съемного диска, то в параметре action будут переданы серийный номер диска, его id, файловая система и т.д).
В параметре subject передается объект с информацией о пользователе, запустившем процесс. Этот объект имеет следующие атрибуты:
Примеры [ править ]
Пользователи часто жалуются на необходимость вводить пароль при монтировании разделов в файловом менеджере и создании нового подключения в NetworkManager, а также невозможность извлечь usb-флэш или лоток оптического привода. За эти разрешения отвечают:
Чтобы узнать является ли устройство системным, на которые распространяется действие org.freedesktop.udisks2.filesystem-mount-system, выполните сначала команду, которая выведет все подключенные накопители:
Затем команду с именем вашего устройства. Например /dev/sdb. Статус true для HintSystem, в выводе команды говорит, что это системное устройство:
Монтирование раздела и создание нового подключения без запроса пароля [ править ]
Сделаем так, чтобы если пользователь находится в системной группе xgrp, то для него запросы пароля не должны будут выполняться для этих действий. Для этого (все действия выполняются от root):
Монтирование раздела и создание нового подключения с запросом пароля [ править ]
Пример создания правила, разрешающего пользователю выполнять монтирование и извлечение устройств — с запросом пароля (при указании polkit.Result.AUTH_SELF — будет запрошен пароль текущего пользователя, polkit.Result.AUTH_ADMIN — администратора). При подключении съемного устройства записывать в системный журнал какое устройство было подключено и каким пользователем:
При монтировании USB-диска в системном журнале появятся записи:
Таким образом, в системном журнале зарегистрировано, что usb-диск с серийным номером 11101094E6BA1A00A4A5200A был подключен пользователем test.
Просмотреть факты подключения конкретного носителя, можно выполнив команду:
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Polkit
Polkit — это средство для управления правами приложений пользовательского уровня, позволяющее непривилегированным процессам решать административные задачи: единый интерфейс предоставления прав доступа к привилегированным операциям для непривилегированных приложений при помощи набора правил (политик) и шины D-Bus. Polkit используется для управления общесистемными привилегиями. Данный фреймворк используется для предоставления непривилегированным процессам возможность выполнения действий, требующих прав администратора. В отличие от sudo, Polkit не наделяет процесс правами суперпользователя, а позволяет точно контролировать, какие действия разрешены, а какие нет.
Polkit может контролировать отдельные действия, такие как запуск GParted: при этом он проверяет имя пользователя и принадлежность оного к группе, например, является ли он членом группы wheel. Далее Polkit проверяет, какими правами наделены пользователи данной группы (есть ли вообще права на запуск?) и, если всё сходится (пользователь в нужной группе и у группы есть соответствующие права), требует ввести пароль для идентификации пользователя.
Polkit предоставляет API авторизации, предназначенный для использования привилегированными программами («МЕХАНИЗМЫ»), предлагающими услугу непривилегированным программам («СУБЪЕКТЫ») часто через какой-то механизм межпроцессного взаимодействия. В этом случае механизм обычно рассматривает объект как ненадежный. Для каждого запроса от субъекта механизм должен определить, разрешен ли запрос, или если он должен отказаться от обслуживания объекта. Используя API-интерфейсы polkit, механизм может разгрузить это решение доверенной стороне: полномочия polkit.
Полкит-сервер реализован как системный демон, polkitd, который сам по себе мало прав, поскольку он работает как пользователь системы polkitd. Механизмы, субъекты и агенты аутентификации обмениваются данными с полномочиями, используя шину системных сообщений.
Помимо действия в качестве органа, polkit позволяет пользователям получать временное разрешение посредством аутентификации либо административного пользователя, либо владельца сеанса, к которому принадлежит клиент. Это полезно для сценариев, когда механизм должен проверить, что оператор системы действительно является пользователем или действительно является административным пользователем.
Polkit может контролировать отдельные действия, такие как запуск GParted: при этом он проверяет имя пользователя и принадлежность оного к группе, например, является ли он членом группы wheel. Далее Polkit проверяет, какими правами наделены пользователи данной группы (есть ли вообще права на запуск?) и, если всё сходится (пользователь в нужной группе и у группы есть соответствующие права), требует ввести пароль для идентификации пользователя.
Содержание
Архитектура работы
Системная архитектура polkit состоит из Главы (реализована как служба на шине системных сообщений) и Агента аутентификации на каждый сеанс пользователя (предоставляется и запускается графической средой пользователя). Действия определяются приложениями. Поставщики, сайты и системные администраторы могут контролировать политику авторизации через Правила авторизации.
Для удобства библиотека libpolkit-gobject-1 обертывает API-интерфейс polkit D-Bus и может использоваться из любой программы на C/C++, а также языки более высокого уровня, поддерживающие GObjectIntrospection, такие как JavaScript и Python. Механизм также может использовать API D-Bus или команду pkcheck для проверки разрешений. Библиотека libpolkit-agent-1 обеспечивает абстрагирование собственной системы аутентификации, например. pam, а также регистрация объектов и связь с услугой D-Bus polkit.
Дополнительную информацию о написании приложений polkit см. В документации разработчика.
Агенты аутентификации
Агент аутентификации используется, чтобы заставить пользователя сеанса доказать, что пользователь сеанса действительно является пользователем (путем аутентификации в качестве пользователя) или администратором (путем аутентификации в качестве администратора). Чтобы хорошо интегрироваться с остальной частью пользовательского сеанса (например, соответствовать внешнему виду), агенты аутентификации должны предоставляться сеансом пользователя, который пользователь использует.
Приложения, которые не запускаются в среде рабочего стола (например, если они запущены из входа ssh), возможно, не связаны с ними агентом проверки подлинности. Такие приложения могут использовать тип PolkitAgentTextListener или помощник pkttyagent, чтобы пользователь мог аутентифицироваться с использованием текстового интерфейса.
Конфигурация
Определения Polkit можно разделить на два вида:
Применение
Polkit используется в следующих дистрибутивах ОС Linux:
Polkit позволяет непривилегированным пользователям выполнять некоторые действия, разрешённые администратором, (возможно, с запросом пароля пользователя или пароля администратора), например:
Правила политики polkit
Все политики находятся в /usr/share/polkit-1/actions/ в формате *.policy Каждая политика представляет собой xml-файл, в котором описываются запросы к polkit. Каждый запрос имеет три условия, прописанных в секции defaults:
Внутри каждого тега прописывается возвращаемое значение. Используются следующие варианты значений:
По-умолчанию, запрашивается пароль пользователя, находящегося в группе wheel. Для того, чтобы запрашивался пароль root необходимо добавить правило с цифрами вначале имени больше 50 с таким содержанием:
Механизм
Сценарий использования Polkit:
В описанной схеме возможны изменения. Например, «daemon» при запуске может самостоятельно создавать файл конфигурации для Polkit, а при завершении — удалять его.