Журнал LinuxFormat - перейти на главную

LXF148:Sysadmin

Материал из Linuxformat
(Различия между версиями)
Перейти к: навигация, поиск
(Новая страница: «==По рецептам доктора Брауна== : Доктор обучает, пишет и консультирует по Linux. Ученая степе…»)
 

Текущая версия на 18:03, 21 июля 2014

Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

[править] По рецептам доктора Брауна

Доктор обучает, пишет и консультирует по Linux. Ученая степень по физике элементарных частиц ему в этом совсем не помогает.


(thumbnail)
«Режим» файла состоит из девяти хорошо знакомых нам битов «прав» и трёх других битов. Ключевой бит в повышении привилегий — setuid.

[править] Вступаем в будущее

Сотни сайтов приняли участие во Всемирном дне IPv6.

8 июня был Всемирным днем IPv6. А вы, верно, и не заметили. На самом деле, так и было задумано, что вы не заметите. На 24 часа несколько сотен сайтов, включая Google, Facebook и YouTube, перешли в режим работы «с двойным стеком» (IPv4 + IPv6) на своих обычных адресах.

Многие сайты уже предоставляют доступ по IPV6, но на других URL. Например, записи DNS AAAA (адреса IPV6) можно в любой день найти для адреса ipv6.google.com, но не для google.com. В День IPV6 все было иначе. Большинство компьютеров ничего не ощутили – они либо проигнорировали записи AAAA (по причине отсутствия подключения по IPV6), либо вообще их не увидели.

Ожидалось, что неприятности возникнут лишь у малой части пользователей (около 0,2 %). Это сайты, которые, получив адрес IPV6, возвращенный DNS, решали предпочесть его адресу IPV4, хотя и не имели подключения по IPV6, или пытались использовать туннельное решение IPV6 вроде Teredo, инкапсулирующего датаграммы IPV6 внутрь датаграмм IPV4. При этом сильно тормозится работа в Интернет, так как компьютеры сначала ждут тайм-аута на несуществующем соединении IPV6, а уж потом пробуют IPV4.

Цель Дня IPV6 частично состояла в том, чтобы помочь засечь эти неправильно настроенные сайты, а частично – чтобы мотивировать провайдеров, изготовителей устройств и разработчиков ОС более быстрыми темпами продвигать обеспечение полной сквозной совместимости с IPV6.

Экранный снимок сайта RIPE NCC показывает, как все изменилось в день IPV6, хотя здесь требуется пояснение. Зеленые и синие полоски означают, указывал ли сайт (или нет) адреса IPV6. На временной (горизонтальной) оси ясно виден 24-часовой период в середине, когда все более или менее позеленело. Лично я считаю это волнующим предвестником будущего. Надеюсь, интернет-пользователям на 99,9 % будет все равно.

Более подробные графики и статистику о Всемирном дне IPV6 см. на http://v6day.ripe.net.


[править] Обновление первого ранга

Когда вам не обойтись без полномочий администратора, на помощь приходит эскалация привилегий. Узнайте, как это работает.

Каждый процесс в Linux, т. е. каждая утилита командной строки, каждое приложение рабочего стола, каждый сервис запускается с особым «идентификатором пользователя», называемым UID. У настоящих пользователей (т. е. живых людей) есть UID; также имеются «системные» учетные записи с UID, которые предоставляют идентификаторы для запуска с ними процессов вроде Apache или Postfix.

В большинстве дистрибутивов устанавливается «порог» UID: если значение UID меньше него, то он системный, а если больше – пользовательский. В дистрибутивах на базе Red Hat этот порог установлен в 500, в Debian – в 1000. Порог не имеет реального значения для привилегий, предоставляемых учетной записи.

Ну и, разумеется, есть учетная запись с особыми привилегиями, обычно называемая root – с UID, равным 0.

При входе в Linux по логину и паролю пользователя определяется его UID, и обычно все программы, которые он запускает, наследуют этот UID.

Именно UID используется для принятия решений по управлению доступом. Чаще всего решение принимает ядро: может ли Мэри запустить ту или иную программу или записать в тот файл?

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

[править] Повышение по службе

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

Напыщенно это называется «эскалацией привилегий». Примеры подобных ситуаций – изменение пароля (включая запись свертки нового пароля в теневой файл) либо монтирование съемного устройства (это привилегированная операция, доступная только root).

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

Другие программы делают процесс повышения привилегий более явным и иногда более длительным. Классическая утилита командной строки, используемая для этих целей – su (substitute user – заменить пользователя). Она запускает новую оболочку с новым идентификатором пользователя. Самая распространенная форма ее запуска выглядит так: 

chris@m1530-1004:~$ id
uid=1000(chris) gid=1000(chris) groups=119(admin),1000(chris)
chris@m1530-1004:~$ su -
Password:
root@m1530-1004:~# id
uid=0(root) gid=0(root) groups=0(root)
root@m1530-1004:~#

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

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

Можно переключиться и на другого пользователя, не root, хотя это менее распространенный вариант: 

$ su - fred
Password:
$

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

Переменная окружения PATH (она задает путь поиска для исполняемых команд) – пожалуй, самая важная из этих настроек.

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

chris@m1530-1004:~$ su -c ‘date 06021012’
Password:
Thu Jun 2 10:12:00 BST 2011

