Как sudo/root-ness обнаружение работает

Это не функция в less, но это - полезная функция.

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

Так, я считал информацию (1) использование страниц less вместо этого. Следующая команда распечатает информацию (1) страницы, с помощью знакомого интерфейса меньше!

info gpg |less

5
27.07.2011, 18:19
5 ответов

Имена пользователей на Unix не являются значительными. Только числовые идентификаторы пользователей. Числовой идентификатор корня всегда 0. Это трудно кодируется повсеместно (в ядре, в утилитах, и т.д.).

Можно найти числовой идентификатор пользователя путем выполнения id.

Обратите внимание, что Ваш числовой идентификатор пользователя является свойством рабочего процесса. Когда Вы входите в систему, процесс, Вы входите в систему через (login, sshd, и т.д.), работает как корень (UID 0), и после того как Ваш вход в систему авторизовывается, он переключается на Ваш идентификатор пользователя и выполняет Вашу оболочку (указанный в/etc/passwd). Оттуда, для использования sudo, su, или что-то еще для переключения идентификаторов пользователей те программы имеют setuid набор битов (chmod u+s или chmod 4xxx установит это), так, чтобы, когда они выполнятся, выполнения процесса как владелец программы (корень, UID 0). Снова, после того как Вы авторизовываетесь, они запускают любую программу (независимо от того, что Вы сказали sudo работать, оболочка, и т.д.) как корень. (В su случай при определении другого пользователя для переключения на, это спадает до того UID, затем выполняет оболочку или что бы то ни было.)

Для ответа на другой вопрос нет действительно никакого пути к корневой учетной записи, которая "будет повреждена", так как это действительно - просто число, но могли бы быть причины, почему Вы не можете только войти в систему как корень (как упущение пароля, например). Ни один из них не должен требовать переустанавливания ОС, но они могли бы потребовать, чтобы немного технического навыка зафиксировало. (Например, если Вы забываете пароль root, можно использовать sudo для получения для укоренения при помощи пароля, начальной загрузки в однопользовательский режим для изменения пароля или начальной загрузки от живых медиа или спасательной среды.)

11
27.01.2020, 20:31
  • 1
    Право, я не ожидал, что это на самом деле проверит имя, ха-ха. Но затем что относительно второй части моего вопроса: что, если это повреждается? Там никакой путь не состоит в том, чтобы заставить другого пользователя иметь идентификатор 0? –  user541686 27.07.2011, 18:38
  • 2
    После того, как я отправил свой ответ, я понял, что не обратился к этому, таким образом, я развернул свой ответ немного. :-) –  Steven Pritchard 27.07.2011, 18:53
  • 3
    , Спасибо! +1, Таким образом, там не похож ни на что, например, реестр Windows, который мог быть "поврежден" на Linux, препятствуя тому, чтобы учетная запись использовалась постоянно? –  user541686 27.07.2011, 18:58

За 25 лет контакта с Unix я никогда не видел случай, где корневая учетная запись была повреждена без самой системы, являющейся применимым. Забытые пароли могут легко быть сброшены, и я не рассматриваю что как повреждение. Был один незабываемый инцидент на Vax, выполняющем BSD, куда я случайно (не спрашивают) удалил все из/dev, включая записи для ленточного накопителя (1/4-дюймовые ленты барабана). Это делает его немного трудно для восстановления от резервного копирования.

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

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

4
27.01.2020, 20:31
  • 1
    "У Вас может быть несколько учетных записей, что у всех есть uid 0".-> СТОП, как?? –  user541686 27.07.2011, 19:06
  • 2
    @Mehrdad - Большинство систем позволяет Вам указывать uid при добавлении нового пользователя. Просто укажите uid 0, и у Вас есть другой пользователь root. –  KeithB 27.07.2011, 19:14
  • 3
    +1 я собираюсь, должен попробовать это. Просто удивление, хотя: Если это - идентификатор пользователя, то, как это не действительно идентификатор? –  user541686 27.07.2011, 19:15
  • 4
    Снова, только числовые идентификаторы являются значительными. Имена пользователей больше для нашего удобства, чем что-либо еще. Они просто отображаются на числовом идентификаторе (в/etc/passwd, NIS, LDAP, и т.д.). –  Steven Pritchard 27.07.2011, 19:41
  • 5
    Пример того, как это полезно, - то, что некоторым людям нравится создавать 2-ю корневую учетную запись с другим именем (toor, распространено), и точно как нормальная корневая учетная запись кроме него имеет другую оболочку входа в систему. Таким образом, у них есть корневая учетная запись с оболочкой входа в систему, которую они хотят, не изменяя корневую оболочку входа в систему учетных записей и возможные проблемы порождения. –  Arrowmaster 27.07.2011, 20:51

Ответ Steven Pritchard хорош, но я думал, что предложу другую презентацию подобной информации.

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

Когда начальные загрузки системы, первый процесс, запущенный ядром, работают как суперпользователь. Тот процесс, названный init, в конечном счете запускает много системных служб (cron, syslogd, …) и программы входа в систему (login, sshd, и т.д.).

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

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

