Что именно отличает пользователя root от каждого другого пользователя?

В чем заключаются фундаментальные различия между произвольной учетной записью и root ? Это просто UID что-то отличное от нуля?

Итак, что же делает su бинарий и как он подстраивает пользователя к root? Я знаю, что пользователь должен сначала быть частью группы sudo через то, что мы находим в /etc/sudoers .

 # User privilege specification root ALL=(ALL:ALL) ALL # Members of the admin group may gain root privileges %admin ALL=(ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL 

Взглянув на разрешения su исполняемого файла, мы найдем -rwsr-xr-x или 4755 (т. Е. Setuid установлен).

Является ли это su- бинарным, который читает этот файл конфигурации и проверяет, является ли пользователь, запрашивающий права root, частью любой группы sudo или admin ? Если это так, делает ли бинар порождение другой оболочки как root (учитывая бит setuid ), предполагая, что пользователь является частью ожидаемых групп и знает пароль пользователя, который пытается быть заменен (например, root )?


tl; dr Действительно ли акт повышения привилегий зависит от бита setuid в двоичном файле su или существуют ли другие механизмы для изменения UID текущего процесса? В случае с первым кажется, что только EUID изменится, оставив UID! = EUID. Это проблема?

Как все это эмулируется в среде Android? Насколько я читал, доступ к корню был полностью лишен – хотя процессы все еще работают на этом уровне привилегий.

Если мы удалили sudo и su , этого было бы достаточно, чтобы предотвратить повышение привилегий или Android предпринял дальнейшие шаги?

3 Solutions collect form web for “Что именно отличает пользователя root от каждого другого пользователя?”

Корень пользователя 0

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

Имя пользователя не имеет значения; ядро даже не знает об именах пользователей.

Механизм разрешения Android идентичен на уровне ядра, но совершенно отличается на уровне приложения. У Android есть пользователь root (UID 0), как и любая другая система, основанная на ядре Linux. Android не имеет учетных записей пользователей, хотя и на большинстве настроек не позволяет пользователю (как у человека, работающему и владеющему устройством) выполнять действия в качестве пользователя root. «Корневой» Android – это настройка, которая позволяет владельцу / пользователю устройства выполнять действия с правами root.

Как работает setuid

Исполняемый файл setuid работает как пользователь, которому принадлежит исполняемый файл. Например, su является setuid и принадлежит root, поэтому, когда любой пользователь запускает его, процесс, выполняющийся su запускается как пользователь root. Задача su состоит в том, чтобы проверить, что пользователь, который ее вызывает, разрешает использовать корневую учетную запись, чтобы запустить указанную команду (или оболочку, если не указана команда), если эта проверка завершилась успешно, и выйти, если эта проверка завершилась с ошибкой. Например, su может попросить пользователя доказать, что они знают пароль root.

Более подробно процесс имеет три идентификатора пользователя : действующий UID, который используется для проверок безопасности; реальный UID, который используется в нескольких проверках привилегий, но в основном полезен в качестве резервной копии исходного идентификатора пользователя и сохраненного идентификатора пользователя, который позволяет процессу временно переключать свой эффективный идентификатор пользователя на реальный идентификатор пользователя, а затем вернуться к прежний эффективный UID (это полезно, например, когда программе setuid необходимо получить доступ к файлу в качестве исходного пользователя). Запуск исполняемого файла setuid устанавливает действующий UID владельцу исполняемого файла и сохраняет реальный UID.

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

Помимо традиционных Unix

До сих пор я описывал традиционные Unix-системы. Все это верно в современной Linux-системе, но Linux приносит несколько дополнительных осложнений.