Другая популярная команда, повышающая привилегии – sudo. Sudo применяется для запуска команды от имени другого пользователя (опять же, обычно это root). Ее настройки лежат в файле /etc/sudoers, который тщательно контролирует, какие команды каждый пользователь может запускать подобным образом.

На все подробности здесь нет места; если вам интересно, загляните в man sudoers. В своей конфигурации по умолчанию Ubuntu в значительной мере полагается на sudo. Вход в систему под пользователем root отключен совсем. Вместо этого учетная запись, создаваемая при установке Ubuntu, делается членом группы ‘admin’, и sudo настраивается так, чтобы члены этой группы могли запускать любые команды от имени root. Вот как я повышаю свои привилегии с помощью sudo для установки нового пакета: 

$ sudo apt-get install abiword
[sudo] password for chris:
... and so on ...

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

Реальный UID – это пользователь, кем вы являетесь на самом деле, а действующий UID – тот пользователь, для которого проверяются права на управление доступом, т. е. права, на которые вы покусились.

Обычно эти идентификаторы одинаковы, но при запуске программы, у которой установлен бит ‘set user ID’ [задать идентификатор пользователя], действующий UID становится равным UID владельца исполняемого файла.


[править] Хранение файлов

Бит setuid – один из трех особых битов в «режиме» файла. Нижние девять бит режима доступа – это три набора прав доступа ‘rwx’, которые вам наверняка знакомы, а следующие три бита описаны в таблице внизу.

Биты setuid можно увидеть, внимательно расмотрев вывод команды ls -l. Например: 

$ ls -l /bin/su
-rwsr-xr-x 1 root root 36864 2011-02-14 22:11 /bin/su

Обратите внимание на s, третью букву в правах доступа, где обычно располагалось бы «право исполнения для пользователя».

Так как владельцем файла в данном случае является root, этот бит говорит, что нужно «установить setuid в root». Вы увидите, что владельцем большинства программ с установленным setuid в системе является root. Найти эти файлы по режиму доступа можно командой 

# find / -perm +4000 -ls 2> /dev/null

В Ubuntu 10.04 эта команда обнаружила 36 программ с setuid (владельцем 34 из которых являлся root). В Fedora 15 я нашел 28.

Механизм set-user-id – основа повышения привилегий в Linux. Автор этой идеи – Деннис Ритчи [Dennis Ritchie], один из отцов-основателей Unix, и в 1973 году он зарегистрировал на нее патент (US Patent 4,135,240), хотя отнюдь не ради получения авторских отчислений.

Патент был выдан в 1979 году, что, между прочим, дает представление о том, как медленно работает бюро патентов США.

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

Юные историки могут отправиться по ссылке http://www.wikipatents.com/US-Patent-4135240/protection-ofdata-file-contents.

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

Хороший пример – почтовая программа Postfix, написанная гуру безопасности Виетсе Венема [Wietse Venema]. Postfix намеренно разбита на несколько исполняемых файлов, и каждый из них запускается с минимально необходимыми привилегиями. Вот пример из Fedora 15: 

$ ls -l /usr/sbin/postdrop
-rwxr-sr-x. 1 root postdrop 187144 Mar 23 18:52 /usr/sbin/postdrop

Здесь postdrop использует механизм setgid, чтобы получить возможность записывать в каталог очереди приема почты (в данном случае /var/spool/postfix/maildrop). Я собирался написать «setgid используется значительно реже, чем setuid», но экспресс-проверка показала, что я неправ. Я насчитал 14 таких программ.

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

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

Однако импорт файлов с setuid на съемный диск чреват проблемами, потому что монтировать съемные диски, как правило, могут и обычные пользователи.

[править] Шалунья Сьюзан

Представьте себе такую ситуацию: в офисе Сьюзан вставляет USB-флэшку в свой компьютер (к которому у нее есть root-доступ) и копирует на него исполняемый файл оболочки Bash.

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

Я отхожу от своего компьютера, а она вставляет в него USB-флэшку, монтирует ее и запускает свою оболочку от имени root. Шалунья Сьюзан.

На практике у нее бы возникли препятствия, так как в большинстве систем съемные диски монтируется с опцией nosuid, то есть бит setuid не будет учитываться для файлов на этом устройстве (взгляните на опции owner, user и nosuid на man-странице команды mount).

Натянув свой колпак безопасности потуже, я призываю вас рассмотреть эту ситуацию в перспективе. При наличии физического доступа к моему компьютеру, у Сьюзан хватает и других вариантов урвать права root – иногда достаточно загрузки в режиме одного пользователя; если это не сработает, она может загрузиться с liveCD и смонтировать файловые системы на моем жестком диске, или, в порядке крайней меры, просто открутить и утащить мой жесткий диск. Физическая безопасность компьютера важна.


[править] Биты «режима» файла

БИТ ВОСЬМЕРИЧНОЕ ЗНАЧЕНИЕ ЧТО ОН ДЕЛАЕТ
setuid 4000 При выполнении файла в действующий UID процесса устанавливается UID владельца файла.
setgid 2000 При выполнении файла в действующий GID процесса устанавливается GID группы файла.
sticky bit 1000 Для каталога, предотвращает удаление файлов, владельцем которых не является текущий пользователь. Для обычного файла значения не имеет.
Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF148:Sysadmin&oldid=15423»
Персональные инструменты
купить
подписаться
Яндекс.Метрика