Могу ли я создать * супер * супер-пользователя, чтобы на самом деле мог иметь пользователя, который может отказать в праве root?

34

Я думал, что было бы выгодно иметь пользователя с разрешениями выше, чем пользователь root.

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

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

Одно из преимуществ этого позволит мне предотвратить установку некоторых нежелательных файлов во время обновлений. Это всего лишь пример одного возможного преимущества.

Поскольку обновления apt-get запускаются пользователем root или с правами sudo, apt-get может заменять определенные нежелательные файлы во время обновлений.

Если бы я мог отказать в этих привилегиях этим отдельным конкретным файлам, я мог бы установить их как simlink для /dev/nullили, возможно, иметь пустой файл-заполнитель, который мог бы иметь разрешения, которые запретили бы замену файла во время обновления.

Кроме того, я не могу не напомнить о строке, которая была сказана в интервью с одним из создателей Ubuntu, когда парень сказал что-то о том, как пользователи лучше доверяют «нам» (обращаясь к разработчикам Ubuntu) «потому что у нас есть root msgstr "который был ссылкой на то, как обновления системы выполняются с правами root.

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

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

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

Примечание. Хотя я считаю, что принятый ответ больше всего соответствует критериям, мне действительно нравится ответ @CR. также.

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

Кроме того, я не пытаюсь выбрать Ubuntu здесь; Я бы не стал использовать его в качестве основного дистрибутива, если бы чувствовал себя отрицательно.

permissions sudo users root mchid
источник
4
О каких файлах вы говорите и почему? « запретить установку определенных нежелательных файлов» означает, что файлы (как правило) не существуют, и вы хотите, чтобы они не делали этого; но "_hat бы запретил замену файла во время обновления. " предполагает, что файлы уже существуют (с, по-видимому, желательным содержимым), и вам не нужны новые версии.
TripeHound
6
Помните, что любой метод, который предотвращает apt(пере) запись файлов, может привести к ошибке, прерывая процесс обновления. aptзатем откажется делать какие-либо обновления или установки, пока «проблема» не будет решена.
Dubu
6
«Простое изменение процедуры установки, чтобы сказать, что обойти эту проблему, совершенно не то, что меня здесь интересует». Может быть и так, но это, как правило, правильный способ решения проблемы, как указано. Ограничение root может быть сделано (формально, root-in-userland - не тот же уровень доступа, что и режим ядра), и существуют системы для его выполнения, но это противоречит философии Unix и базовым принципам безопасности. В общем, если у кого-то есть «частичный» корень, исключить черный список из всего, что он может использовать, чтобы получить «полный» корень, исключительно трудно. Предпочитаю только давать рут доверенному коду.
Кевин
8
@mchid: root - полный контроль. В этом весь смысл. Чтобы он не имел полного контроля, вам нужно отрицать так много вещей, что он больше не выглядит как root (например, не устанавливать модули ядра, не монтировать произвольные устройства и т. Д.). Если вы не хотите запускать вещи как root, не запускайте их как root. Вместо этого раздайте возможности (за исключением всех корневых эквивалентов , не беспокойтесь о них) или запустите демон типа polkitd, который выполняет корневые операции от имени не-корневых процессов.
Кевин
4
@mchid: Вот в чем проблема: у программ есть много способов обойти ваши ограничения. Если вы не внесете в черный список все эти способы, любая программа, которую вы запускаете как «ограниченный root», все равно может стать полноценной root, когда захочет. Так что вся ваша схема - не что иное, как шарада театра безопасности.
Кевин

Ответы:

83

Требуемый «пользователь» называется LSM: модуль безопасности Linux. Наиболее известными являются SELinux и AppArmor.

Этим вы можете запретить определенным двоичным файлам (и их дочерним процессам) выполнять определенные действия (даже если их UID root). Но вы можете разрешить эти операции gettyи их дочерние процессы, чтобы вы могли сделать это вручную.