Программа sudo позволяет Вам команды выполнения как корень. Обычно, если Вы запускаете программу, она наследовала идентификатор пользователя процесса, который запустил ее. Но sudo корень setuid: это - исключение, определенное битами полномочий на /usr/bin/sudo, это заставляет его работать как идентификатор пользователя 0 вместо этого. sudo проверки, позволяется ли пользователь, который вызвал, выполнить команду с поднятыми полномочиями (путем консалтинга /etc/sudoers), и или выполнения команда или сигналы ошибка.

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

3
27.01.2020, 20:31

Таким образом, предыдущие ответы от Steven Pritchard и KeithB корректны, но существует несколько тонкости для знания о том, как идентификатором процесса на самом деле управляют.

Как упомянуто, имя пользователя полностью не важно ядру или любому управлению процессами, и только отображается в пространстве пользователя на основе/etc/passwd или подобных механизмов, поэтому забудьте все об этом. Корень действительно hardcoded и является uid 0 по определению в любой системе POSIX (или что-либо даже удаленно UNIXy, насколько я знаю).

Полномочия вычисляются сделанные на основе свойств в настоящее время процесса выполнения. Существует реальный uid, который является uid пользователя, который запустил процесс и эффективный uid, который является uid, процесс рассматривают что касается целей полномочий. При выполнении вещей от оболочки оболочка является родительским процессом - и дочерние процессы всегда наследовали реальный uid родителя, который является uid, если Вы работаете в оболочке входа в систему. Процессы, для которых включен setuid, могут изменить свой эффективный uid (но никогда свой реальный или сохраненный uid) - процессы, работающие с эффективным uid 0 (как корень), могут измениться на любой другой uid, и другие процессы могут только изменить euid между реальным и сохраненным uid - другое свойство процесса, которое всегда является исходным euid процесса (эквивалентно, эффективный uid родителя в точке, когда exec() был назван). Это не может быть изменено непривилегированными пользователями, и корень может изменить его только на реальный uid.

Все те также важны для полномочий группы, просто s/uid/gid.

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

2
27.01.2020, 20:31

Концепция привилегии «root» распространяется на различные механизмы управления:

  1. Аппаратное обеспечение :ЦП Intel (и все остальные ЦП в целом )имеют различные «привилегированные состояния» -, и в каждом из этих привилегированных состояний вы можете или не можете запускать определенный класс ассемблерных инструкций -в целом более привилегированное состояние будет иметь право выполнять больше инструкций.

https://stackoverflow.com/questions/18717016/what-are-ring-0-and-ring-3-in-the-context-of-operating-systems

https://en.wikipedia.org/wiki/Protection_ring

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

  1. Из (1 )через механизм таблицы страниц у вас также будут различные типы памяти :кольца 0 или кольца 3.

https://en.wikipedia.org/wiki/Kernel_page-table_isolation

https://manybutfinite.com/post/cpu-rings-privilege-and-protection/

Кольцо 0 будет иметь больше привилегий и хранить всю вашу конфиденциальную информацию, -в том числе информацию о вашем USERID. Если у вас userid=0, вы привилегированный, а если нет, то просто обычный пользователь. И у каждого идентификатора пользователя есть разные таблицы страниц в ядре -, поэтому каждый процесс не может напрямую изменять память друг друга. И помните, что идентификатор пользователя хранится в памяти кольца 0 -ваши процессы, работающие в кольце 3, никогда не смогут изменить эту информацию, и если вы можете, то вам, должно быть, удалось перейти в ядро, чтобы изменить ее ("привилегия эскалация» ).

Чтобы проверить, являетесь ли вы пользователем root или нет -root -, сделайте это в ядре:

  if (current_cred()->uid != 0)
     return -EPERM;

А если вы не в ядре -, у вас нет доступа ко всем учетным данным, хранящимся в ядре. И один процесс не может прочитать память другого процесса -, поэтому такая проверка не нужна, если вы не находитесь в ядре, которое может видеть ВСЮ память для всех процессов.

Подводя итог :любые запущенные вами процессы, которые всегда выполняются с привилегией кольца 3 (для Intel ),будет иметь информацию об идентификаторе пользователя, хранящуюся в ядре -, которое должно быть изначально создано из другого компонента ядра или корневого процесса (userid = 0 ). Любой процесс, принадлежащий root -, (, который все еще работает в кольце3 ), будет иметь возможности (, почему? потому что он написан внутри самого исходного кода ядра Linux:

https://stackoverflow.com/questions/15774548/check-for-user-root-within-linux-kernel)для легкого перехода в привилегию кольца 0 . Это объясняет, почему независимо от того, как вы изменяете свою собственную память, (которая работает в кольце 3 ), вы никогда не сможете увидеть/изменить свой идентификатор пользователя.

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

Если вы можете перенести жесткий диск на другую машину , на которой у вас есть root-права, вы можете предположить, что ЛЮБОЙ идентификатор пользователя необходим для чтения физических файлов, принадлежащих этому конкретному пользователю -на жестком диске. т.е., если у вас нет физической защиты, вы можете обойти все механизмы защиты на жестком диске, если только он не зашифрован.

0
27.01.2020, 20:31

Теги

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