PolicyKit — создание собственных правил
PolicyKit присутствует практически в любом современном дистрибутиве Linux. Он является хорошо отлаженной частью операционной системы и в то же время постоянно развивается вместе с ней. Как правило, работа PolicyKit почти незаметна для пользователя и редко требует вмешательства. Вопросы могут возникать лишь в тех случаях, когда на экране монитора появляются окна, подобные показанному ниже, и это кажется не совсем обоснованным.
Назойливое требование ввода пароля для выполнения обыденного, хорошо понятного или часто повторяющегося действия может стать поводом для коррекции работы PolicyKit.
Немного о том, что это и как работает
PolicyKit (часто используется также сокращение PolKit) — это набор программных средств с открытым исходным кодом для гибкого управления предоставлением системных привилегий в Unix-подобных операционных системах, например, в Linux. Он позволяет непривилегированным процессам запускать привилегированные, системные. Разработчик PolicyKit — David Zeuthen. Сайт проекта http://www.freedesktop.org/wiki/Software/polkit . Лицензия — LGPL.
PolicyKit дополняет базовую модель разграничения прав доступа DAC (Discretionary Access Control), принятую в UNIX-подобных операционных системах. С небольшими упрощениями основную идею модели DAC можно изложить буквально в нескольких словах. Например, так: любой объект операционной системы является файлом и для каждого файла определены права на чтение, запись и выполнение отдельно для владельца, для членов группы и для всех остальных.
Модель DAC проста и эффективна. Но надо понимать, что она разрабатывалась во времена майнфрэймов, когда пользователь и администратор системы на самом деле были разными людьми и имели полномочия разного уровня. Очевидно, что для операционной системы, установленной на персональном компьютере требуется более гибкая модель. Для пользователя персонального компьютера такие действия как установка системного времени или даты, подключение носителей, настройка сетевого соединения, монитора или клавиатуры являются обыденными. Но по своей сути — это системные операции и они требуют прав суперпользователя. Как правило, на персональном компьютере их выполняет пользователь, который скорее всего не имеет в этот момент нужных привилегий. Но, несмотря на это, если ему все же требуется выполнить подобную операцию, то это во многих случаях не должно быть связано с необходимостью ввода административного пароля. Ввод пароля в таких ситуациях наверняка будет восприниматься как помеха, даже как признак враждебного поведения системы.
PolicyKit служит одним из способов временной и частичной передачи административных полномочий обычному, непривилегированному пользователю. Для похожих целей существуют и другие программные средства, например, sudo. Но, в отличие от sudo, PolicyKit не предоставляет администраторских полномочий на весь процесс, а следует принципу минимальных разрешений. Другими словами, он дает права суперпользователя только для выполнения конкретного действия.
Работает это следующим образом. Любой запрос на выполнение действия в системном контексте, поступивший от работающего пользовательского процесса, отслеживается с помощью PolicyKit. В соответствии с имеющимися правилами PolicyKit принимает решение о том, может ли быть выполнено это действие, и, если может, то — при выполнении каких условий. Это решение — запрет, разрешение или разрешение с условием — передается системной программе, которая затем действует соответствующим образом. Другими словами, хотя непривилегированный пользовательский процесс (Subject) и привилегированный системный процесс (Mechanism) общаются между собой напрямую, решение принимает третья сторона — PolicyKit.
Примечание. Здесь и далее по тексту в скобках приведены англоязычные термины, которые используются в документации PolicyKit и с которыми можно столкнуться при чтении статей на эту тему.
Условием выполнения действия может быть, например, ввод оператором пароля. Для взаимодействия с оператором используется агент (Authentication agent), который при необходимости показывает оператору окно с соответствующим требованием. Агент предоставляется пользовательским окружением, например, агент PolicyKit для GNOME. Практически все современные пользовательские окружения, такие как GNOME, KDE, MATE, Xfce и другие, имеют в своем составе соответствующих агентов для взаимодействии с PolicyKit.
Все участники рассмотренного выше процесса — Mechanism, Subject, PolicyKit и Authentication agent — сообщаются между собой через системную шину сообщений D-Bus. В этом процессе может также участвовать systemd, система инициализации, которая постепенно все больше проникает во все основные составляющие операционной системы.
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. Имя каждого файла вполне соответствует той группе действий, которые в нем перечислены. Средняя часть имени файла — название программы или группы действий — является в данном случае смысловой. Именно на нее надо обращать внимание, если требуется определить, в каком файле описано требуемое действие.
Видно, что кроме собственно описания действия такие файлы содержат описание правил авторизации для выполнения этих действий. Причем эти правила являются правилами по умолчанию. Именно эти правила составляются разработчиками дистрибутива. Данные правила можно изменять редактированием XML-файлов .policy, но этот метод не является правильным из-за того, что при обновлении программ сделанные изменения пропадут.
Файлы и правила
Настраивать правила можно как правкой существующих файлов .rules, так и созданием новых — в каталоге /etc/polkit-1/rules.d. Создание новых файлов .rules является более безопасным и надежным методом, т.к. он всегда позволяет быстро и без потерь вернуться к исходному варианту.
В Интернете можно найти материалы, описывающие настройку правил PolicyKit с помощью pkla-файлов. Это больше не актуально. В новых версиях PolicyKit файлы правил .rules написаны на языке программирования JavaScript.
В июне 2012 года David Zeuthen сообщил в своем блоге, что собирается переписать ту часть PolicyKit, которая работает с файлами правил. После проведения предварительных тестов он остановился на варианте с использованием языка программирования JavaScript. Такой выбор David обосновал тем, что ему хорошо знаком SpiderMonkey, интерпретатор JavaScript, а также тем, что он постоянно общается с людьми, которые имеют опыт его внедрения в GNOME Shell.
David привел достаточно веские аргументы в пользу намечавшегося кардинального изменения PolicyKit — повышение гибкости и увеличение скорости работы. Несмотря на это, по тем ответам, которые он получил, видно, что разразилась настоящая буря. Потому что минусов тоже хватало. Совершенно ясно, что среди обычных пользователей, да и среди системных администраторов Linux не так уж много тех, кто умеет программировать на JavaScript. Сам язык имел не очень хорошую репутацию в плане безопасности. К тому же считалось, что его место — Web. Кроме того, были опасения, что новый PolicyKit будет требовать установки большого количества дополнительного программного обеспечения из-за зависимостей, связанных с использованием JavaScript. При этом, как предполагали оппоненты, возможно значительное снижение скорости его работы. Накал обсуждения был велик.
Однако, решение было принято. Новая версия PolicyKit 0.106 работала уже с новыми файлами правил. Предполагалось, что именно эта версия будет включена в дистрибутив Fedora начиная с номера 18.
На самом деле указанная в выводе версия относится к утилите pkcheck, которая входит в комплект PolicyKit. Но она же соответствует всему комплекту в целом.
Да, с некоторых пор файлы правил для PolicyKit выглядят не как традиционные файлы конфигурации, а как небольшие программы. Это несколько затрудняет написание собственных правил для тех, кто далек от программирования. Но задача облегчается тем, что во многих случаях можно использовать простой шаблон и не особенно задумываться о том как он работает. Шаблон может выглядеть, например, следующим образом:
Конечно, это не единственный возможный шаблон. Но, похоже, один из самых простых. Немного разобравшись в конструкциях языка программирования JavaScript можно при желании составлять более сложные правила. Например, поставить выполнение действия в зависимость от таких условий как время суток или серийный номер устройства.
Шаблон очень просто использовать. Если вместо элементов, выделенных цветом, подставить нужные значения, то приведенный шаблон может быть оформлен в виде отдельного файла .rules в каталоге /etc/polkit-1/rules.d. Ниже, в секции «Практика» рассматриваются примеры того как это можно сделать.
Для тех, кому требуется быстрый результат, а не погружение в программирование на языке JavaScript, можно дать совсем краткие пояснения того, что делает приведенный в шаблоне программный код. В данном случае используется метод addRule (), который описывает некоторую функцию. Эта функция обеспечивает проверку возможности выполнения действия и выбирает для этого нужный тип авторизации в соответствии с правилом . Это правило действительно только для определенной группы пользователей .
Осталось разобраться с тем, как правильно записать действие , группу пользователей и правило в файле .rules.
Действие — это значение id в элементе action в нужном файле действий .policy. Например, в приведенном выше файле это — org.x.xf86-video-intel.backlight-helper. При выборе нужного действия полезно внимательно прочитать его описание, приведенное в элементе description.
Группа пользователей — это одна из реально существующих в операционной системе групп. Например, это может быть та группа, которая была создана при заведении пользователя в системе.
Формулировка правил в целом совпадает с той, что используется в XML-файлах действий, которые были рассмотрены выше. Это — NO, YES, AUTH_SELF, AUTH_SELF_KEEP, AUTH_ADMIN, AUTH_ADMIN_KEEP. Они имеют тот же смысл, но в данном случае записываются в верхнем регистре.
Видно, что с помощью задания имени файла можно просто и надежно определить порядок чтения файлов .rules. На практике часто в начале имени файла записывают число. При этом файлы гарантированно будут читаться в том же порядке, в котором возрастают эти числа. Впрочем, маловероятно, что пользователю придется создавать много своих файлов с правилами. Разработчики хорошо делают свою работу и варианты по умолчанию обычно выбираются ими правильно.
Порядок чтения файлов .rules важен. Правила, которые содержатся в файлах, прочитанных раньше, переопределяют правила в файлах, прочитанных позже. Ниже этому дается объяснение.
Функции JavaScript, описывающие правила, последовательно добавляются в PolicyKit при чтении файлов .rules. Чтение происходит в том порядке, который рассматривался выше. В свою очередь, проверка правил, описанных в этих функциях, производится в том же порядке, в котором они были добавлены. Проверка производится до тех пор, пока одна из функций не возвращает значение. Другими словами, до тех пор, пока сочетание параметров действие и группа пользователей не приведет к появлению правила . В этот момент PolicyKit формирует решение о возможности выполнения действия. Если таких сочетаний в файлах правил имеется несколько, то выполняться будет первое появившееся при переборе. Это значит, что для того, чтобы добавить свое правило, его надо поместить в файл, который будет прочитан и обработан раньше других.
Источник
Как запретить PolicyKit долбить меня бесконечными запросами пароля? [РЕШЕНО]
На сервере установил Debian 10, из под рута поставил графическую оболочку KDE, настроил удаленный рабочий стол по xrdp.
Создал нового обычного пользователя, добавил его в группу sudo.
Зашел под новосозданным пользователем и оказался буквально парализован бесконечными запросами пароля. Очень прошу помощи, что я не учел? Почему, если при установке Debian он создает обычного пользователя сам, то все нормально, а если его создать потом вручную он вот так вот криво создается? Я не могу ни одного пакета поставить из-за этих бесконечных запросов пароля.
оденьте трусы на задницу, а панаму на голову.
помимо создания юзера, его нужно добавить не только(и не столько) в группу sudo(что за блажь?), а ещё и в другие группы, коих почти с десяток, video, audio, adm, pulse, kvm, disk, power, wheel. да и сам sudo не мешало бы для начала настроить.(на снимке он у тебя спрашивает разрешение на подключение к репам, если тебя так заботит проверять обновления может десяточку?)
Какие конкретно, смотри по своему набору. Какие группы указаны в правилах polkitd? их там может быть тьма, а может ни одной, что не мешает самому правила написать.
Какие пароли он от тебя требует? на какие действия? при каких условиях? Конечно, если повключать в автостарт квалеты, управление ключами, и прочую лабуду, то можно по десять минут логиниться с увлечением долбя пароли на всякий чих. Ты сперва для себя определись, что тебе нужно для работы, а потом уже паранойю разводи.
Да откуда бы мне знать что за группы нужны для комфортной работы? Я весь интернет перерыл, нигде не нашел списка групп, в которые надо добавлять новосозданного пользователя.
Тут наверное проблема в том, что на сервере Debian изначально ставится только с одним пользователем (рутом). Вероятно надо попробовать как-нибудь со своего iso-образа установится, чтобы два пользователя создалось сразу (обычный и рут).
помимо создания юзера, его нужно добавить не только(и не столько) в группу sudo(что за блажь?), а ещё и в другие группы, коих почти с десяток, video, audio, adm, pulse, kvm, disk, power, wheel
А вот нафига так? Тож вопрос интересен. Почему не создается сразу со всеми нужными как при установке?
Я не знаю. Но в панели хостера я могу лишь выбрать шаблон ОС и все эти шаблоны только с одним рутовским юзером, в них не предусмотрен обычный юзер.
Используешь гуй. оно на все запросы, которые требуют Рут прав, кидает тебе запрос на ввод пароля. А ты как хотел? Используй терминал, пароль будешь 1 раз вводить на время сессии sudo.
Или можешь настроить полкит, чтоб пароль не спрашивало.
А вот нафига так? Тож вопрос интересен. Почему не создается сразу со всеми нужными как при установке?
проблема в том, что на сервере Debian
каждая системная служба имеет свои резоны по доступу к железу и другим службам и за каждой тянется борода старины Черномора из исторических прецедентов и всяких секьюрных примочек.
Само понятие «сервер» уже накладывает кучу ограничений на гуи и прочую необязательную мешпуху.
А работать в линуксе под рутом — это не просто моветон, а прямое указание на органические повреждения мозга. (может всё-таки десяточка?добрая, котоламповая, с анальными зондами с усиками и пупырышками от Билли, тем более он вон решил всех осчасливить неизвлекаемым носимым, который битки майнить будет пока на женщине выполняешь обязательную программу)
обязательного списка групп, в которые должен быть добавлен юзер не существует в природе, в каждом дистрибутиве свои примочки. Есть лишь общие правила(которые просто приняты по умолчанию), если у тебя нет avahi или samba, то тебе и не нужны эти группы, если тебе не нужен qemu, то тебе и все виртуальности тоже никуда не впёрлись. Кому-то и аудио не нужно, так что только читать основы, общих рекомендаций нет.
А есть гайды по настройке полкит на русском?
Я вчера весь день убил на всю эту хрень, но так и не смог победить. Итак, алгоритм моих действий был таким:
- Ставлю чистый Debian на сервер.
- Создаю нового обычного пользователя и добавляю его точно в те же группы, в которых состоит мой пользователь на домашнем ПК (там тоже Debian).
- Далее, копирую с домашнего компа конфиги PolitKit из каталогов /etc/polikit-1 и /usr/share/polkit-1 (так как пользователь на сервере и на домашнем ПК имеют одинаковые имена, то проблем быть не должно).
- После чего иду и настраиваю файл /etc/sudoers по аналогии с тем, что записано в этом же файле на моем домашнем ПК.
- Перезагружаюсь и запускаю установку kde-full + xrdp
- Как только графическая оболочка готова, захожу через удаленный доступ под обычным пользователем и пытаюсь использовать какой-нибудь пакетный менеджер для установки пакетов.
- Но эта падла все равно просит у меня пароли! И ПРИ ЭТОМ ВВЕДЕННЫЕ ПАРОЛИ НЕ ПРИНИМАЕТ! Пишет что не хватает прав для действий. При этом с консоли sudo нормально работает, а вот пакетные менеджеры в графическом режиме все как один отказваються работать, требуя неизвестных мне прав.
Я не понимаю, что за фигня происходит, ведь PolitKit настроен точно так же, как на домашнем компе. Что не так то? Разумеется я пробовал и переустанавливать PolitKit, но это ни капельки не помогло.
Я не понимаю, что за фигня происходит, ведь PolitKit настроен точно так же, как на домашнем компе. Что не так то? Разумеется я пробовал и переустанавливать PolitKit, но это ни капельки не помогло.
)))))(фэйспамл-об-стол, стол уже весть в трещинах)
во-первых, полкит это своеобразная штука, она работает с особыми правами, любые её действия имеют доминантный характер по отношению к любым другим системным вещам, но выполняются они только с правами самого polkitd. Все правила(файлы) должны иметь владельцем polkitd.
так ты должен сделать. Хотя и пишут что достаточно только хозяина поменять, но я по старинке делаю и группу тоже, вреда не будет.
во-вторых, с sudo там тоже не всё просто, файл настройки он не один(внезапно, да?), их четыре:
/etc/sudo.conf /etc/sudoers /etc/sudoers.dist /etc/sudoers.d/sudo
плюс к этому, существует ещё и PAM со своими правилами! которые во многом порой переопределяют поведение защиты от дурака.
каталог /etc/pam.d , где все текущие правила, и! каталог /etc/security , где прописаны права и разрешения на применение правил PAM. В частности такой файлик как /etc/security/access.conf , отвечает за доступ к ресурсам файловой системы в разных ситуациях(в том числе и удалёнка). Там есть комментарии, можно почитать, ну и man’ы никто не отменял.
Всё работает в комплексе, одни прикладухи требуют полисикит, другие пам, третьи акцесы рама, четвертые всех вместе.
Я не могу подсказать как тебе настроить пакетный манагер, скорее всего, там ещё и свои замороки с настройками доступа, но рекомендую начать с прав доступа к правилам полкита, очень часто это главная засада, дальше уже по мере поступления проблем.
Огромное спасибо за развернутый ответ, но мне уже настолько надоело все это, что мне проще и быстрее будет в будущем взять сервер на котором можно будет разворачивать свои образы-инсталяторы, а не только из шаблона. Сейчас уже времени нет, со всем этим возится, работать надо, сроки жмут, поэтому откладывается все на неопределенное время. Еще раз спасибо.
polkitd рулит разрешениями для определенных действий в зависимости от того как пользователь зашел в систему — локально или удаленно. Для удаленных пользователей политика строже. Даже не перезагрузку системы будет пароль спрашивать.
Для изменения поведения нужно переопределить конкретные правила. Это делается не сложно, но сам алгоритм как придти к тем или другим действиям довольно туманен.
как обойти запросы пароля на создание цветового профиля устройства и на обновление репозиториев можно почитать тут: http://c-nergy.be/blog/?p=14051 http://c-nergy.be/blog/?p=14058
в моем случае не удалось достичь желаемого результата по репозитариям. Правда раньше было 2 запроса, а теперь один. Возможно это немного другое действие…
А нельзя этот PolitKit вырезать нахрен? Удалить из системы, чтобы программы стартовали напрямую, без предварительной проверки прав.
бери божественную 10-ку. там все эти секурные суеверия отключаются раз и навсегда. главное не мешай ей обновляться. она не любит когда юзер начинает что-то ей диктовать.
Во FreeBSD есть PolicyKit, но нет такого трэшака, как тут описывалось.
Источник
