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

Это возможно?

Мы хотим, чтобы некоторые пользователи могли, например, сделать это sudoи стать пользователем root,

Что ж, это проблема, которую sudo предназначен для решения, так что эта часть достаточно проста.

но с ограничением, что пользователь не может изменить пароль root.

Как указал SHW в комментарии, вы можете настроить sudo так, чтобы определенные пользователи могли выполнять только определенные действия от имени пользователя root. То есть, вы можете позволить user1 сделать sudo services apache2 restart, позволяют user2 делать , sudo rebootно ничего другого, позволяя при этом наемный-как-система-администратор user3сделать sudo -i. Существуют инструкции о том, как настроить sudo таким образом, или вы можете искать (или спрашивать) здесь. Это решаемая проблема.

Тем не менее, пользователь, которому была предоставлена ​​возможность sudo -iили sudoв оболочку ( sudo bashнапример), может делать все что угодно. Это связано с тем, что к тому моменту, когда sudo запускает оболочку, само sudo уже исчезло. Он обеспечивает контекст безопасности другого пользователя (чаще всего root), но не может сказать, что делает исполняемое приложение. Если это приложение запускается, passwd rootsudo ничего не может с этим поделать. Обратите внимание, что это можно сделать и с помощью других приложений; например, многие из более продвинутых редакторов предоставляют средства для выполнения команды через оболочку, оболочку, которая будет выполняться с эффективным идентификатором этого процесса редактора (то есть root).

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

Сожалею; если вы действительно имеете в виду «убедитесь, что мы сможем войти в систему и использовать систему независимо от того, что с ней делает кто-то с правами root», это (для всех целей и задач) сделать невозможно. Быстро "sudo rm / etc / passwd" или "sudo chmod -x / bin / bash" (или что-либо другое, что использует root), и вы все равно в значительной степени замаскированы. «В значительной степени шланг» означает «вам нужно восстановить данные из резервной копии и надеяться, что они не сделали ничего хуже, чем скольжение пальцев». Вы можете предпринять некоторые шаги, чтобы уменьшить риск случайного сбоя, ведущего к непригодной для использования системе, но вы не можете предотвратить возникновение очень серьезных проблем со злым умыслом вплоть до необходимости восстановления системы с нуля или, по крайней мере, из известных хорошие резервные копии.

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

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

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

Это практически невозможно. Прежде всего, если вы дадите им возможность стать корнем , то вы ничего не сможете сделать, чтобы помешать им что-либо сделать. В вашем случае, sudoследует использовать, чтобы предоставить вашим пользователям некоторые полномочия root, в то же время ограничивая других, не позволяя им стать root .

В вашем случае, вам необходимо будет ограничить доступ к suи passwdкомандам и открытый доступ к довольно много всего остального. Проблема в том, что вы ничего не можете сделать, чтобы помешать вашим пользователям редактировать /etc/shadow(или, если /etc/sudoersна то пошло) напрямую и сбросить пароль для замены root, чтобы перехватить root. И это только самый простой сценарий атаки. Судоши с неограниченными полномочиями, за исключением одной или двух команд, могут обойти ограничения, чтобы захватить полный root-доступ.

Единственное решение, предложенное SHW в комментариях, состоит в том, sudoчтобы вместо этого предоставить пользователям доступ к ограниченному набору команд.

Обновить

Может быть способ сделать это, если вы используете билеты Kerberos для аутентификации. Прочитайте этот документ, объясняющий использование .k5loginфайла.

Я цитирую соответствующие части:

Предположим, что у пользователя alice в ее домашнем каталоге был файл .k5login, содержащий следующую строку:
bob@FOOBAR.ORG
Это позволило бы bob использовать сетевые приложения Kerberos, такие как ssh (1), для доступа к учетной записи alice с использованием билетов Kerberos bob.
...
Обратите внимание, что поскольку Боб сохраняет билеты Kerberos для своего собственного участника, bob@FOOBAR.ORGон не будет обладать какими-либо привилегиями, требующими билетов Алисы, такими как root-доступ к любому из узлов сайта или возможность изменить пароль Алисы.

Я могу ошибаться, хотя. Я все еще изучаю документацию и еще не попробовал Kerberos для себя.

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

Популярный подход (хотя и очень хакерский) состоит в том, чтобы иметь второго пользователя сuid=0 общим именем toor(root back). Он имеет другой пароль и может служить в качестве резервного доступа. Чтобы добавить, вам, вероятно, потребуется отредактировать /etc/passwdи /etc/shadow(скопировать rootстроки).

Это практически отказоустойчиво, но если вам просто нужно защититься от «главного администратора», меняющего пароль без уведомления, то это сработает. Тривиально отключить, удалив toorаккаунт; таким образом, единственным преимуществом является наличие отдельного пароля.

