Разве это нельзя использовать для взлома системы?

Что «это»?

В третий раз спрашиваю, Wayland каким боком к политикам PackageKit/polkit?

Именно к ним, никакого. Но к Qt имеет непосредственное отношение.

А дальше что?

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

Я же серьёзно, меня тревожит что я поставилю обновления, может даже мой племянник 6 лет это сделает. А чем с этими обновлениями Linux лучше, только тем что не надоедает каждые 15 минут?

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

Мне не понятно чем не устроил классический UNIX сокет, или сеть lo, для осуществления взаимодействия двух процессов.

«дать право на выключение компьютера пользователю, если он единственный залогиненный пользователь или его сессия сейчас активна» — приходи.

Потеринг перед тем как строчить код dbus и polkit забыл прочесть маны по команде shutdown и настройках /etc/inittab, /etc/shutdown.allow ?

man shutdown

«shutdown can check to see if an authorized user is logged in on one of the virtual consoles. If shutdown is called with the -a argument (add this to the invocation of shutdown in /etc/inittab), it checks to see if the file /etc/shutdown.allow is present. It then compares the login names in that file with the list of people that are logged in on a virtual console (from /var/run/utmp). Only if one of those authorized users or root is logged in, it will proceed.»

Мне не понятно чем не устроил классический UNIX сокет, или сеть lo, для осуществления взаимодействия двух процессов.

Абсолютным отсутствием гибкости, интроспекции или управляемости, ну всё в духе 80-х.

Покажи мне команду, которая для любого наперёд заданного сокета позволит мне в реальном времени получить человекочитаемое представление передаваемых данных или же состояния программы «по ту сторону»?

А покажи мне команду, которая для любой наперёд заданной пары общающихся между собой программ позволит мне написать сколь угодно сложные политики безопасности, которые смогут принимать решение в зависимости от содержания сообщения?

Потеринг перед тем как строчить код dbus и polkit забыл прочесть маны <…>

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

man shutdown

«shutdown can check to see if an authorized user is logged in on one of the virtual consoles. If shutdown is called with the -a argument (add this to the invocation of shutdown in /etc/inittab), it checks to see if the file /etc/shutdown.allow is present. It then compares the login names in that file with the list of people that are logged in on a virtual console (from /var/run/utmp). Only if one of those authorized users or root is logged in, it will proceed.»

«Простое и правильное решение совершенно другой проблемы»[2]. Процитированное тобой поведение не совпадает с запрошенным.

Я же серьёзно, меня тревожит что я поставилю обновления

С этим — к психотерапевту.

А чем с этими обновлениями Linux лучше, только тем что не надоедает каждые 15 минут?

Почитай чейнджлоги.

Абсолютным отсутствием гибкости или какой бы то ни было управляемости, ну всё в духе 80-х.

По UNIX сокету можно гнать все что хочешь (замена dbus). Если не хватает модели DAC для безопасности вешаешь на этот сокет дополнительно MAC (DAC или DAC+MAC замена polkitd). Гибкость реализуется на стороне общающихся прог.

Да соглашусь что все в духе 1970-2010, пока не пришел Потеринг с systemd, dbus, polkitd, … Я их не использую и не вижу в них необходимости.

Процитированное тобой поведение не совпадает с запрошенным.

«дать право на выключение компьютера пользователю, если он единственный залогиненный пользователь или его сессия сейчас активна»

Может имелось ввиду:

«дать право на выключение компьютера пользователю, если он единственный залогиненный пользователь И его сессия сейчас активна»

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

В код Shutdown можно добавить еще один if чтобы он перед выключение проверял отсутствие других залогиненых пользователей (условие единственного пользователя). Но это спорно, возможно vase действительно надо выключить комп, а vova своей сесией не даст.

В /etc/inittab добавляем комбинацию клавиш для выключения и действие: «/sbin/shutdown -a -h -t 10 now»

В /etc/shutdown.allow добавляем пользователей:

vasya vova

В /etc/shutdown.allow добавляем пользователей:

vasya

vova

По одному пользователю на строку. ЛОР коде испортил.

