Корневой доступ, который не может изменить пароль root?

Mac OS X не использует стандарт/etc/passwd и/etc/shadow. Вместо этого это использует базу данных. Там используйте, чтобы быть GUI по имени NetInfo, но это было заменено dscl команда (Командная строка Служб каталогов).

$ dscl
> read /Local/Default/Users/David Password
Password: ********

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

Ее детализация статьи с помощью DSCL и взламывая пароли на Mac.

66
16.12.2013, 11:21
18 ответов

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

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

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

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

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

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

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

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

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

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

57
27.01.2020, 19:31
  • 1
    я сожалею свой ответ, получил всю шумиху (я не вполне получаю его!). Ваш ответ поднимает точные вопросы, и я надеюсь, что он принят. +1 Вам, сэру. –  Joseph R. 17.12.2013, 01:49
  • 2
    @JosephR. иногда краткий ответ предпочтен. –  David Cowden 17.12.2013, 04:59
  • 3
    @DavidCowden Да, это кажется дело обстоит так здесь... –  Joseph R. 17.12.2013, 12:48
  • 4
    @JosephR. Никакие заботы для меня. Сообщество Exchange Стека не всегда предсказуемо, и вопросы, которые уже имеют много upvotes, действительно имеют тенденцию притягивать больше. Спасибо за upvote, все же. :) –  a CVn 17.12.2013, 13:55

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

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

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

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

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

И у Вас должен будет быть сценарий, который периодически восстанавливает сетевое соединение.

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

-3
27.01.2020, 19:31
  • 1
    Монтирование / и т.д. только для чтения, в то время как, возможно, возможный (необходимо было бы быть осторожными во время корня центра в сценариях начальной загрузки initrd, например), рискует быть довольно хрупкой установкой. Кроме того, существует много вещей, которые может сделать пользователь с корневым доступом, какие калеки способность других пользователей достигнуть полномочий пользователя root, которые не вовлекают модификации создания в / и т.д. –  a CVn 16.12.2013, 13:57
  • 2
    @MichaelKjörling, установка не хрупка, я часто использую ее (как локальное монтирование только для чтения). –  Angelo Fuchs 16.12.2013, 14:00
  • 3
    @MichaelKjörling я добавил некоторые другие элементы, которые Вы захотите иметь только для чтения, если Вы захотите гарантировать Вам, может все еще войти в систему. Так, список действий, которые должны быть сделаны при потере работоспособности по той дороге, не так короток, но это - единственный путь, который ", гарантия, что мы все еще можем войти в тот сервер и стать корнем, неважно, того, что сделают другие пользователи". –  Angelo Fuchs 16.12.2013, 14:03
  • 4
    я признаю, что никогда не видел потребность попробовать его, но одна вещь, я могу определенно видеть это, был бы опасен, то, как init собирается обработать/etc/inittab, заменяемый под его ногами. Или что сделает система, если начальная буква и повторно смонтированный после того, как/etc/fstab будут отличаться. И существует/etc/mtab. Другие пользователи могут хотеть изменить свои собственные пароли, который включает запись в/etc/shadow и возможно/etc/passwd. И монтирование / и т.д. только для чтения является все еще только частичным решением. Я не говорю, что это не может быть часть решения, но это, конечно, не первый шаг, который я сделал бы в ситуации OP. –  a CVn 16.12.2013, 14:06
  • 5
    Да. Выполнение этого опасно и имеет серьезные проблемы, если сделано неправильно. Все еще насколько я вижу, что это - единственный жизнеспособный способ решить запрос операции в секунду на пользователей, которым нужно разрешить стать корнем. –  Angelo Fuchs 16.12.2013, 15:30

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

su -

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

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

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

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

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

- John Crout

-1
27.01.2020, 19:31
  • 1
    sudo чрезвычайно отличается от su -. На это неоднократно указывали, например, SHW, Joseph R., самостоятельно, hbdgaf и вполне возможно еще несколько, поле комментария слишком коротко для включения... –  a CVn 17.12.2013, 18:05
  • 2
    Все верные, но не важный. Вы обсуждаете альтернативные способы стать корнем и рисками предоставления корневого доступа, но ничто, что имеет любое влияние “на корневой доступ, который не может изменить пароль root”. замена –  Gilles 'SO- stop being evil' 17.12.2013, 18:11
  • 3
    Верный. Вопросом является логический оксюморон; Это не может существовать, если установка не повреждается. Что такое хороший пользовательский вход в систему/учетная запись, где тот пользователь не может изменить их пароль, уже у них есть корневой доступ? Поэтому предлагаемые предложения относятся к тому, что, возможно, имел в виду корреспондент; не к пути они записали вопрос. Любой метод управления доступом имеет свойственный риск. –  John Crout 13.04.2014, 21:53

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

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