В качестве альтернативы вы можете захотеть изучить альтернативные механизмы аутентификации, например sshключи libnss-extrausers, LDAP и т. Д.

Обратите внимание, что администратор все еще может испортить плохо. Например, путем блокировки брандмауэра.

Если вы хотите иметь очень защищенную систему, рассмотрите возможность использования SELinux, где пользователь unix (например, root) также имеет роль, которая может быть гораздо более детальной. Возможно, вы захотите предоставить администратору доступ с правами администратора, но только с ограниченными правами (например, для администрирования только Apache). Но это потребует довольно много усилий с вашей стороны, чтобы правильно настроить политику.

Суть root в том, чтобы иметь неограниченное управление системой. Вы можете настроить его с помощью SELinux (раньше был демонстрационный сайт, где любой мог войти в систему как root, но его мощность была ограничена через систему доступа), но это не главное. Дело в том, что это неправильное решение вашей проблемы.

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

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

PS. Есть много способов устроить себе root-доступ без пароля; с одной стороны, если вы находитесь /etc/sudoers(без ограничений), вам нужен только собственный пароль, чтобы стать пользователем root, например, с помощью sudo bash. Но вам просто не нужно идти туда.

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

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

Возможно, вам следует рассмотреть возможность предоставления пользователям корневого доступа к виртуальной машине или контейнеру LXC. Это позволило бы им иметь полный root-доступ к системе, не позволяя им войти в систему на хосте или выполнить административные действия.

Я не знаю, будет ли это практически осуществимо, но вот один грязный хак:

1. написать скрипт / программу-обертку, которая скопирует /etc/passwdфайл в другое место перед вызовом фактическогоsudo
2. Разрешить обычному пользователю использовать sudo
3. Как только он закончит свою задачу, или когда он выйдет из sudo, восстановите /etc/passwdфайл

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

Утверждение, что sudoэто просто для предоставления root и никакой защиты после этого, явно ложно.

Вы используете visudoдля изменения файла sudoers. Вот пример строки:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroэто имя пользователя, которому мы даем разрешение. Поместите %спереди, чтобы применить его к группе.
• ALLэто имя для этого правила. Судоши могут сделать гораздо больше, чем просто предоставить глобальные разрешения. Вот где это все сложнее, хотя.
• = не нуждается в объяснении
• ALL:ALLчитается как (who_to_run_it_as: what_group_to_run_it_as). Таким образом, вы можете разрешить запуск команды, но только в контексте определенного пользователя или группы.
• NOPASSWD: говорит отключить запрос пароля.
• /path/to/command позволяет указать конкретные команды path_to_commmand, another_command

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

Рекомендации

• из моего другого ответа здесь

(Я не знаю ubuntu, но он должен быть похож на Fedora / Red-Hat)
Единственное, что я могу себе представить, ограничение доступа для изменения пароля root - это не предоставление полного доступа root, возможно, с помощью sudo, или использование SElinux для ограничения доступа. к файлу паролей ... но я бы не стал доверять с большим доступом, так как root обычно имеет неограниченный доступ и может обновить SElinux, или поменять файл пароля, или запустить какую-либо заранее подготовленную программу для изменения пароля.

Если вы недостаточно доверяете им, чтобы не сменить пароль, вам, вероятно, не следует предоставлять им root-доступ. В противном случае, я думаю, вы пытаетесь избежать несчастных случаев.

Если вы только пытаетесь защитить свой доступ к root, настройте программу, которая может восстановить пароль root, поэтому, даже если он был изменен, его можно восстановить с минимальным доступом. (sudo преуспевает сам по себе)

Ваше требование:

У нас есть небольшая проблема на сервере, [...] которая является гарантией того, что мы все еще можем войти на этот сервер и стать пользователем root независимо от того, что будут делать другие пользователи.

Из вашего вопроса кажется, что вы не сталкиваетесь со случайными злонамеренными пользователями, намеревающимися уничтожить вашу систему, но вместо этого имеете полудоверенных пользователей, которые могут время от времени причинять вред (возможно, студенты?). Мои предложения касаются этой ситуации, а не тотального нападения злоумышленников.

1. Запустите сервер в виртуальной среде. Вы сможете смонтировать файловую систему сервера и заменить измененные файлы на заведомо исправные версии. В зависимости от ожидаемого ущерба, вы можете сделать снимок всех критических каталогов (/ bin, / sbin, / etc, / usr, / var и т. Д.) И расширить снимок, чтобы перезаписать поврежденные файлы, оставив оставшуюся часть система не повреждена.

2. Запустите систему только для чтения, например, с DVD-R. Если вы можете жить с большей частью системы в статическом состоянии до следующей перезагрузки, это хороший вариант. Вы также можете использовать резервное хранилище только для чтения с виртуальной средой или загружать базовую систему по сети, делая изменения между перезагрузками гораздо проще, чем запись нового DVD-R.

