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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

chattr +i <file>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я не могу поверить, что никто не упомянул 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

УДАЛЕНИЕ sudo

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

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

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