Ядро Linux может слать проге уведомления через inotify, fanotify. Например антивирусное с проверкой файлов при доступе их использует для сканирование файла перед тем как его прочитает/запишет другая прога.

Меня dbus + polkitd настораживает.. И необходимости в ней не вижу.

Ладно все это будет спором как о нужности и целях systemd.

Я их не использую и не вижу в них необходимости.

Дело хозяйское, как говорится.

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

Безопасность 2020

Потратил 9999 часов на настройку секьюрности своего локалхоста

@

Тебя трахнули через утекшую почту в чужом облаке

Я всегда обновлял через терминал.

Так и делай. Не знаю как там в кедах, а gnome-software можно запретить вообще заниматься обновлениями(через dconf-editor будет удобнее это сделать).

Тебе стоит прекратить истерику и разобраться в вопросе.

Правило polkit для PackageKit выглядит вот так:

 # cat /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules
 polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.packagekit.package-install" &&
         subject.active == true && subject.local == true &&
         subject.isInGroup("wheel")) {
             return polkit.Result.YES;
     }
 });

Читать как «пользователь в группе wheel может выполнить действие установить пакет без ввода пароля».

Это не единственное что может пользователь в группе wheel, поэтому случайных пользователей вообще говоря в неё не добавляют. И правильным решением в данном случае будет бабушек, племенников и т.п. в эту группу не помещать.

Если тебе всё же не нравится конкретно это правило - отключи его.

Если тебе не нравится PackageKit - удали его. И пользуйся dnf из командной строки.

Приплетать сюда Qt, Wayland, systemd и пятна на солнце совершенно необязательно.

Будучи вдохновлённым этим топиком, нарыл то же правило в своей федоре и пробовать YES менять на NO и на AUTH_SELF. Работает прекрасно, но только для установок пакетов. Обновления продолжают устанавливаться без запроса пароля. Также менял package-install на system-update/upgrade-system - обновления ставятся без пароля.
Это странно.

Может имелось ввиду:

«дать право на выключение компьютера пользователю, если он единственный залогиненный пользователь И его сессия сейчас активна»

Нет, имелось в виду именно то что сказано.

В код Shutdown можно добавить еще один if чтобы он перед выключение проверял отсутствие других залогиненых пользователей (условие единственного пользователя). Но это спорно, возможно vase действительно надо выключить комп, а vova своей сесией не даст.

Да ты что?

А когда мне потребуется разрешать выключение, скажем, только по выходным или вне рабочего времени, ты мне скажешь опять «в код shutdown» что-то добавлять?

В код Shutdown можно добавить еще один if <…>

В /etc/inittab добавляем комбинацию клавиш <…>

В /etc/shutdown.allow добавляем пользователей <…>

Это настолько смешно, что даже смешно.

В сраку тебя, гномосек ))

Я надеюсь вы с ТС окрапляете святой водой системник перед включением?

Обновления продолжают устанавливаться без запроса пароля.

Посмотри в /usr/share/polkit/actions/org.freedesktop.packagekit.policy. Там прописаны все возможные действия и дефолтные политики для них.

Как intelfx сказал, для обновлений другие правила, тебе нужен action.id == "org.freedesktop.packagekit.system-update" скорее всего.

Только не надо править файлы в /usr/. Они при следующем обновлении будут перезаписаны.

Надо скопировать файл с правилами из /usr в /etc (/etc/polkit-1/rules.d/org.freedesktop.packagekit.rules) и редактировать там.

Нет, имелось в виду именно то что сказано.

Тогда все будет работать из каробки, без необходимости добавления if.

А когда мне потребуется разрешать выключение, скажем, только по выходным или вне рабочего времени, ты мне скажешь опять «в код shutdown» что-то добавлять?

Для того чтобы компьютер выключался в зависимости от фаз луны, или фазы менструального цикла, надо патчить код shutdown.

Это настолько смешно, что даже смешно.

Смешно до слез - когда надо ставить spidermonkej чтобы собрать правила на JS для polkitd.

Девиз UNIX - простота и совершенство.