-1
27.01.2020, 19:31

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

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

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

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

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

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

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

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

0
27.01.2020, 19:31

Первоначально сформулированный вопрос бесполезен. Похоже, что главная цель, "все еще имеют вход в систему", настолько говорящий о некоторой чрезвычайной ситуации, входят, который продолжает работать наверняка даже с корневым доступом, предоставленным другому человеку. Аплодисменты к Anony-муссу, кто сначала отметил Это явно.

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

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

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

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

1
27.01.2020, 19:31

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

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

2
27.01.2020, 19:31

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

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

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

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

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

  3. Модули ядра. Модули безопасности Linux (LSM) ядра обеспечивают основание для создания безопасных модулей. LSM используется SELinux, но также используется многими менее известными и более простыми системами, такими как Вкус, TOMOYO и AppArmor. Эта статья имеет хороший обзор опций. Возможности являются одним из тех, может быть настроен out-of-the-box для предотвращения доступа для записи к/etc/passwd,/etc/shadow, или любого другого файла (файлов), который Вы хотите, даже корнем.

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

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

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

3
27.01.2020, 19:31

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

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

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

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

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

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

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

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

2
27.01.2020, 19:31

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

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

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

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

Ссылки

  • из моего другого ответа здесь
5
27.01.2020, 19:31
  • 1
    Этот ответ объясняет, как настроить sudo для ограниченного корневого доступа, но было бы намного лучше, если бы в ответе было сказано так и куда это должно пойти. –  a CVn 16.12.2013, 11:02
  • 2
    @MichaelKjörling сделан –  RobotHumans 16.12.2013, 11:05
  • 3
    "Оператор, что sudo только для предоставления корня и нет никакой защиты, после этого является очевидно ложным". Скажем, я предоставляю sudo vi доступ к пользователю, потому что я хочу, чтобы они смогли отредактировать файлы конфигурации системы. Тот пользователь затем делает :!/bin/bash внутри a sudo vi сессия. Как делает способность sudo ограничить то, что управляет, чтобы пользователь мог выполниться через справку sudo защитить мою систему при тех обстоятельствах? (Никто не сказал, что sudo не может быть настроен более плотно, чем бескомпромиссное sudo -i подход.) –  a CVn 16.12.2013, 11:09
  • 4
    , Понимая, что ограничения подхода легко так же важны как знающий, как выполнить задачу. –  a CVn 16.12.2013, 11:15
  • 5
    @MichaelKjörling, я думаю, что это - просто пример. Но быть ясным, правильный способ позволить пользователям отредактировать системные файлы конфигурации состоит в том, чтобы позволить им работать sudoedit. Можно конкретно определить, какие файлы они должны смочь sudoedit. Это находится в man sudoers. –  Matthew Flaschen 17.12.2013, 07:09

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

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

2
27.01.2020, 19:31
  • 1
    как Michael так точно отметил, злонамеренный пользователь может предотвратить корневой доступ, обязательно не угоняя пароль, просто портя двоичные файлы. Даже init=... подход может быть предотвращен, удалив, выполняют полномочия от подходящих двоичных файлов. Я думаю лучшее решение в этом случае, должен смонтировать Вашу корневую файловую систему через LiveCD, и (попробуйте к), фиксируют повреждение. С другой стороны, если Вы полагаете, что система была поставлена под угрозу, Вы - более обеспеченное восстановление от резервного копирования так или иначе. –  Joseph R. 17.12.2013, 01:46
  • 2
    Согласованный @JosephR; обнаружение и фиксация повреждения являются сложными, и я просто переустановил бы также. Но я предполагаю, что беспокойство OP было больше о ком-то, случайно блокирование их... сознательно взламывающий в работе или школьной ситуации является немного суицидальным. ;-) –  Darren Cook 17.12.2013, 01:56
  • 3
    Не обязательно. Действительно злонамеренный пользователь, объединенный с небрежным/невежественным системным администратором, может нарастить необнаруженные полномочия. Я действительно соглашаюсь, что исходное намерение OP состояло в том, чтобы, вероятно, отразить невинные ошибки, а не принять меры против злонамеренного намерения, но вопрос был отмечен "безопасность", и мы просто работали с ним, я предполагаю :) –  Joseph R. 17.12.2013, 01:59

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

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

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

5
27.01.2020, 19:31
  • 1
    Всегда существует возможность, что злонамеренный пользователь прочитает этот сценарий и уничтожит резервную копию. –  Joseph R. 16.12.2013, 11:07
  • 2
    Это также в значительной степени что vipw и друзья уже делают. –  a CVn 16.12.2013, 11:10
  • 3
    Считайте это программой, и наличие только базируется доступ –  SHW 16.12.2013, 11:11
  • 4
    root может отредактировать "другое местоположение" после sudo. –  Has QUIT--Anony-Mousse 16.12.2013, 13:46
  • 5
    Почему Вы ПРЕДОСТАВИЛИ БЫ корневой доступ потенциально злонамеренному пользователю??? Как корень, это тривиально для установки черного хода, который не зависит от прохождения через sudo и/или обертки... –  alexis 16.12.2013, 22:34

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