Linux имеет систему возможностей . Помните, как я сказал, что в ядре много проверок, где разрешены только процессы с идентификатором пользователя 0? Фактически, каждая проверка получает свои возможности (ну, не совсем, некоторые проверки используют одну и ту же возможность). Например, есть возможность доступа к необработанным сетевым сокетам и еще одна возможность перезагрузки системы. Каждый процесс имеет множество возможностей рядом со своими пользователями и группами. Процесс проходит проверку, если он работает как пользователь 0 или если у него есть возможность, соответствующая проверке. Процесс, требующий определенной привилегии, может выполняться как пользователь без полномочий root, но с необходимой возможностью; это ограничивает воздействие, если процесс имеет отверстие безопасности. Исполняемый файл может быть установлен в одну или несколько возможностей: это похоже на setuid, но работает над возможностями процесса, а не с идентификатором пользователя процесса. Например, для ping нужны только сырые сетевые сокеты, поэтому вместо setuid root может быть установлен CAP_NET_RAW .

Linux имеет несколько модулей безопасности , наиболее известным из которых является SELinux . Модули безопасности вводят дополнительные проверки безопасности, которые могут применяться даже к процессам с правами root. Например, возможно (не просто!) Настроить SELinux, чтобы запустить процесс как идентификатор пользователя 0, но с таким количеством ограничений, что он фактически ничего не может сделать .

Linux имеет пространства имен пользователей . Внутри ядра пользователь фактически не просто идентификатор пользователя, но пара, состоящая из идентификатора пользователя и пространства имен. Пространства имен образуют иерархию: дочернее пространство имен расшифровывает разрешения в своем родителе. Мощным пользователем является пользователь 0 в корневом пространстве имен. Пользователь 0 в пространстве имен имеет полномочия только внутри этого пространства имен. Например, пользователь 0 в пространстве имен пользователя может выдавать себя за любого пользователя этого пространства имен; но извне все процессы в этом пространстве имен работают как один и тот же пользователь.

В Linux есть 4 UID: RUID (реальный), EUID (эффективный), SUID (сохраненный), FSUID (файловая система).

Это не что иное, как числа и свойства процессов, которые хранятся в блоке управления в таблице процессов ядра.

UID '0' имеет специальную характеристику, так как он обозначает root пользователя, который имеет в целом неограниченные права доступа.

su и sudo – программы для изменения прав доступа пользователя, путем запуска нового подпроцесса с установкой EUID на новый UID через бит SetUID от su . Этот процесс su затем снова создает новую оболочку в новом подпроцессе с 4 UID, установленными на новое значение UID.

Следующий пример должен продемонстрировать это, допустим, пользователь rda регистрируется через терминал ssh. ps fax покажет следующие процессы:

 472 ? Ss 0:00 /usr/sbin/sshd -D 9151 ? Ss 0:00 \_ sshd: rda [priv] 9153 ? S 0:00 | \_ sshd: rda@pts/1 9154 pts/1 Ss+ 0:00 | \_ -bash 

4 процесса, демон ssh, два процесса для сеанса ssh (и терминал?), Последний процесс – это оболочка входа (обозначается символом a перед bash )

ps faw -eo euser,ruser,suser,fuser,f,comm покажут UID процессов:

 EUSER RUSER SUSER FUSER F COMMAND ... root root root root 4 sshd root root root root 4 \_ sshd rda rda rda rda 5 | \_ sshd rda rda rda rda 0 | \_ bash 

Вызов su за которым следует успешная аутентификация, приведет к следующему:

 EUSER RUSER SUSER FUSER F COMMAND ... root root root root 4 sshd root root root root 4 \_ sshd rda rda rda rda 5 | \_ sshd rda rda rda rda 0 | \_ bash root rda root root 4 | \_ su root root root root 4 | \_ bash 

Процесс «bash» запускает новый дочерний процесс su, с EUID, установленным битом SetUID, на '0' (root), RUID по-прежнему настроен на UID rda в этой точке. Процесс «su» снова запускает новый дочерний процесс с новой оболочкой, предоставляя пользователю root-доступ (теперь у RUID установлено значение '0' ). Пользователь остается в своем рабочем каталоге, а новая оболочка будет использовать ту же среду, что и родительская оболочка, например:

 server:/home/rda# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin server:/home/rda# pwd /home/rda 

Оболочку можно закрыть с exit и пользователь будет в родительской оболочке с его исходными правами доступа.

Ситуация другая, если «su» вызывается с дефисным параметром '-' :

 rda@server:~$ su - Password: server:~# echo $PATH /root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin server:~# pwd /root 