Хауке Лагинг
источник
2
Но если их UID - root, не могут ли они изменить разрешения selinux, которые в первую очередь мешают им получить доступ?
curious_cat
11
@curious_cat: Да, конечно, вам нужно запретить процессу «ограниченный root» возможность изменять / повышать свое собственное разрешение! Люди, которые написали SELinux, уже думали об этом ...
Питер Кордес
8
@curious_cat Вы можете настроить LSM так, чтобы было совершенно невозможно изменить их конфигурацию во время выполнения. Вы должны перезагрузиться и дать параметр ядра для того, чтобы к этому тогда.
Хауке Лэнг
5
@Joshua Если ваша копия apt-get использует Rowhammer, у вас есть более серьезные проблемы.
Драконис
3
@corsiKa Во-первых, вы хотите ограничить людей, которые могут загружать машину, людьми, которые фактически находятся на машине, потому что системы уязвимы во время загрузки. Запуск перезагрузки по сети - это нормально, но разрешить контроль при загрузке - нет. Во-вторых, правило компьютерной безопасности состоит в том, что вы ничего не можете сделать, когда у злоумышленника есть физический доступ, потому что тогда он может также замочить все в LN2 / перепрограммировать оборудование / и т.д. Так что, да, считается, что тот, кто может изменить загрузку машины, «выиграл» машину.
HTNW
51

Вы неправильно понимаете концепцию rootпользователя.

На простом английском языке rootнаходится на «вершине дерева».

Что если вы решите однажды иметь «супер супер пользователя», а затем в следующем месяце «супер супер супер пользователя» (!). Как далеко "вверх" дерево вы хотите пойти? Как бы вы перетасовали все разрешения и иерархию, чтобы это работало? Кто всегда на вершине? Кто-то должен быть на вершине, и это root. Конец истории.

Решения, приведенные здесь - в том числе AppArmor и SELinux - на самом деле не меняют этого. Они просто обеспечивают более точный контроль над rootразрешениями и процессами.

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

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

У вас не может быть пользователя с «большим количеством разрешений», чем rootпотому, что он rootпредставляет максимально возможный уровень разрешений. Использование фразы типа «больше контроля, чем корня» является противоречием - rootимеет полный контроль и все возможные разрешения, поэтому ничего не поделаешь.

Энди
источник
Я был бы на вершине, а не в корне, конец истории. Поскольку в иерархии пользователей нет более высокого уровня, именно поэтому я хотел бы создать более высокого пользователя.
mchid
Хотя это как раз то, что я хочу: контроль над полномочиями root и процессами, чтобы я мог отказать в разрешении root. Если я могу как-то отказать в праве root, не создавая нового пользователя с SELinux или AppArmor, то, мне кажется, мне не нужен новый пользователь. Я хочу полный контроль, больше контроля, чем root.
mchid
16
У вас не может быть пользователя, у которого «больше разрешений», чем root. Вот и вся проблема. Пользователь, которого вы хотите создать, по сути является пользователем root. Вам нужно подходить к этому по-другому, например, создать пользователя с rootпривилегиями, а затем отказать в определенных, где вы хотите более точный контроль. То, что вы спрашиваете («больше контроля, чем root»), невозможно, или даже вещь!
Энди
@mchid Итак, что вы на самом деле хотите сделать, это переименовать текущего пользователя root в mchid, создать нового пользователя с именем root и заставить apt-get et al использовать вашего нового пользователя без полномочий root?
Одалрик
В некоторых системах rootне имеет разрешения на прямой доступ к оборудованию. Если вы отключите загрузку модулей ядра, вы можете держать root заблокированным от полного контроля над оборудованием ( /dev/memи тому подобным). На самом деле это не относится к разрешениям файловой системы, поскольку вы не будете использовать apt-get, напрямую взаимодействующий с вашим контроллером SATA или NVMe ... Но технически существует состояние «больше разрешений, чем root», и это называется режимом ядра. : P
Питер Кордес
26

Если вы просто хотите предотвратить изменение / удаление файлов или каталогов, просто установите для них флаг неизменности.

chattr +i <file>

Даже root не сможет ничего с ними сделать, если флаг не будет удален. Также можно использовать систему контейнеров / пространств имен для предотвращения доступа root, но это кажется излишним для того, что вам нужно.