7
27.01.2020, 19:31
  • 1
    Это было бы более безопасно, чем многие опции IMHO. –  Elder Geek 11.04.2015, 05:26

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

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

11
27.01.2020, 19:31
  • 1
    В то время как выполнение этого с маем SELinux в теории быть возможным (и я не убежден), утверждая, что это, не показывая фактические правила, не собирается помогать любому. –  Gilles 'SO- stop being evil' 17.12.2013, 00:00
  • 2
    @Gilles хорошо на самом деле, это - то, для чего был разработан SELinux. SELinux является слоем полномочий, требуемых в дополнение к стандартным полномочиям POSIX. На правильно настроенной машине SELinux корневой доступ бессмыслен, так как Ваши истинные полномочия определяются контекстом защиты и объектной маркировкой. –  tylerl 21.12.2013, 19:51
  • 3
    Если Вы знаете, как сделать это, ответьте на Миф или действительность: SELinux может ограничить пользователя root? –  Gilles 'SO- stop being evil' 26.12.2013, 00:52
  • 4
    Теоретически, это может все еще быть выполнимо с SELinux; однако, установка чего-то как этот должна была бы быть более сложной, для обеспечения устойчивого разделения для ВСЕХ SELinux-связанных файлов конфигурации от "нормальной" файловой системы (к который root у пользователя есть полный доступ). В конце "самый легкий" метод для такого разделения (с или без SELinux) должен был бы пойти с чем-то как Kerberos, как упомянуто Joseph R. –  ILMostro_7 14.10.2014, 12:12

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

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

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

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

11
27.01.2020, 19:31

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

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

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

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

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

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

17
27.01.2020, 19:31
  • 1
    Ethernet, Это на самом деле не предотвращает пользователя toor от изменения пароля root; это только обеспечивает второй пароль для становления корнем с. –  alexis 16.12.2013, 14:30
  • 2
    1, затем. Вы предлагаете закулисный пароль так, чтобы администраторы могли восстановить корневой доступ после того, как они теряют его??? Это является просто заблуждающимся, и помимо противных пользователей мог легко отключить его, как Вы говорите. Существуют намного более надежные способы настроить бэкдор. –  alexis 16.12.2013, 16:03
  • 3
    @alexis, Именно это, по моему скромному мнению, попросил автор вопроса. Почему дают-1 для этого? toor учетные записи восстановления были общей практикой (хотя осуждено) на Unix в течение многих десятилетий. –  Has QUIT--Anony-Mousse 16.12.2013, 19:08
  • 4
    Если единственная цель состоит в том, чтобы предотвратить против случайных изменений пароля, это - хороший ответ. Если цель состоит в том, чтобы предотвратить что-либо злонамеренное, это не много справки. Так как OP не сказал, какова цель была, мы не знаем. –  Bobson 16.12.2013, 19:18
  • 5
    Который является, почему я заявил что в своем первом предложении: "винты... кроме этого, Вы доверяете... полностью". Это - действительно только решение "для доступа к поддержке"; не средство защиты. Используя дополнительный корень ssh ключи достигает того же, не будучи hackish. –  Has QUIT--Anony-Mousse 17.12.2013, 10:47

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

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

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


Обновление

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

Я заключаю соответствующие части в кавычки:

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

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

92
27.01.2020, 19:31
  • 1
    Как Вы делали ту прохладную ссылку на комментарий? Я посмотрел на источник для Вашего ответа и видел () окружение его. Охладите секретную шляпу! –  Joe 21.12.2013, 01:24
  • 2
    @Joe время, комментарий был добавлен, является на самом деле ссылкой на сам комментарий. –  Joseph R. 21.12.2013, 01:33
  • 3
    @Joe Находит идентификатор (<tr id="thisistheid"...) к комментарию (например, в Chrome щелкают правой кнопкой и Inspect element), затем добавьте его к ссылке потока с предыдущим #. В Вашем случае (идентификатор = comment-162798) это похоже на это: unix.stackexchange.com/questions/105346 / … –  polym 27.07.2014, 12:53
  • 4
    Спасибо за ответ я не знал, должен ли я принять это или что от @Michael Kjörling, я выбрал его, потому что это имеет больше описания - необходимый новичку как я :) Однако Ваш был также полезен –  244an 14.03.2015, 14:17
  • 5
    @244an Никакие заботы. Я рекомендовал бы то же сам. :) –  Joseph R. 16.03.2015, 10:40

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

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

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

3
27.01.2020, 19:31

Теги

Похожие вопросы