Всякие systemd, dbus+polkitd - монструозные дырявые ненужные комбайны.

Девиз UNIX - простота и совершенство.

Правильно, нефиг заморачиваться с условиями, по выходным и в нерабочее время подавай… Еще бы на Пасху захотели. Простота и удобство – вилка питания.

Вход в компьютер пользователя должен иметь возможность ограничиваться по времени - требование безопасности. Реализован в GNU/Linux с помощью pam.

Если кому захотелось иметь возможность выключения компа только в нерабочее время и по выходным то в код shutdown надо добавить проверку еще одного условия - времени. Брать выходные дни и нерабочие время можно с настроек pam. Также следует добавить параметр запуска shutdown для инициализации проверки времени.

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

А вообще ЕМНИП в том же калькулейте так же было - обновы просто ставились и все, без пароля рута.

Это уже винда какая то получается. Те же дыры, под другим соусом.

А тебе не пофиг, как там штатный обновлятор из реп тянет обновы?
Если паранойя мучает - проверь, что репы верные прописаны. Уверен, что доступа к конфигу реп без рута нет.

Правило polkit для PackageKit выглядит вот так:

Ты хочешь сказать что люди будут читать, писать и редактировать правила на «очень удобном» для этого языке JS?

Думаете люди будут использовать систему где контроль безопасности реализован на JS?

Правила безопасности должны быть просты, удобочитаемы и хорошо понимаемы. Пример: https://en.m.wikibooks.org/wiki/Grsecurity/The_RBAC_System#Policy_Structure_in_a_Nutshell

Если паранойя мучает - проверь, что репы верные прописаны.

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

Правила безопасности должны быть просты, удобочитаемы и хорошо понимаемы. Пример: https://en.m.wikibooks.org/wiki/Grsecurity/The_RBAC_System#Policy_Structure_in_a_Nutshell

Классический случай экономии букв там где не следовало.

Многие системщики этим страдают. Они почему-то никак не могут понять что пробивать код руками на перфокартах уже не обязательно. И вместо ручного кодирования информации в минимальную последовательность битов можно пользоваться текстовым редактором и не экономить слова.

Меньше букв - меньше читать и быстрее понимать.

Сокращение «rwx» более привычно и легче читаемо админами чем «read,write,execute»

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

Специально далссылку на очень правильное решения в данной области. Правила с нуля админами по буквам давно уже не набиваются. Есть программы способны сами научится и написать, В УДОБНОМ для верификации человеком виде, правила контроля доступа. После верификации человеком и внесению правок при необходимости, правила компилируется для использования ядром OS.

По этому если людям показывают правила контроля доступа написанные кемто вручную на java script они смотрит на это как на ад и израиль. И конечно для обеспечения своей приватности использовать не будут.

Сокращение «rwx» более привычно и легче читаемо админами чем «read,write,execute»

Это верно только если ты эти сокращения читаешь 100500 раз в день. То есть для вывода в ls это более-менее имеет смысл. Или для горячих клавиш в vi.

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

Для security-правил, которые человек читает и пишет раз в пять лет экономия букв смерти подобна.

По этому если людям показывают правила контроля доступа написанные кемто вручную на java script они смотрит на это как на ад и израиль. И конечно для обеспечения своей приватности использовать не будут.

Ну да, если написанные тобой на коленке правила на плоходокументированном псевдоязыке компилируются в ядро, они сразу приобретают +100500 к безопасности. Автоматом.

Это верно только если ты эти сокращения читаешь 100500 раз в день.

Можно согласится.

Для security-правил, которые человек читает и пишет раз в пять лет экономия букв смерти подобна.

Там букв совсем немного, кроме rwx в MAC еще пару букв применяют. Да, быстро что-то хорошее сделать раз в 5 лет может не получится. Надо посидеть и вспомнить назначение ~ 7 символов. Но это не 10 и не 20. Если символы вбивать в одном и том же порядке код получается очень быстро читаем и понятен.

Ну да, если написанные тобой на коленке правила на плоходокументированном псевдоязыке компилируются в ядро, они сразу приобретают +100500 к безопасности. Автоматом.