CR.
источник
11
Но root может убрать флаг.
17
10
apt, как и почти все, не будет использовать chattr для удаления этого флага.
кр.
13
@sebasth: Исправьте, но сценарии установки Apt, dpkg и per-package (обычно) не изменят атрибуты файла. Вместо этого они просто потерпят неудачу и будут жаловаться, когда они пытаются изменить файлы с неизменным флагом.
Дэвид Фёрстер
4
@TripeHound Итак, ОП хочет apt-getпреуспеть в замене файла, при этом сохраняя этот файл без изменений? Это несколько противоречиво, я смею сказать.
Дмитрий Григорьев
3
@DmitryGrigoryev Это звучит , как они хотят , apt-getчтобы думать , что удалось , но оставить один или несколько файлов без изменений. Они не говорят, какие файлы или почему, но, как вы говорите, несколько противоречивы и склонны к «странному поведению» в будущем.
TripeHound
9

  • Вместо супер-супер-пользователя вы можете ограничить root. Посмотрите , как можно установить права доступа к файлам в GNU / Linux

  • Также есть AppArmor и SELinux.

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

  • Вы также можете использовать виртуализацию для ограничения root:

    • cgroups, пространства имен, chroot и т. д. (Docker делает это)
    • Xen
    • Virtualbox

  • Смотрите также etckeeper: эта редакция инструмента контролирует /etcкаталог и синхронизируется с apt. По умолчанию это небезопасно, вредоносная установка может саботировать его, но вы также можете заставить его вносить изменения в резервное хранилище с огненными стенами.

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

Репозитории Firewalled могут находиться на другой машине, в Интернете или на другой виртуальной машине (или хосте виртуальной машины).

Ctrl-Alt-Делор
источник
8

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

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

Для способов ограничения приложений и пользователей вы можете написать политику AppArmor или SELinux. Такая политика, которая в большей степени поддерживается, зависит от вашего дистрибутива: в Debian лучше поддерживается AppArmor, а в дистрибутивах на основе Fedora / RHEL SELinux по умолчанию включен.

И AppArmor, и SELinux работают над политиками белого списка , которые содержат правила, разрешающие (или запрещающие) определенные действия. Политики применяются к процессу в exec , так же пользователи могут быть ограничены, когда политика применяется к их процессам при входе в систему. Хорошо продуманная политика не может быть обойдена (если ошибки ядра не рассматриваются). Ограниченный процесс, выполняющийся от имени пользователя root (uid 0), ограничен настроенной политикой и не может изменить его, если это явно не разрешено в политике.

Язык политики AppArmor определяет правило запрета , которое можно использовать для создания политики черного списка . Хорошее место для начала с AppArmor - это справочные страницы AppArmor , вики и поиск существующей конфигурации в вашем дистрибутиве /etc/apparmor.d/.

Многочисленные материалы по администрированию и разработке SELinux представлены в вики SELinux . Ссылочная политика SELinux размещена на github.

sebasth
источник
7

Я не могу поверить, что никто не упомянул apt pinning ...

Пару лет назад Microsoft выпустила патч, который мешал компьютерам с Windows 10 общаться с нашими старыми контроллерами домена Samba NT4. Когда проблема была обнаружена, мы закрепили пакет Samba, чтобы остаться в текущей версии, и aptвсе еще работали правильно.

Полный обзор Debian хорошо объясняет этот процесс:

В /etc/apt/preferences(или новый файл в разделе /etc/apt/preferences.d/) добавьте текст, чтобы указать, какой пакет и версия:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

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

ПРИМЕЧАНИЕ: этот ответ предполагает, что у вас есть проблема XY

Канадский Люк ВОССТАНОВИТЬ МОНИКУ
источник
Я сам ответил на несколько проблем XY на askubuntu. Тем не менее, apt это всего лишь пример, и это то, что привело меня к идее. Меня больше интересует аспект "власть-коррумпирует-и-абсолютно-власть-коррумпирует-абсолютно". Полная и абсолютная власть над моей собственной системой - вот что привело меня к Linux в первую очередь. Понимание того, что моя сила не всегда абсолютна над корнем, является своего рода тревожным; идея абсолютной власти заманчива.
mchid
Кроме того, я предполагаю, что это небольшая проблема XY, но Y здесь "как мне отказать в праве root, когда root является суперпользователем?"
mchid
1
@mchid не в том, чтобы запретить права root, а в том, чтобы что-то запретить программе, работающей от имени root.
Джон Китс
6