3. Модули ядра. Модули безопасности Linux (LSM) ядра обеспечивают основу для создания безопасных модулей. LSM используется SELinux, но также используется рядом менее известных и более простых систем, таких как Smack, TOMOYO и AppArmor. Эта статья имеет хороший обзор вариантов. Скорее всего, один из них может быть настроен «из коробки» для предотвращения доступа на запись в / etc / passwd, / etc / shadow или в любой другой файл (файлы), который вы хотите, даже с правами root.

4. Та же идея, что и у # 1, но когда сервер находится не в виртуальной среде. Вы можете получить цепную загрузку сервера в ОС, предназначенную только для чтения, такую ​​как live CD, которая будет автоматически монтировать файловую систему сервера и перезаписывать базовую систему при каждой загрузке копиями с заведомо исправными копиями. Только для чтения ОС будет загружаться в основную ОС.

5. Опять же, если предположить, что это полу доверенные пользователи, которые подотчетны высокому руководителю (учителю / начальнику), лучшим ответом может стать аудит Linux . Таким образом, вы будете знать все предпринятые действия, относящиеся к безопасности, и кто их предпринял (вы будете знать, кто их предпринял, потому что даже если все пользователи имеют общую учетную запись root, они сначала будут sudo'ed из своей учетной записи пользователя). На самом деле вы можете даже анализировать журнал аудита в реальном времени и заменять поврежденные файлы. / etc / shadow перезаписан? Нет проблем, просто сделайте так, чтобы сервер мониторинга мгновенно заменил его верной версией.

Другие технологии, которые вы можете исследовать в зависимости от ваших потребностей:

• Архитектура измерения целостности Linux / Модуль расширенной проверки (IMA / EVM), и
• Доверенные платформенные модули (TPM).

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

Большим преимуществом этого является то, что настраивать нечего. Ваш вопрос звучит так: « Я забыл пароль root, как мне вернуться обратно? » И ответом на это является перезагрузка и выбор однопользовательского режима при включении компьютера. Это дает вам корневую оболочку без необходимости знать пароль. В этот момент вы можете установить новый пароль. (А также пойти и восстановить любой ущерб ...)

Если вы клонируете свой сервер в виртуальную машину (например, VirtualBox ), вы можете предоставить пользователям неограниченный root-доступ и при этом гарантировать, что у вас всегда будет прямой доступ к разделам (-ям) гостевой операционной системы, и, следовательно, поддерживать окончательный контроль над /etc/passwdи подобное, так как у вас будет root на хост-системе.

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

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

Тем не менее, предполагая, что вы можете доверять своим пользователям, чтобы не быть злыми намерениями, вы можете ограничить изменение пароля вопросом политики . Вы можете создать оболочку для passwdпрограммы, которая будет напоминать им «пожалуйста, не меняйте пароль root». Это предполагает, что источником проблемы является то, что пользователи, которые изменяют пароль root, делают это из-за недопонимания (например, думая, что они меняют свой пароль после этого sudo bash).

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

Аспект мониторинга и обнаружения - это сложная техническая проблема, которая может быть решена другим вопросом, если вы решите пойти по этому пути. Мне кажется, нам нужно

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

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

Реализация может быть сделана путем модифицированной libc или (намного лучше) трассировки системных вызовов.

Конечно, невозможно на 100% правильно выполнить такую ​​трассировку и ведение журналов, это нелегко реализовать и требует дополнительных ресурсов для работы. Это не остановит смену пароля или другие нежелательные попытки взлома системы, но сделает (более вероятным) возможным найти виновного пользователя или, по крайней мере, создаст иллюзию того, что существует мониторинг, и сделает его менее привлекательным для некоторых злых пользователей (но некоторые любящие проблемы хакеры, которые видят фундаментальную бесполезность введенных технических мер, могут почувствовать желание принять вызов и попытаться обойти систему просто ради удовольствия).

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

Проблема заключается в следующем: если владелец имеет физический доступ к ящику, он может легко восстановить логический доступ к системе (при условии, что он все еще жив :). В противном случае сохранение пароля root не спасет вас, например, от sshd или настройки плохой сети, поэтому система все равно недоступна.

Тема о том, как предотвратить повреждение системы человеком с правами администратора, кажется слишком широкой, чтобы соответствовать формату вопросов SE.

Говоря об удаленном экстренном вводе, лучшим способом является IPMI (я думаю), если он доступен. Владелец системы может подключить виртуальный диск в любое время, загрузиться с него и продолжить восстановление системы.

Если IPMI недоступен, можно использовать любую подходящую технологию виртуализации, как уже было предложено выше.

Вы можете ограничить доступ к sudo в своем /etc/sudoersфайле

Чтобы полностью объяснить синтаксис / etc / sudoers, мы будем использовать пример правила и разбить каждый столбец:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Первый столбец определяет, к какому пользователю или группе относится это правило sudo. В данном случае это пользователь jorge. Если слову в этом столбце предшествует символ%, оно обозначает это значение как группу, а не пользователя, поскольку в системе могут быть пользователи и группы с одинаковыми именами.

Второе значение (ALL) определяет хосты, к которым применяется это правило sudo. Этот столбец наиболее полезен при развертывании среды sudo в нескольких системах. Для настольной системы Ubuntu или системы, в которой вы не планируете развертывать роли sudo на нескольких системах, вы можете оставить это значение равным ALL, что является подстановочным знаком, соответствующим всем хостам.

Третье значение задается в скобках и определяет, каким пользователем или пользователями пользователь в первом столбце может выполнять команду. Это значение имеет значение root, что означает, что jorge будет разрешено выполнять команды, указанные в последнем столбце, от имени пользователя root. Это значение также может быть установлено в подстановочный знак ALL, что позволит jorge запускать команды как любой пользователь в системе.

Последнее значение (/ usr / bin / find, / bin / rm) представляет собой список команд, разделенных запятыми, которые пользователь в первом столбце может выполнять как пользователь (и) в третьем столбце. В этом случае мы разрешаем jorge запускать find и rm как root. Это значение также может быть установлено в подстановочный знак ALL, что позволит jorge запускать все команды в системе от имени пользователя root.

Имея это в виду, вы можете разрешить X-команды запятыми и, если вы не добавите passwdк этому, все будет в порядке.

Корня 1/2 нет :) Как только вы дадите права root, они могут делать все, что захотят. В качестве альтернативы вы можете использовать sudo для запуска ограниченной оболочки bash или запустить rbash без прав root.

