Знакомство с Linux. Часть 10. SUID, sudo и прочий административный ресурс

Продолжим разговор об обеспечении безопасности системы рассмотрением чрезвычайно полезной утилиты sudo. Если в системе имеется набор рутинных функций, которые часто нужно выполнять от имени суперпользователя, то нет смысла всякий раз ради этого открывать root-консоль или использовать команду su -.

Sudo позволяет аккредитованному пользователю исполнять команды от имени root'а - или любого другого пользователя системы, в зависимости от настроек. Настройки аккредитации хранятся в файле /etc/sudoers.


По умолчанию, простая аккредитация пользователя означает, что при попытке исполнить команду от имени другого ему будет предложено ввести свой пароль - свой собственный, обратите внимание, а не пароль того, от чьего имени он собирается действовать. Вдобавок, "эффект памяти" после первого ввода пароля составляет по тому же умолчанию всего пять минут, и если команду sudo вновь отдать по истечении этого срока, она снова затребует пароль. Однако изменением настроек в файле /etc/sudoers можно преодолеть эти ограничения, уместные для больших многопользовательских систем, но никак не для домашних компьютеров.

Кстати, если sudo попытается воспользоваться неаккредитованный пользователь, сообщение об этом в виде электронного письма незамедлительно отправится на локальный адрес root, и если даже машина не подключена к Интернету, суперпользователь получит это письмо. Кроме того, запись о нарушителе появится в системном журнале.


(О том, что такое системный журнал и как читать электронную почту, мы вскоре поговорим отдельно. Самым нетерпеливым порекомендую команды man syslog и man mail, соответственно).


Чтобы определить, какими полномочиями наделён тот или иной пользователь для исполнения команды sudo, достаточно от его имени сделать запрос sudo -l


Изначально только root имеет право вершить при помощи sudo всё, что угодно, - но суперпользователю эта утилита ни к чему, он и так способен на всё. Владельцам же прочих учётных записей на данном компьютере следует позаботиться о своей аккредитации. Заведение в /etc/sudoers новых правил следует производить - внимание! - не при помощи привычного вам редактора, а посредством особой утилиты visudo. Её аналоги, кстати, имеются и для редактирования файлов паролей /etc/passwd и групп /etc/group - vipw и vigr, соответственно. Главная их особенность - в том, что перед запуском самого редактора они блокируют (lock) редактируемый файл, так что ни один другой пользователь не сможет в то же самое время его править. Vi ведь оперирует не с самим файлом, а с его копией в памяти, как мы помним, и до самого момента явной записи информации на диск в исходный файл не вносятся изменения. Значит, возможна ситуация, когда один и тот же файл открывают на редактирование два пользователя (в случае /etc/sudo, например, им обоим должнен быть известен пароль root). Тогда в итоге файл останется таким, каким сохранит его на диск последний из завершивших работу пользователей. Если же файл блокирован, открыть его кому-то ещё в то же самое время будет непросто.

Утилита sudo - мощный и гибкий инструмент, и с его помощью системный администратор может существенно облегчить свою жизнь. Скажем, можно аккредитовать в /etc/sudoers своего заместителя для выполнения некоторых рутинных обязанностей и не терзаться мыслью о том, что пароль root'а знает кто-то ещё: теперь это ни к чему. Однако вряд ли для домашнего компьютера потребуется вся потаённая мощь sudo - всё-таки уровень подозрительности к окружающим, если это члены семьи, даже у самого параноидального сисадмина должен быть понижен. Так что наиболее распространённая опция в sudo "для дома, для семьи" - это разрешение на запуск той или иной полезной утилиты от имени непривилегированного пользователя без дополнительного введения пароля.

Аккредитация в этом случае выглядит чрезвычайно просто (если вас интересуют более глубокие подробности, к вашим услугам man sudo и man 5 sudoers). Запустите команду visudo, и в самой последней строке открывшегося файла допишите строчку

[имя пользователя] localhost.localdomail = NOPASSWD: [полный путь исполнения]

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


Как видно, достаточно исполнить sudo [имя программы], и всё получится. В то время как неаккредитованному пользователю будет отказано в запуске команды, а root получит по электронной почте сообщение о происшествии.


И всё-таки sudo - не панацея. Помните об этом, передоверяя сторонним пользователям запуск недоступных для них по умолчанию команд. Ведь ограничения на использование тех или иных утилит наложены разработчиками ОС неспроста. Многие программы имеют возможностью выхода в оболочку (например, тот же редактор vi способен исполнять консольные команды). И если человек, не прерывая сеанса sudo, умудрится получить доступ к командной оболочке - воспользовавшись особенностью данной программы или её багом - это прямая дорога к разрушению всей системы безопасности, поскольку в руках злоумышленника сразу же окажется суперпользовательский логин. Даже такая невинная утилита, как отображающая содержимое файлов cat, может применяться для перезаписи файлов. Используйте sudo для облегчения повседневной работы, но не надейтесь, что проблемы локальной безопасности отныне перестанут быть актуальными.

Будем считать, что с безопасностью на уровне пользователей мы с вами разобрались. Давайте посмотрим, каким образом можно укрепить файловую систему.