Это на самом деле довольно просто.

Root - это ваш "супер супер пользователь"

Создайте учетную запись с именем «admin» и предоставьте ему все права root, кроме той, которая вам не нужна.

Затем создайте пользователя с именем bob и позвольте ему «стать администратором». Используя su или даже sudo.

Теперь у вас есть обычный пользователь (bob), супер-пользователь, который может выполнять административные функции (admin) и супер-супер-пользователь (root).

Если вы хотите изменить имя «root» на что-то другое, вы можете даже сделать это. Технически имеет значение только идентификатор пользователя (0).

coteyr
источник
Если бы у меня был обычный пользователь (bob), супер-пользователь, который может выполнять административные функции (admin), и супер-супер-пользователь (root), root не выполнял бы все административные функции с фоновыми процессами, cronjobs и другие вещи, как идентификатор пользователя (0)?
mchid
нет, если вы не хотите их. Большинство сервисов позволяют вам выбрать, какой пользователь работает. Вы можете настроить его так, чтобы пользователь-администратор запускал процессы. Есть несколько исключений, но не так много.
Coteyr
Разве я не должен был бы пройти и установить все эти процессы индивидуально?
mchid
3
Вот что происходит, когда вы пытаетесь нарушить стандартные соглашения. Я думаю, что вам нужно лучше понять, как и почему системы разрешений в среде * nix.
Шона
2
Я согласен с Шоной, вам, похоже, не хватает фундаментального понимания системы разрешений * nix. Это очень мощный, но он не похож на окна.
Coteyr
3

Если вы хотите просто запретить установку определенных файлов, то ограничение прав root не является подходящим способом сделать это. Стоит также отметить, что обычные ответы (неизменяемые файлы или LSM) не будут работать для вашего конкретного случая использования, так как APT (и большинство других менеджеров пакетов) выручит, если они не смогут установить файлы.

Реальный вопрос, который вы хотите задать:

Есть ли способ запретить APT устанавливать определенные файлы?

Это нечто совершенно отличное от того, что вы просите на нескольких уровнях.

Теперь, что касается этого вопроса, я сам не уверен на 100%, но я знаю, что у ряда других менеджеров пакетов есть опции для предотвращения установки определенных файлов (например, в системе Portage Gentoo есть опция INSTALL_MASK=, которая фактически принимает shell -стиль соответствия шаблонов вещей не устанавливать). Я был бы более чем готов поспорить, что такая опция существует для APT (или, возможно, самого dpkg).

Остин Хеммелгарн
источник
Действительно, «Есть ли способ предотвратить установку определенных файлов APT?» это не мой вопрос; это всего лишь пример и то, что напомнило мне вопрос. Новый Firefox поставляется с дополнениями и устанавливает эти файлы даже после того, как пользователь удаляет их с новыми обновлениями. Это на самом деле не проблема; это то, что заставило меня понять, что я хочу еще больше контролировать свою систему. Однако я ценю вашу логику, так как сам ответил на несколько вопросов, поэтому спасибо за вклад.
mchid
dpkg-divert делает это: unix.stackexchange.com/a/157896/70847
mchid
1

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

WGroleau
источник
1

Работа от навесного привода

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

Пусть система X будет вашей рабочей системой, а система Y - другой системой, которой вы управляете

  1. Смонтировать каталог из Y как диск в X
  2. Настройте права таким образом, чтобы пользователь root имел права на все на этом подключенном диске, за некоторыми исключениями

Теперь у вас есть «рабочий корень», который может делать практически все, и у вас есть «супер-корень», действительная учетная запись root системы Y, которая действительно может делать все.

Деннис Джаэруддин
источник
Мне нравится идея, хотя, я хотел бы сделать это на работающей системе.
mchid
1