Если вы хотите иметь отказоустойчивый механизм для входа на сервер от имени пользователя root, вы можете создать другого пользователя uid=0или создать простой cron, который будет периодически сбрасывать пароль root.

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

су -

стать корнем. Root uid = 0; UID колеса = 10. Люди используют имена, но ОС использует uid. Определенные команды не могут быть выполнены членом группы колес. (Если вы используете wheel, не делайте ошибку, добавляя root в качестве члена группы wheel). Посмотрите документацию Red Hat, если вы не знаете, что такое колесо.

Другой вариант - использовать ключ ssh, а не пароль. Предполагая, что вы можете быть уверены, что пользователи, использующие sudo, не добавляют свои открытые ключи в файл ~ / .ssh / авторизованные ключи, это позволяет избежать любых проблем, связанных с изменением пароля root, поскольку пароль root эффективно игнорируется.

Если вы предпочитаете расширять доверие к этим пользователям (не добавляя их собственный открытый ключ), попробуйте использовать расширенные атрибуты файла и бит Immutable. После создания файла ~ / .ssh / authorizedkeys и после настройки / etc / ssh / sshd_config и / etc / ssh / ssh_config, как вам нравится, установите бит Immutable. Конечно, есть способы с этим справиться - ничто не идеально.

В любой системе инсайдеры несут наибольший риск. Человек, который управляет шоу, находится наверху груды. Связанная мысль относится к контрактам. Адвокаты скажут вам: «Никогда не ведите дела с кем-то, с кем вам нужен контракт для ведения бизнеса». Здравый смысл говорит нам: «Никогда не занимайся бизнесом без контракта». Когда вы найдете кого-то, кому вы доверяете, чтобы вести бизнес, напишите контракт, исходя из потребностей друг друга.

Все представленные ответы, включая мой, не соответствуют физическому доступу. Кто бы ни имел это, имеет контроль. Если это не вы, то, скорее всего, у вас есть способ заставить человека, который имеет физический доступ к машине, в случае, если кто-то найдет способ запретить вам вход в систему, или если они найдут способ войти в систему даже после того, как вы Я пытался предотвратить это. Конечно, если у вас есть физический доступ, то, возможно, в этих вещах нет необходимости, хотя в любом случае следует рассмотреть возможность реализации пары, если вы заинтересованы в том, чтобы НЕ быть неудобным.

Джон Кроут

Одним из способов было бы убедиться, что /etcэто не доступно для записи. Никто, пока не может быть sudoerвокруг.

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

Это можно сделать с помощью локального устройства, которое препятствует доступу на запись. (Поиск write blockerоборудования)

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

Чтобы быть уверенным в том, что пользователь также не может испортить ваши возможности входа в систему, вам необходимо установить /binи только для чтения /sbin.

И вам придется иметь скрипт, который периодически восстанавливает сетевое соединение.

(Как примечание: если вы разрешите sudoer только очень ограниченный набор команд и для каждой из них убедитесь, что они не могут вырваться из них / заменить их и т. Д., Вы можете предотвратить это, имея возможность /etcзаписи ...)