Mac OS X не использует стандарт/etc/passwd и/etc/shadow. Вместо этого это использует базу данных. Там используйте, чтобы быть GUI по имени NetInfo, но это было заменено dscl
команда (Командная строка Служб каталогов).
$ dscl
> read /Local/Default/Users/David Password
Password: ********
К сожалению, это о том, насколько я могу добраться с утилитой. Это распечатало звездочки вместо пароля. Возможно, существует способ заставить его бросить хеш, но я не нашел его.
Ее детализация статьи с помощью DSCL и взламывая пароли на Mac.
Мы хотим это, некоторые пользователи должны смочь сделать, например.
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 или иначе.
Один путь состоял бы в том, чтобы гарантировать это /etc
не перезаписываемо. Никем пока мог быть a sudoer
вокруг.
Это могло быть сделано путем монтирования его по сети и гарантировать с другой стороны, что устройство не может быть записано.
Это могло быть сделано при помощи локального устройства, которое предотвращает доступ для записи к нему. (Поиск write blocker
аппаратные средства)
Важная часть - то, что ограничение должно применяться за пределами корневого понятия той машины. Творческий хакер найдет его путь вокруг всех препятствий, которые Вы помещаете в них в среде, которой он мог управлять. Таким образом, если корень мог бы изменить свой пароль, a - также sudoer
.
Быть уверенным, что пользователь также не может завинтить Ваши способности к входу в систему, которые Вы должны иметь только для чтения смонтированный /bin
и /sbin
.
И у Вас должен будет быть сценарий, который периодически восстанавливает сетевое соединение.
(Как заметка на полях: при разрешении sudoer, только очень ограниченный набор команд и для каждого из них защищает это, они не могут убежать из них / заменяют их и т.д., то можно предотвратить его при наличии /etc
перезаписываемый..)
Попытайтесь добавить, что группа колеса вместо того, чтобы использовать 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
sudo
чрезвычайно отличается от su -
. На это неоднократно указывали, например, SHW, Joseph R., самостоятельно, hbdgaf и вполне возможно еще несколько, поле комментария слишком коротко для включения...
– a CVn
17.12.2013, 18:05
Существует корень № 1/2 :) После того как Вы даете полномочия пользователя root, они могут сделать то, что они хотят. Кроме того, можно использовать sudo, чтобы выполнить ограниченную оболочку удара или выполнить rbash без полномочий пользователя root.
Если Вы хотите иметь отказоустойчивый механизм для входа в систему в сервер как корень, можно или создать другого пользователя с uid=0
или создайте простой крон, который будет периодически изменять пароль root.
Можно ограничить доступ к 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
к этому необходимо быть в порядке
Первоначально сформулированный вопрос бесполезен. Похоже, что главная цель, "все еще имеют вход в систему", настолько говорящий о некоторой чрезвычайной ситуации, входят, который продолжает работать наверняка даже с корневым доступом, предоставленным другому человеку. Аплодисменты к Anony-муссу, кто сначала отметил Это явно.
Проблема: Если у владельца есть физический доступ к полю It, может легко восстановить логический доступ к системе (если Это все еще живо:). Если не - сохраняющий пароль root не спасет от, например, sshd вниз или плохая установка сетей, таким образом система все еще не доступна так или иначе.
Тема о том, как препятствовать системе повреждение человеком с административными привилегиями, кажется слишком широкой для установки формату вопроса SE.
Разговор об удаленной чрезвычайной ситуации вводит решение, лучшим способом является IPMI (я думаю), если Это доступно. Системный владелец может виртуальный диск атташе в любое время, начальная загрузка от Него и procced с системным восстановлением.
Если IPMI не доступен, любая подходящая технология виртуализации может, чтобы быть обходным решением, как были уже предложены выше.
При клонировании сервера в VM (такой как VirtualBox), можно предоставить освобожденный корневой доступ к людям и все еще гарантировать, что Вы будете всегда иметь прямой доступ к разделу (разделам) гостевой операционной системы и поэтому обеспечивать заключительный контроль /etc/passwd
и т.п., так как у Вас будет корень в хост-системе.
Конечно, предоставление освобожденного корневого доступа все еще не может быть правильным решением: если безопасность данных является во всем проблемой или Вашей ответственностью, Вы не можете предоставить корневой доступ далеко.
Ваше требование:
У нас есть немного проблемы на сервере [...] то есть, гарантия, что мы все еще можем войти в тот сервер и стать корнем, неважно, того, что сделают другие пользователи.
От Вашего вопроса кажется, как будто Вы не сталкиваетесь со случайным намерением злонамеренных пользователей уничтожения Вашей системы, но вместо этого имеете полудоверяемых пользователей, которые могут вызвать вред время от времени (студенты, возможно?). Мои предложения обращаются к той ситуации, не всеобщему нападению злонамеренными пользователями.
Выполните сервер в виртуальной среде. Вы сможете смонтировать файловую систему сервера, и замена изменила файлы с известным - хорошие версии. В зависимости от возможного повреждения Вы ожидаете, Вы могли взять снимок всех критических каталогов (/мусорное ведро,/sbin, / и т.д.,/usr, / var, и т.д.) и развернуть снимок для перезаписи поврежденных файлов при оставлении остальной части системы неповрежденной.
Выполните систему, только для чтения, например, от DVD-R. Если можно жить с большинством частей системы, являющейся статичным до следующей перезагрузки, это - хороший вариант. Вы могли также использовать запоминающее устройство только для чтения с виртуальной средой или загрузить основную систему по сети, делая изменения между перезагрузками намного легче, чем запись нового DVD-R.
Модули ядра. Модули безопасности Linux (LSM) ядра обеспечивают основание для создания безопасных модулей. LSM используется SELinux, но также используется многими менее известными и более простыми системами, такими как Вкус, TOMOYO и AppArmor. Эта статья имеет хороший обзор опций. Возможности являются одним из тех, может быть настроен out-of-the-box для предотвращения доступа для записи к/etc/passwd,/etc/shadow, или любого другого файла (файлов), который Вы хотите, даже корнем.
Та же идея как № 1, но когда сервер не находится в виртуальной среде. У Вас могла быть цепочечная загрузка сервера в ОС только для чтения, такую как живой CD, который автоматически смонтирует файловую систему сервера и перезапишет основную систему на каждой начальной загрузке с известным - хорошие копии. ОС только для чтения затем загрузилась бы в основную ОС.
Снова, принятие их является полудоверяемыми пользователями, которые ответственны перед большой шишкой (учитель/босс), лучший ответ может быть Аудитом Linux. Таким образом, Вы будете знать каждые принятые меры, важные для безопасности, и кто взял их (Вы будете знать, кто взял их, потому что, даже если все пользователи совместно используют корневую учетную запись, у них будет sudo'ed от их учетной записи пользователя сначала). На самом деле Вы могли бы даже смочь проанализировать контрольный журнал в в реальном времени, и замена повредила файлы./etc/shadow перезаписывается? Без проблем, просто имейте контролирующий сервер, немедленно заменяют его известным - хорошая версия.
Другие технологии можно хотеть заняться расследованиями на основе потребностей:
Требование не технически возможно. Как уже красноречиво прокомментировано, предоставляя неограниченный или еще более ограниченный sudo
права пользователю означают доверие тому пользователю. Кто-то имеющий злые намерения и достаточно технической способности и настойчивости может пройти любые препятствия, которые помещаются на месте.
Однако принятие Вас может доверять Вашим пользователям, чтобы не быть злым умышленным, можно сделать ограничение на пароль, изменяющий вопрос политики. Можно создать обертку для passwd
программа, которая напомнит им, "не изменяет пароль root". Это предполагает, что источник проблемы - то, что пользователи, которые изменяют пароль root, делают его из-за недоразумения (как, возможно, размышление, что они изменяют свой собственный пароль, сделав sudo bash
).
При специальных (редких) обстоятельствах, если полное доверие не возможно и не возможно повредиться sudo
доступ к соответствующим но довольно безопасным блокам, Вы могли бы рассмотреть устанавливающие организационные санкции против изменения пароля (или любая другая указанная форма системного вмешательства), контроль расположения дефицитных ресурсов так, чтобы не было легко пойти необнаруженное, чтобы обойти политики набора - и быть общедоступным и быть прозрачным о правилах использования и контроле.
Аспектом контроля и исследования является трудная техническая проблема, извлекающая выгоду из другого вопроса, должен Вы принимать решение обойти тот путь. Это кажется мне, мы должны были бы
Мы должны были бы, по крайней мере, зарегистрировать открытие кроме безопасного набора файлов для записи, создания процесса, exec()
, и конечно любая попытка изменить сети.
Реализация могла быть сделана измененным libc или (намного лучшей) трассировкой системного вызова.
Конечно, невозможно сделать такую трассировку и вход работы 100% правильно, не легко реализовать, и это также требует, чтобы дополнительные ресурсы работали. Это не остановило бы изменение пароля или другое нежелательное системное вмешательство, но оно сделает (более вероятно) возможным найти виновного пользователя или по крайней мере создать иллюзию, что там контролирует, и сделайте его, менее приглашение на некоторое зло возражало против пользователей (но некоторая проблема, любя хакеров, которые видят, что фундаментальная тщетность технических мер, помещенных на месте, могла бы чувствовать себя поощренной охватить проблему и попытаться обойти систему просто ради удовольствия).
Оператор это 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, это может быть и используется для управления доступом к определенным командам намного большим количеством детализированного способа.
sudo vi
доступ к пользователю, потому что я хочу, чтобы они смогли отредактировать файлы конфигурации системы. Тот пользователь затем делает :!/bin/bash
внутри a sudo vi
сессия. Как делает способность sudo ограничить то, что управляет, чтобы пользователь мог выполниться через справку sudo защитить мою систему при тех обстоятельствах? (Никто не сказал, что sudo не может быть настроен более плотно, чем бескомпромиссное sudo -i
подход.)
– a CVn
16.12.2013, 11:09
sudoedit
. Можно конкретно определить, какие файлы они должны смочь sudoedit
. Это находится в man sudoers
.
– Matthew Flaschen
17.12.2013, 07:09
Для дополнения других ответов я собираюсь предположить, что сценарий - то, что Вы чувствуете теряющий контроль над корнем редкая ситуация, и что в тех случаях перезагрузка сервера позволяется. (В конце концов, если Вы будете полагать, что машина была поставлена под угрозу, то Вы захотите вывести ее из эксплуатации так или иначе.)
Большое преимущество этого состоит в том, что нет ничего для конфигурирования. Ваш вопрос становится: "Я забыл пароль root, как я возвращаюсь в?" И ответ на это должен перезагрузить и выбрать однопользовательский режим, когда машина подходит. Это дает Вам корневую оболочку, не будучи должен знать пароль. В той точке можно установить новый пароль. (А также пойдите и возместите любые убытки...),
init=...
подход может быть предотвращен, удалив, выполняют полномочия от подходящих двоичных файлов. Я думаю лучшее решение в этом случае, должен смонтировать Вашу корневую файловую систему через LiveCD, и (попробуйте к), фиксируют повреждение. С другой стороны, если Вы полагаете, что система была поставлена под угрозу, Вы - более обеспеченное восстановление от резервного копирования так или иначе.
– Joseph R.
17.12.2013, 01:46
Я не знаю, что это будет практически выполнимо, но здесь является одним грязным взломом:
/etc/passwd
файл к некоторому другому местоположению, прежде, чем назвать фактическим sudo
sudo
/etc/passwd
файлЯ знаю, существует партия плюс - минус вещи, которые необходимо рассмотреть для достижения этого. В конце концов, это - грязный взлом
root
может отредактировать "другое местоположение" после sudo
.
– Has QUIT--Anony-Mousse
16.12.2013, 13:46
Возможно, необходимо рассмотреть разрешение пользователям иметь корневой доступ к контейнеру LXC или виртуальной машине. Это позволило бы им иметь полный корневой доступ к системе, не позволяя им препятствовать тому, чтобы Вы вошли в хост или приняли административные меры.
Это, вероятно, возможно, по крайней мере, в теории, чтобы сделать это использование SELinux. Это позволяет Вам настраивать намного более точные правила о том, что пользователь или процесс или не разрешены сделать. Даже с SELinux, это может быть хитро, чтобы лишить возможности пользователя изменять пароль root, но все еще способный сделать независимо от того, что они, возможно, должны сделать.
Действительно это зависит от того, что пользователь, которому не разрешают изменить пароль root на самом деле, должен смочь сделать. Это, вероятно, было бы легче и более безопасным просто разработать то, что то есть, и дают те разрешения конкретно с помощью sudo.
root
у пользователя есть полный доступ). В конце "самый легкий" метод для такого разделения (с или без SELinux) должен был бы пойти с чем-то как Kerberos, как упомянуто Joseph R.
– ILMostro_7
14.10.2014, 12:12
Сущность корня состоит в том, чтобы иметь неограниченную команду системы. Вы могли настроить его с SELinux (раньше было демонстрационным сайтом, где любой мог войти в систему как корень, но его питанию нанесли вред через систему доступа), но это не точка. Дело в том, что это - неверное решение Вашей проблемы.
Теперь, Вы не сказали, какова Ваша проблема, но если Вы не доверяете этим пользователям, чтобы не приближаться к паролю root, у них нет бизнеса, являющегося корнем. Если они должны администрировать веб-сервер, или различные устройства или диск деформации или что бы то ни было, настраивают решение для этого. Создайте суперприводимую в действие группу, предоставьте всему этому доступ, в котором это нуждается, и добавьте их к нему. Если они должны выполнить системные вызовы только для корня, запишите некоторые setuid программы.
Конечно, пользователь с таким доступом (и немного знания) мог, вероятно, легко взломать систему, но по крайней мере Вы работаете с моделью защиты ОС, не против него.
PS. Существует много способов расположить корневой доступ для себя без пароля; для одного, если Вы находитесь в /etc/sudoers
(без ограничений), Вам только нужен Ваш собственный пароль для становления корнем, например, с sudo bash
. Но Вы просто не должны должны быть идти туда.
Я предполагаю, что Вы хотите удостовериться, что у Вас есть "чрезвычайный администратор" доступ, даже если Ваш фактический администратор завинчивает (но кроме этого, Вы доверяете основному администратору полностью).
Популярный подход (хотя очень hackish) должен иметь второго пользователя с uid=0
, обычно называемый toor
(базируйтесь назад). Это имеет другой пароль и может служить резервным доступом. Для добавления необходимо будет, вероятно, отредактировать /etc/passwd
и /etc/shadow
(скопируйте root
строки).
Это почти отказоустойчиво, но если просто необходимо охранять против "основного администратора" изменение пароля без уведомления, затем это будет работать. Это тривиально для отключения путем удаления toor
учетная запись; таким образом, единственное преимущество имеет отдельный пароль.
С другой стороны, можно хотеть изучить альтернативные механизмы аутентификации, т.е. ssh
ключи, libnss-extrausers
, LDAP и т.д.
Обратите внимание, что администратор может все еще завинтить плохо. Например, путем блокирования брандмауэра.
Если Вы хотите иметь очень защищенную систему, рассмотреть использование SELinux, где пользователь UNIX (например, корень) также идет с ролью, которая может быть намного более мелкомодульной. Можно хотеть предоставить администраторский корневой доступ, но только ограниченную роль (например, управлять только апачем). Но это потребует, чтобы довольно большое усилие на Вашей стороне правильно настроило политику.
toor
от изменения пароля root; это только обеспечивает второй пароль для становления корнем с.
– alexis
16.12.2013, 14:30
toor
учетные записи восстановления были общей практикой (хотя осуждено) на Unix в течение многих десятилетий.
– Has QUIT--Anony-Mousse
16.12.2013, 19:08
Это практически невозможно. В первую очередь, если Вы предоставляете им питание становления корнем, затем нет ничего, что можно сделать, чтобы препятствовать тому, чтобы они делали что-либо. В Вашем варианте использования, 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 для меня.
<tr id="thisistheid"...
) к комментарию (например, в Chrome щелкают правой кнопкой и Inspect element
), затем добавьте его к ссылке потока с предыдущим #
. В Вашем случае (идентификатор = comment-162798
) это похоже на это: unix.stackexchange.com/questions/105346 / …
– polym
27.07.2014, 12:53
(Я не знаю человечности, но это должно быть подобно Fedora/Red-Hat),
Единственная вещь я могу предположить ограничивать доступ к изменению пароля root, не предоставляет полный корневой доступ, возможно, с sudo, или использует SElinux для ограничения доступа к файлу паролей..., но я не доверил бы или много доступа, поскольку корень обычно имеет неограниченный доступ и мог обновить SElinux, или повторно маркировать файл паролей или запустить некоторую pre-prepred программу для изменения пароля.
Если Вы не доверяете им достаточно для не изменения пароля, Вы, вероятно, не должны предоставлять им корневой доступ. Иначе я предположил бы, что Вы стараетесь избегать несчастных случаев.
Если Вы только пытаетесь защитить свой доступ к корню, установить программу, которая может восстановить пароль root, поэтому даже если это изменилось, это может быть восстановлено с минимальным доступом. (sudo преуспевает на своем собственном),
:)
– a CVn 17.12.2013, 13:55