Вы можете запустить гипервизор типа 1, такой как гипервизор Xen, и использовать его в качестве виртуальной гостевой системы для своей обычной ОС. Гипервизор управляет виртуальной гостевой ОС на уровне «глубже», чем корневой, поскольку он контролирует (виртуальное) оборудование, на котором работает гостевая ОС.

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

Я чувствую, что этот подход, вероятно, излишним, хотя

Натан Смит
источник
Как гипервизор препятствует тому, чтобы пользователь с полномочиями root делал что-либо в гостевой виртуальной машине?
fpmurphy
Этот ответ начинается нормально, но затем грамматически сбивается с пути (тогда он читает неверное или, по крайней мере, двусмысленность). Я сделал исправление.
Ctrl-Alt-Delor
1
@ fpmurphy1 гипервизор может перехватывать системные вызовы, применять политики и т. д. для принудительного применения произвольных ограничений для пользователя root или любой другой части гостевой ОС. Может быть, мой ответ не очень хороший, потому что это слишком много работы, если у вас нет реального корпоративного
Натан Смит
@ ctrl-alt-delor Спасибо за ваше исправление, но я не думаю, что грамматика была проблемой. Я пояснил, что хотел сказать, и я ценю обратную связь, что мои мысли поначалу не были ясны
Натан Смит
1
@ fpmurphy1 в гостевой, у вас есть полный root. Однако это не тот же корень, что и root на хосте. Поэтому это корень меньше, чем корень хоста. Docker позволит вещам быть более интегрированными, но все же накладывает ограничения на root.
Ctrl-Alt-Delor
1

Взгляните на cgroups и пространства имен Linux как на альтернативный метод достижения этой цели, а также на инструменты, основанные на них, такие как Docker и lxd .

Эти инструменты позволяют, помимо прочего, ограничивать, какие части файловой системы может видеть процесс, выполняемый от имени «root», ограничивать видимые ему процессы и предоставлять «определенные» возможности пользователю «root».

SMW
источник
0

УДАЛЕНИЕ sudo

Как об удалении sudoи линке /bin/suк /bin/false? Соедините это с тем, чтобы убедиться, что rootвы не можете войти через систему, sshи вы заблокировали систему.

Это делает rootSuper * Super User, а все остальные подчиняются этому.

Для файлов, замененных во время обновлений, просто не делайте никаких обновлений. Более реалистично, изменить права доступа к файлам , чтобы 440или 444таким образом , они не могут быть записаны. Или поместите их в репозиторий git, чтобы, если они перезаписались, их можно было восстановить.

user176717
источник
Видите ли, я все еще хочу делать обновления, и я все еще хочу, чтобы root делал почти все, что обычно делает root. Тем не менее, я хочу иметь возможность сказать корню «эй, не делай этого» или «нет, ты не можешь этого сделать», как родительские полномочия могли бы сделать с потомством. Как и сейчас, Root похож на родительский авторитет в моей системе, и все маленькие дети говорят: «Мама, а?» когда они используют sudo. Это хорошо. Однако почти каждый человек на этой планете является чьим-то потомком. Кажется, что некоторые ответы здесь таковы, как если бы малыш не осознавал, что малыш был бы до самосознания
mchid
, , , что бабушка и дедушка являются матерями и отцами мамы и папы. Я хотел бы попросить дедушку жить в моей системе, потому что, прямо сейчас, root - это папа дома, и дедушка может сказать папе, что делать, потому что дедушка - отец папы :)
mchid
Похоже, вы добавили слишком много людей с полномочиями sudo. Настройте sudoersфайл так, чтобы только выбранные пользователи могли выполнять предварительно выбранные команды.
user176717
У меня есть только два пользователя в файле sudoers, включая root. Я пытался использовать сравнение, чтобы объяснить, как некоторые люди, кажется, не понимают мой вопрос и чего я хотел бы достичь.
mchid
Кажется, что люди чувствуют, что не может быть ни одного пользователя выше root, так же, как совсем маленький ребенок чувствует, что у его мамы и папы не может быть родителей. Также я не понизил голосование.
mchid