Админа который пишет правила контроля доступа вынесем за скобки этого обсуждения.

Здесь важна читаемость правил для их верификации!

По поводу компиляции в ядро если исключить технологии pathbased security у тебя альтернативы:

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

SELinux - от АНБ ;) правила трудно читаемы, нет самообучения.

SMACK - правила просты и понятны, удобно читаемы, нет самообучения.

Потеринг сэкономил на разработке формата правил и написании компилятора тупо взяв JS. Результат - не читаемый код контроля доступа.

в очень удобном виде;

Мерять удобство количеством букв, это как мерить качество кода количеством строк.

SELinux - от АНБ ;) правила трудно читаемы, нет самообучения.

Разумеется, SELinux тоже придуман в далекие времена системными программистами которые экономили буквы.

Гораздо хуже что современные порождения мысли у системных программистов лучше не становятся. На один device tree посмотреть - слезы наворачиваются. А ведь программирование как область деятельности уже дошло до осознания выжности читабельного кода.

Потеринг сэкономил на разработке формата правил и написании компилятора тупо взяв JS.

Интересно, ты понимаешь, что когда приписываешь Поттерингу проекты не глядя ты теряешь авторитет во всех остальных своих замечаниях?

Результат - не читаемый код контроля доступа.

Давай спросим участников треда, могут ли они прочитать процитированный кусок JS-кода и понять что он делает.

Я никогда не программировала на JS например, я поняла, а ты?

Так то оно так, но огромный js движок в зависимостях к системному компоненту выглядит немного диковато.

Интересно, ты понимаешь, что когда приписываешь Поттерингу проекты не глядя ты теряешь авторитет во всех остальных своих замечаниях?

Он сотрудник RH, а они в Linux испортили много..

Мой авторитет в среде пользователей правил контроля доступа написанных на JS - не важен.

Я никогда не программировала на JS например, я поняла, а ты?

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

Мерять удобство количеством букв, это как мерить качество кода количеством строк.

Давай спросим участников треда, могут ли они прочитать процитированный кусок JS-кода и понять что он делает.

