Могу ли я создать * супер * суперпользователя, чтобы у меня действительно был пользователь, который может отказать в праве доступа root?
Способ UCSPI-TCP
Существуют другие инструменты, кроме netcat. Вот как использовать некоторые из них. Все они предполагают существование сценария службы , который запускает вашу функцию , чем бы она ни была:
#!/bin/sh
while read -r MESSAGE
do
echo 1>&2 "${TCPREMOTEIP}" "${TCPREMOTEPORT}" rx "${MESSAGE}"
func
done TCPREMOTEIP и TCPREMOTEPORT переменные среды определяются протоколом UCSPI-TCP.
Сценарий создается как отдельный процесс для каждого TCP-соединения с использованием различных наборов инструментов. Далее инструменты показаны как используемые в коротком скрипте. Такой сценарий, обычно называемый run , позволяет запускать их под управлением сервисного менеджера семейства daemontools. Конечно, их можно вызывать напрямую.
Bernstein ucspi-tcp
С ucspi-tcp Дэниела Дж. Бернштейна tcpserver порождает скрипт службы :
#!/bin/sh -e exec tcpserver -v -P -R -H -l 0 0.0.0.0 7777 ./service
Существуют расширенные версии Bernstein ucspi с поддержкой IPv6 -tcp. В случае с Эрвином Хоффманом tcpserver пытается одновременно обрабатывать IPv4 и IPv6 (если операционная система поддерживает это, некоторые нет) и порождает сценарий службы :
#!/bin/sh -e exec tcpserver -v -P -R -H -l 0 ::0 7777 ./service
Bercot s6 -networking, s6 и execline
В s6-network Лорана Берко, s6-tcpserver4 и s6-tcpserver6 обрабатывают IPv4 и IPv6 отдельно и порождают службу скрипт:
#!/command/execlineb s6-tcpserver4 -v 0.0.0.0 7777 ./service
#!/command/execlineb s6-tcpserver6 -v ::0 7777 ./service
Можно создать более сложные серверы, вставив такие инструменты, как s6-tcpserver-access и s6-applyuidgid в цепочку непосредственно перед ./ сервис .
nosh UCSPI tools
С помощью набора инструментов nosh tcp-socket-listen прослушивает сокет TCP, снова обрабатывая IPv4 и IPv6 одновременно, если операционная система поддерживает это, и связывается с ] tcp-socket-accept , который, в свою очередь, порождает скрипт службы :
#!/bin/nosh tcp-socket-listen --combine4and6 :: 7777 tcp-socket-accept --verbose --localname 0 ./service
Или один запускает два отдельных процесса в операционных системах, таких как OpenBSD:
#!/bin/nosh tcp-socket-listen 0.0.0.0 7777 tcp-socket-accept --verbose --localname 0 ./service
#!/bin/nosh tcp-socket-listen :: 7777 tcp-socket-accept --verbose --localname :: ./service
Можно создать более сложные серверы вставив в цепочку такие инструменты, как ucspi-socket-rules-check и setuidgid .
#!/bin/nosh tcp-socket-listen --combine4and6 :: 7777 setuidgid unprivileged-user tcp-socket-accept --verbose --localname 0 ucspi-socket-rules-check --verbose ./service
Pape ipsvd
С помощью ipsvd Геррита Папа tcpsvd порождает сценарий службы :
#!/bin/sh -e exec tcpsvd -v 0.0.0.0 7777 ./service
UCSPI-UDP
Общий сценарий службы может обрабатываться, когда стандартный ввод - это сокет потока . Но вы не указали TCP явно.
Хотя некоторые из вышеупомянутых наборов инструментов могут быть использованы для создания серверов UDP аналогично тому, как их можно использовать для создания серверов TCP (см. udp-socket-listen на пустом месте), построить сложно. фактическая служебная программа со сценарием оболочки, поскольку встроенные функции оболочки не обязательно хорошо справляются, когда стандартный ввод представляет собой сокет дейтаграммы .
Дополнительная литература
- Протокол:
- Джонатан де Бойн Поллард (2016). Генератор клиент-серверного программного интерфейса UNIX . Часто задаваемые ответы.
- Дэниел Дж. Бернштейн (1996). Клиент-серверный программный интерфейс UNIX . cr.yp.to.
- наборы инструментов:
- справочные руководства:
- Дэниел Дж. Бернштейн. Программа
tcpserver. ucspi-tcp. - Эрвин Хоффманн.
tcpserver. ucspi-tcp6 . fehcom.de. s6-tcpserver4. Лоран Берко. s6-сеть . skarnet.org.s6-tcpserver6. Лоран Берко. s6-сеть . skarnet.org.s6-tcpserver-access. Лоран Берко. s6-сеть . skarnet.org.s6-applyuidgid. Лоран Берко. s6 . skarnet.org.- Джонатан де Бойн Поллард (2016).
tcpserver. nosh Guide . Программное обеспечение. - Джонатан де Бойн Поллард (2016).
TCP-сокет-прослушивание. Руководство по эксплуатации . Программное обеспечение. - Джонатан де Бойн Поллард (2016).
tcp-socket-accept. Руководство по эксплуатации . Программное обеспечение. - Джонатан де Бойн Поллард (2016).
ucspi-socket-rules-check. nosh Guide . Программное обеспечение. - Джонатан де Бойн Поллард (2016).
setuidgid. nosh Guide . Программное обеспечение. - Джонатан де Бойн Поллард (2016).
udp-socket-listen. nosh Guide . Программное обеспечение. tcpsvd. ipsvd . Геррит Папе. smarden.org.
- Дэниел Дж. Бернштейн. Программа
Не могу поверить, что никто не упомянул 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 - не способ сделать это. Стоит также отметить, что обычные ответы (неизменяемые файлы или LSM) не будут работать для вашего конкретного случая использования, поскольку APT (и большинство других менеджеров пакетов) выручат, если они не смогут установить файлы.
На самом деле вы хотите задать вопрос:
Есть ли способ запретить APT устанавливать определенные файлы?
Это нечто совершенно отличное от того, о чем вы спрашиваете на нескольких уровнях.
Теперь, что касается этого вопроса, я сам не уверен на 100%, но я знаю, что у ряда других менеджеров пакетов есть опции для предотвращения установки определенных файлов (например, в системе Gentoo Portage есть опция INSTALL_MASK=, который фактически принимает шаблоны соответствия в стиле оболочки для вещей, которые не нужно устанавливать). Я был бы более чем готов поспорить, что такая опция существует для APT (или, возможно, для самого dpkg).
УДАЛИТЬ sudo
Как насчет удаления sudoи символической ссылки /bin/suна /bin/false] ? Соедините это с тем, что убедитесь, что rootне может войти через ssh, и вы заблокировали систему.
Это делает rootСупер*СуперПользователем, а все остальные подчиняются ему.
Для файлов, замененных при обновлении, просто не делайте никаких обновлений. Более реалистично изменить права доступа к файлам на 440или 444, чтобы они не могли быть записаны. Или поместите их в репозиторий git, чтобы, если они будут перезаписаны, их можно было отменить.
Нужный вам «пользователь» называется LSM :Модуль безопасности Linux. Наиболее известны SELinux и AppArmor.
Таким образом, вы можете запретить некоторым двоичным файлам (и их дочерним процессам )выполнять определенные действия (, даже если их UID равенroot). Но вы можете разрешить эти операции gettyи его дочерним процессам, чтобы выполнять их вручную.
Если вы просто хотите предотвратить изменение/удаление файлов или каталогов, просто установите для них неизменяемый флаг.
chattr +i <file>
Даже root не сможет ничего с ними сделать, пока флаг не будет снят. Также можно использовать систему контейнеров/пространств имен для предотвращения корневого доступа, но это кажется излишним для того, что вам нужно.
Для программного обеспечения, подобного APT , которому при нормальной работе требуется доступ практически ко всей системе, ограничение является проблематичным. Даже если вы запретите ему доступ к определенным частям системы, скорее всего, у злонамеренного распространителя будет более чем достаточно возможностей для обхода. Например, заменив библиотеку или просто двоичный файл, или добавив вредоносное изменение конфигурации, которое в конечном итоге будет использовать неограниченный root.
В зависимости от того, насколько сильно вы установите ограничения, некоторые сценарии установки могут сломаться.
Чтобы ограничить приложения и пользователей, вы можете написать политику AppArmor или SELinux. Какая политика будет больше поддерживаться, зависит от вашего дистрибутива :На основе Debian лучше поддерживается AppArmor, в то время как дистрибутивы на основе Fedora/RHEL включают SELinux по умолчанию.
И AppArmor, и SELinux работают с политиками белого списка , которые содержат правила, разрешающие (или запрещающие )определенные действия. Политики применяются к процессу в exec , аналогичным образом пользователи могут быть ограничены, когда политика применяется к их процессам в -in.Хорошо продуманную политику нельзя обойти (, если не учитывать ошибки ядра ). Ограниченный процесс, работающий от имени пользователя root (uid 0 ), ограничен настроенной политикой и не может изменить его, если это явно не разрешено политикой.
Язык политики AppArmor определяет правилоотказа , которое можно использовать для построения политики черного списка . Хорошим местом для начала работы с AppArmor являются справочные страницы AppArmor , вики и просмотр существующей конфигурации вашего дистрибутива в /etc/apparmor.d/.
Множество материалов по администрированию и разработке SELinux представлено в SELinux wiki . Эталонная политика SELinux размещена на github.
Вы можете запустить гипервизор типа -1, например гипервизор Xen и пусть ваша обычная ОС будет размещена в качестве виртуализированного гостя. Гипервизор управляет виртуальной гостевой ОС на более «глубоком» уровне, чем root, поскольку он контролирует (виртуальное )оборудование, на котором работает гостевая ОС.
Вы можете запрограммировать гипервизор для управления гостевой ОС различными способами, включая изменение разрешений, создание и применение резервных копий, перехват определенных изменений или инструкций в гостевой ОС для внедрения дополнительных функций, проверки и т. д. Это было бы правильным,потенциально полезный способ реализации системы типа unix с «пользователем» (, на самом деле функцией гипервизора )для «делания вещей, которые не может сделать даже root»
Я чувствую, что этот подход, вероятно, является излишним
Поместите резервную копию в безопасное место. После любой установки/обновления немедленно замените определенные файлы из этой резервной копии -. Таким образом, никаких ошибок, которые могут испортить установку, вы все равно получите файл (s ), который хотели сохранить.
Работа с навесного привода
Обратите внимание, что это в основном концептуальный ответ, но я думаю, что он должен работать и соответствовать духу того, чего вы хотите достичь.
Пусть система X будет вашей рабочей системой, а система Y — другой системой, которой вы управляете
- Смонтировать каталог из Y как диск в X
- Настройте права таким образом, чтобы пользователь root X имел права на все на этом подключенном диске, за некоторыми исключениями
Теперь у вас есть «рабочий корень», который может делать почти все, и у вас есть «суперкорень», фактическая корневая учетная запись системы Y, которая действительно может делать все.
Вы неправильно понимаете концепцию пользователя root.
Проще говоря, rootнаходится на вершине дерева.
Что, если однажды вы решите стать «суперсуперпользователем», а в следующем месяце — «суперсуперсуперпользователем» (! ). Как далеко «вверх» по дереву вы хотели бы подняться? Как бы вы перетасовали все разрешения и иерархию, чтобы это работало? Кто всегда на высоте? Кто-то должен быть наверху, и это root. Конец истории.
Приведенные здесь решения -, включая AppArmor и SELinux -, на самом деле ничего не меняют. Они просто обеспечивают более тонкий контроль над rootразрешениями и процессами.
Мне кажется, что ваш процесс обновления не подходит для желаемого результата. Но это вовсе не вина пользователя root. Вместо того, чтобы все усложнять, подумайте о rootкак о пользователе с правами самого высокого уровня, а затем обо всем остальном вам придется работать сверху вниз.
Я знаю, что некоторые люди пометят это,но в иерархии пользователей нет более высокого уровня, и все остальные решения просто дают немного другой контроль над тем, как работают разрешения root. Но они не создают нового пользователя с более высокими правами.
У вас не может быть пользователя с «больше разрешений», чем root, потому что rootпредставляет собой максимально возможный уровень разрешений. Использование такой фразы, как «больше контроля, чем root», является противоречием-rootимеет полный контроль и все возможные разрешения, поэтому над ним ничего нельзя сделать.
Взгляните на cgroups и пространства имен Linux в качестве альтернативного метода достижения цели такого типа, а также основанные на них инструменты, такие как Docker и lxd .
Эти инструменты позволяют, помимо прочего, ограничивать доступ к частям файловой системы для процесса, запущенного с правами root, ограничивать, какие процессы ему видны, и предоставлять только определенные возможности для «корневой» пользователь.
На самом деле это довольно просто.
Root — ваш «супер-суперпользователь»
Создайте учетную запись с именем «admin» и предоставьте ему все права root, кроме тех, которые вам не нужны.
Затем создайте пользователя с именем bob и позвольте ему «стать администратором». Используя su или даже sudo.
Теперь у вас есть обычный пользователь (bob )суперпользователь с правами администратора (admin )и суперпользователь (root ).
Если вы хотите изменить имя "root" на другое, вы даже можете это сделать. Технически имеет значение только идентификатор пользователя (0 ).
Вместо суперпользователя -super -вы можете ограничить root. видеть Какие существуют способы установки прав доступа к файлам и т. д. в gnu/linux
Также есть AppArmor и SELinux.
И/или настроить
sudo, чтобы не отдавать полные привилегии суперпользователя. Вы можете настроить его так, чтобы пользователь мог запускать только предварительно -согласованные команды с предварительно -согласованными аргументами.Вы также можете использовать виртуализацию для ограничения root:
- cgroups, namespaces, chroot и т. д. (Docker делает это)
- Зен
- Виртуальный бокс
См. также
etckeeper:эта версия инструмента управляет каталогом/etcи синхронизируется с apt. По умолчанию это небезопасно, вредоносная установка может саботировать его, но вы также можете заставить его отправлять изменения в хранилище резервных копий, защищенное огнем -.Использование системы контроля версий в целом с огнестойким -защищенным хранилищем резервных копий. Это помогает при случайных, преднамеренных повреждениях и сбоях оборудования.
Репозитории резервных копий, защищенные брандмауэром, могут находиться на другой машине, в Интернете, на другой виртуальной машине (или на хосте виртуальной машины ).