Прежде всего, упомянем о том, чего до сих пор избегали: о битах SUID/SGID. SUID - это сокращение от set user identifier; SGID, соответственно, - set group ID. Эти биты являются атрибутом файла/каталога, наряду с правами на чтение или запись, и позволяют производить некое действие над файлом от имени другого пользователя - так, как если бы это был его владелец. Иными словами, если у файла, принадлежащего root, выставлен бит SUID, то его может исполнить другой пользователь - и, как можно догадаться, не всегда с благими намерениями.


Вообще говоря, создатели ОС Linux прекрасно осознавали опасность самой идеологии SUID/SGID в целом, но иногда для административных целей она просто необходима. К счастью, современные системные средства (такие, как команды печати и модемного соединения) учатся обходиться без неё, и уж совершенно точно в системе можно указать целые разделы, размещение в которых SUID/SGID-программ представляется абсолютно ненужным и даже опасным. И в системе предусмотрены средства ограничить их размещение. Специальный параметр монтирования nosuid (с которым знакомы те, кто изучил руководство по команде mount) делает SUID/SGID-биты, присвоенные файлам на данной системе, неэффективными. Такой параметр имеет смысл применить к разделу, содержащему директории пользователей. Не лишним окажется он и для всех прочих разделов, куда разрешена запись не одному лишь пользователю root: обычно это /tmp. Кроме того, для них же полезными окажутся опции noexec (запрет на исполнение бинарных файлов) и nodev (запрет на создание символьных и блочных устройств - всё равно их "доброкачественные" версии сосредоточены в каталоге /dev). Поскольку опциями по умолчанию (defaults) являются rw, suid, dev, exec, auto, nouser и async, для потенциально пордверженных компрометации разделов разумно будет явно указать в файле /etc/fstab rw, nosuid, nodev, noexec, auto, nouser и async.


Отнеситесь со всей возможной жёсткостью к установке прав на вновь создаваемые пользователями каталоги и файлы. По умолчанию, их создание происходит с достаточно мягкими правами - применяется маска 0006 (мы обсуждали маски файлов, когда разговор шёл о монтировании систем), то есть файл рождается доступным на чтение/запись как самому владельцу, так и его группе, а всем прочим пользователям разрешено вдобавок его чтение.


Нелишним будет ужесточить маску до 0077 - то есть полностью блокировать даже чтение для всех, кроме самого пользователя. Пусть делегирование дополнительных прав на файл будет осознанным шагом. Изменить маску по умолчанию можно, отредактировав файл .bashrc в домашнем каталоге каждого действующего пользователя. а также /etc/skel/.bashrc - для всех вновь создаваемых.



Мощным средством поддержания порядка в пользовательских каталогах является квотирование дискового пространства - то есть установление жёстких пределов, до которых могут разрастаться эти каталоги. Строго говоря, уже сам факт выделения особого раздела /home под пользовательские нужды подразумевает, что такие пределы установлены, и насколько бы опрометчивым ни оказалось расходование свободного места пользователями, на общую работоспособность системы это не повлияет. Желающие могут обратиться к страницам руководств программ quota и edquota, но для домашнего компьютера их применение не выглядит настолько оправданным, как для больших многопользовательских систем, где в самом деле переполнение отведённого одному пользователю пространства может серьёзно затруднить работу всех прочих.

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

Общий синтаксис программы таков:

find [путь] [выражение]

причём "выражение" может быть и указанием на тип разыскиваемого файла, и командой на исполнение некой операции по результату поиска, и т. п. Ну, например: известно, что наличие в системе файлов .rhosts является практически гарантированным маркером готовящегося или свершившегося взлома. Эти файлы обеспечивают работу крайне небезопасных r-протоколов, доставшихся Linux в наследство из славного прошлого, когда важно было обеспечить простоту и надёжность доступа, а вовсе не его безопасность. Так вот, поиск всех файлов с именем .rhosts, начиная с корня домашнего пользовательского (/home) каталога задаётся командой

find /home -name .rhosts

Будем надеяться, что вы у себя таковых не обнаружите. Далее: у каждого файла, возникающего в системе нормальным путём (при инсталляции или дальнейшей работе легитимных пользователей) есть владелец и группа владения. У файлов же, создаваемых хакерами, их зачастую просто нет. То есть цифровое обозначение пользователя и группы у таких файлов присутствует, но вот полноценных учётных записей, которые им соответствовали бы, в системных файлах нет. Поискать беспризорников по всей файловой системе, от самого корневого каталога (/) можно, исполнив команду

find / -nouser -o -nogroup

(параметр -o выступает здесь, как нетрудно догадаться, аналогом логического оператора "или"). Если подозрительный улов обнаружится в системных каталогах, не пытайтесь сразу отформатировать винчестер и переставить ОС по новой - возможно, это просто какая-то недоработка; свяжитесь с разработчиками соответствующей программы, поставщиками вашего дистрибутива или задайте вопрос на форуме. А вот если ничейные файлы находятся в /home - тут дело явно нечисто. Пора приступать к изучению системных журналов...

И мы к нему обязательно приступим. Даже скорее, чем вы думаете!