Давай проведем более фундаментальное исследование удобства написания и понимания правил контроля доступа среди посетителей ЛОРа. Возьмем в дополнение к JS еще: RSBAC от Grsdcurity, SMACK, SELinux и DAC + /etc/security/*.conf (capability,…).

Запость, пожалуйста, опрос с содержанием (выбор пункта 1 обязателен в GNU/Linux для всех, CONFIG_MUTIUSERS=у и pam отключать запрещено):

Заглавие: «Формат написания и просмотра правил контроля доступа.»

Какое представление, формата написания и просмотра правил контроля доступа для вас более удобено и понятно:

1.) DAC + /etc/security/*.conf (capability, time restrictions, …) - минимальный порог в GNU/Linux!

Классика: chown, chmod, umask, groupadd, usermod, ls, setfacl, getfacl, setfattr, getfattr, … и классические настройки в конфигурационных файлах UNIX /etc/security/*.conf

ls -l

getfacl -pt

getfattr –absolute-names -d -m ‘.*’

2.) SMACK (MAC через LSM) для контроля доступа используется 6 букв. И правила, грубо говоря, имеют следующий вид:

предмет объект доступ

доступ можно писать как при выводе ls с дашем «-»: arwxtb. Чтение и выполнение: -r-x–. Добавление a—–. …. Если строго соблюдать порядок атрибутов доступа и вместо отсутствия ставить «-» то правила будут очень легко пониматся и быстро читатся.

Предмет: файл, каталог, сокет, …

Объект: метка программы, процесса, …

3.) RSBAC от Grsdcurity (как большой плюс: не использует Linux LSM, имеет собственные хуки в ядре)

Пример правила https://en.m.wikibooks.org/wiki/Grsecurity/The_RBAC_System#Policy_Structure_in_a_Nutshell

[pre]

role admin sA

subject / rvka

    / rwcdmlxi

role default G

role_transitions admin

subject /

    /               r

    /opt            rx

    /home           rwxcd

    /mnt            rw

    /dev

    /dev/grsec      h

[/pre]

Имеет чуть больше букв для описание контроля доступа по ролям, предметам и объектам. Большие и маленькие буквы имеют разные значения, например m - разрешает обекту изменять/устанавливать sbit, А M - включает аудит установки sbit-а объектом. …

4.) SELinux (MAC через LSM от АНБ).

https://selinuxproject.org/page/BasicConcepts

Пример правила:

allow user_t user_home_t:file { create read write unlink };

5. JS с компилятором JIT.

Или без JIT https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey

[code=Java]

polkit.addRule(function(action, subject) {

if (action.id == "org.freedesktop.packagekit.package-install" &&

     subject.active == true && subject.local == true &&

     subject.isInGroup("wheel")) {


         return polkit.Result.YES;

 }

});

[/code]

огромный js движок в зависимостях к системному компоненту выглядит немного диковато.

Так-же издевательски как страшный комбайн systemd.

Я не поняла зачем ты стал мешать в разговор о читабельности кода заодно и сравнение разных систем контроля доступа. Ради «ненавязчивой» контекстной рекламы вероятно.

Но с читабельностью это явно не к тебе.

Я против использования JS как формата для описания правил контроля доступа.

Здесь и в опроснике сравнивать предлагаю только форматы правил разных систем контроля доступа. На предмет удобочитабельнтсти, простоты и быстроты понимания.

Анониму ЛОРкод отключили, по этому у меня форматирование не работает и плохая читабельность поста выше. Отформатируй его, пожалуйста и запости в опросник.

Анониму ЛОРкод отключили

Не уверен

[code] Мне ЛОРкод отключили за критику RH, поделок Потеринга и федорки. [/code]

Мне ЛОРкод отключили за критику RH, поделок Потеринга и федорки.

Его отключили всем, юзай маркдоун.

Мне ЛОРкод отключили за критику RH, поделок Потеринга и федорки.

Кому ты сдался, параноик?

Какой самый удобный формат для написания и просмотра правил контроля доступа.

Вопросы:

DAC + /etc/security/*.conf (capability, time restrictions, …) этого хватает.

SMACK (MAC через LSM)

RSBAC от Grsecurity (не использует Linux LSM, имеет собственные хуки в ядре)

SELinux (MAC через LSM от АНБ)

polkitd (контроль доступа в dbus)

Текст:

Какое представление, формата написания и просмотра правил контроля доступа для вас более удобено и понятно?

1. DAC + /etc/security/*.conf (capability, time restrictions, …) - минимальный порог в GNU/Linux!

Классика: chown, chmod, umask, groupadd, usermod, ls, setfacl, getfacl, setfattr, getfattr, … и классические настройки в конфигурационных файлах UNIX /etc/security/*.conf

ls -l
getfacl -pt
getfattr –absolute-names -d -m ‘.*’

2. SMACK (MAC через LSM) для контроля доступа используется 6 букв.

less /usr/src/linux/Documentation/security/Smack.txt

предмет объект доступ

    TopSecret    Secret   -r-w--
    Closed       Off      ------
    Gamers       Game     --x---

Предмет: файл, каталог, сокет, …

Объект: метка программы, процесса, …

3. RSBAC от Grsecurity (не использует Linux LSM, имеет собственные хуки в ядре)

less /etc/grsec/policy

role admin sA
subject / rvka
    / rwcdmlxi

role default G
role_transitions admin
subject /
    /               r
    /opt            rx
    /home           rwxcd
    /mnt            rw
    /dev
    /dev/grsec      h

4. SELinux (MAC через LSM от АНБ).

less /usr/src/linux/Documentation/security/SELinux.txt

Пример правила:

allow user_t user_home_t:file { create read write unlink };

5. Polkitd (для контроля доступа в dbus) java script с компилятором JIT. Или без JIT https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey

Пример правила:

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.packagekit.package-install" &&
     subject.active == true && subject.local == true &&
     subject.isInGroup("wheel")) {
         return polkit.Result.YES;
 }
});

s/RSBAC от Grsecurity/RBAC от Grsecurity/