2sash-kan: Новая страница: «==По рецептам доктора Брауна== : Доктор обучает, пишет и консультирует по Linux. Ученая степе…»

2014-07-21T15:03:31Z

Новая страница: «==По рецептам доктора Брауна== : Доктор обучает, пишет и консультирует по Linux. Ученая степе…»

Новая страница

==По рецептам доктора Брауна==

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

{{Врезка|left|Заголовок=Вылезайте из-под камня...|Содержание=Ни одна из лягушек в нашем саду не припрыгала ко мне, чтобы попросить адрес IPV6. Но последние пару лет они, скорее всего, жили под камнем.

Все остальные, надеюсь, в курсе, что адресное пространство IPV4 заканчивается. В RIPE NCC, Региональном интернет-реестре [Regional Internet Registry], который обслуживает Европу, Ближний Восток и Центральную Азию, сейчас осталось около 4,5 блока /8 (около 75 миллионов адресов), но эта цифра постоянно тает.

В апреле оставшийся запас в APNIC (обслуживающем Азиатско-Тихоокеанский регион) упал ниже одного блока /8 (16 миллионов адресов).

Необходимость «подготовить» мир к IPV6 начинает давить.

А вам в этой ситуации что делать? Начните с посещения сайта http://test-ipv6.com, который определит, есть ли у вас поддержка IPV6. Скорее всего, ее нет, но это не повод для паники.

;Время действий

Сайты с IPV4 никуда не денутся. Переключение с IPV4 на IPV6 – это не переход с правостороннего движения на левостороннее: его не обязательно делать всем сразу.

В обозримом будущем IPV4 и IPV6 будут сосуществовать в Интернете параллельно. Может пройти лет 20 или больше, прежде чем IPV4 «отключат» окончательно.

Впрочем, мы видим, что новые сайты поддерживают только доступ по IPV6. Если вы работаете в Linux (конечно, да!), ваш компьютер умеет говорить на IPV6, хотя вы могли не активировать эту возможность. А вот ваш ADSL-модем и провайдер – совершенно другая история.

Начните допекать своего провайдера вопросами, когда же он наконец введет поддержку IPV6. Только давление клиентов заставит провайдеров отреагировать. Впрочем, поверьте мне, это не вопрос «если», это вопрос «когда».|Ширина=20%}}

[[File:LXF148.bytes.png|thumb|«Режим» файла состоит из девяти хорошо знакомых нам битов «прав» и трёх других битов. Ключевой бит в повышении привилегий — 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.

{{Врезка|right|Заголовок=Привилегии Гномов|Содержание=В Gnome для разрешения привилегированных действий используется PolicyKit. Это сложная схема, в которой набор действий вроде “org.debian.apt.install-packages” задается в иерархическом пространстве имен. (В командной строке pkaction выведет список действий.) Действия определяются в XML-файлах в /usr/share/polkit-1/actions. Большинство пользователей увидят агента аутентификации в действии – при попытке выполнения привилегированной операции появится маленькое окошко, которое позволит аутентифицироваться. PolicyKit различает аутентификацию пользователя (запрашивается пароль пользователя) и администратора (запрашивается пароль root). Эти две ситуации аналогичны использованию su и sudo соответственно в мире командной строки.|Ширина=20%}}

===Обновление первого ранга===

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

Каждый процесс в 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 владельца исполняемого файла.

{{Врезка|left|Заголовок=Разверните собственную систему|Содержание=Имея доступ root, вы можете создавать собственные программы с setuid. В доказательство, вот вам showid.c, простая программа на C – она выводит мои реальный и действующий идентификаторы пользователя:

#include <stdio.h>
void main()
{
printf(“real = %d\n”, getuid());
printf(“effective = %d\n”, geteuid());
}

Я скомпилировал ее командой

$ gcc showid.c -o showid

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

$ ./showid
real = 1000
effective = 1000

Затем от имени root я изменил владельца файла на root и установил бит setuid:

# chown root showid
# chmod u+s showid

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

$ ./showid
real = 1000
effective = 0

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

#/bin/bash
id -ur # Show real UID
id -u # Show effective UID

вы увидите, что бит setuid не имеет эффекта. И для реального, и для действующего UID выводится значение 1000.|Ширина=40%}}

====Хранение файлов====

Бит 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 и смонтировать файловые системы на моем жестком диске, или, в порядке крайней меры, просто открутить и утащить мой жесткий диск. Физическая безопасность компьютера важна.

====Биты «режима» файла====

{|class="wikitable"
!БИТ
!ВОСЬМЕРИЧНОЕ ЗНАЧЕНИЕ
!ЧТО ОН ДЕЛАЕТ
|-
|setuid
|4000
|При выполнении файла в действующий UID процесса устанавливается UID владельца файла.
|-
|setgid
|2000
|При выполнении файла в действующий GID процесса устанавливается GID группы файла.
|-
|sticky bit
|1000
|Для каталога, предотвращает удаление файлов, владельцем которых не является текущий пользователь. Для обычного файла значения не имеет.
|}

LXF148:Sysadmin - История изменений

2sash-kan: Новая страница: «==По рецептам доктора Брауна== : Доктор обучает, пишет и консультирует по Linux. Ученая степе…»