Среда оболочки изменилась, так как новая оболочка является оболочкой входа в систему, см. '-su' , которая выполняет некоторые дополнительные скрипты конфигурации:

  9151 ? Ss 0:00 \_ sshd: rda [priv] 9153 ? S 0:00 | \_ sshd: rda@pts/1 9154 pts/1 Ss 0:00 | \_ -bash 9613 pts/1 S 0:00 | \_ su - 9614 pts/1 S+ 0:00 | \_ -su 

Оболочку входа следует закрыть с logout .

Теоретически, я думаю, что можно запретить пользователю получать повышенные привилегии, удаляя sudo и su и не дает возможности входа в систему напрямую (через терминал, ssh и т. Д.) И без физического доступа к устройству.

Обновление: процесс Rooting на Android

Как подробно объяснено здесь , возможные способы укоренения устройства Android зависят от загрузчика и системного свойства Android ro.secure .

Цель всегда одна и та же, чтобы установить su bin в /system и сделать setuid(0) .

Устройство с разблокированным загрузчиком:

Вытащите ПЗУ с dd из устройства, добавьте su , переупаковку (или загрузите такое модифицированное ПЗУ), перезагрузите устройство в режиме вспышки и запустите модифицированное ПЗУ.

Устройство с ro.secure = 0 :

Это системное свойство управляет командами wether, введенными в adb shell , запускаются как root ( ro.secure=0 ) или как непривилегированный пользователь ( ro.secure=1 ). Значение ro.secure устанавливается во время загрузки по default.prop в root каталоге, который доступен только пользователю root и, таким образом, безопасен.

В большинстве случаев это ro.secure имеет значение 1 , но некоторые производители устанавливают значение 0 . Это можно проверить, запустив getprop ro.secure в эмуляторе терминала на устройстве или в оболочке adb. Если он установлен в 0 , укоренение довольно простое, подключите его к компьютеру, запустите adb , mount /system как read-write, install su .

Устройство с заблокированным загрузчиком:

Такое устройство имеет восстановление, которое не позволяет мигать пользовательским ПЗУ, который не был подписан производителем. Единственный способ получить root-доступ в этой ситуации – это использование уязвимости безопасности в одном из запущенных системных процессов, которые выполняются в привилегированном режиме, и взломать его, чтобы разрешить выполнение «условного кода». Этот код обычно монтирует /system и устанавливает его навсегда.

В общем, это просто, что эффективный uid равен 0. бит «setuid» на исполняемых файлах фактически устанавливает эффективный uid процесса. Если эффективный uid не равен нулю, а действительный uid не равен нулю, программа работает как «непривилегированный» пользователь. Применимы следующие правила:

Непривилегированные процессы могут устанавливать только эффективный идентификатор пользователя для реального идентификатора пользователя, эффективного идентификатора пользователя или сохраненного идентификатора set-user-ID. Непривилегированные пользователи могут устанавливать реальный идентификатор пользователя только для реального идентификатора пользователя или для эффективного идентификатора пользователя.

Что касается Android, то нет, я не думаю, что удаление sudo и su достаточно – если какая-либо программа может иметь установленный бит seteuid, эта программа может запускаться с uid = 0. Если есть какая-либо возможность иметь доступ во внутреннюю файловую систему как root в любое время, тогда такая программа может быть введена и возможен доступ root.

  • В чем разница между sudo su и just su?
  • Есть ли веская причина для запуска sudo su?
  • ssh master - выполнить su удаленно
  • Ошеломление задержки аутентификации при неудачных `su` или` sudo`
  • SSH с su и удаленной командой с использованием -c и запуска нескольких команд с параметрами
  • как использовать другую оболочку при изменении на root
  • Неправильное разрешение на папку / etc
  • Su -c не работает и игнорируется
  • Сохранение текущего стиля командной строки после использования 'su?'
  • Разница между sudo su - пользователем и пользователем sudo -iu
  • rsync как другой пользователь
  • Interesting Posts
    Linux и Unix - лучшая ОС в мире.