ISP`s IT Аутсорсинг
Быстрый переход: Главная блога Главная сайта Форум
Если Вы чего то недопоняли или не нашли - задайте
вопрос на нашем форуме и мы попробуем Вам помочь.
Subnets.ru Регистрация IP и Автономных систем mega-net.ru

Вступление

Как известно, в ОС FreeBSD бывают пользователи двух типов: суперпользователи (администраторы) и обычные. Обычные пользователи могут выполнять команды, у которых установлен соответствующий бит исполнения. Но могут возникнуть ситуации, когда нужно пользователю дать право на выполнение только определенных команд (в нашем примере — должна быть доступна только команда ifconfig без аргументов), исключив выполнение всех остальных.

Решение

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

1. Ставим из дерева портов sudo:

cd /usr/ports/security/sudo

make install clean

Правим конфигурационный файл /usr/local/etc/sudoers:

root ALL=(ALL) ALL # означает что все команды будут выполняться от пользователя root.

#Далее создается набор команд под названием TP: следует перечисление через запятую сначала

#всех запрещенных каталогов и программ, а затем всех допустимых комманд с полным путем.

#Если команда написана как /usr/local/bin/nmap, то это означает что ее разрешено запускать c любыми

#аргументами. Если же после команды стоят символы «», то это означает что команду не разрешено

#запускать с аргументами. /sbin/ifconfig tun[0-9]* * — разрешает запускать команду ifconfig с

#аргументами tunX, где X любое число от 0 до бесконечности, плюс любой аргумент после.

#/usr/bin/tail -[fFn] /var/log/* — также разрешает запускать tail с любым из аргументов, указанных в скобках

#и указать файл из каталога /var/log/.

Cmnd_Alias TP=!/bin/,!/sbin/,!/usr/bin/,!/usr/sbin/,!/usr/local/bin/,!/usr/local/sbin/,/sbin/ifconfig «»

user ALL=(ALL) NOPASSWD: TP # разрешает выполнять комманды из списка TP только пользователю с именем user,

# без ввода пароля root’а

2. Ставим из дерева портов bash:

cd /usr/ports/shells/bash

make install clean

3. Создаем домашний каталог для пользователя user:

mkdir -p /usr/home/user

4. Настраиваем bash:

Создаем в домашнем каталоге пользователя user профайл bash с именем .bash_profile следущего содержания:

PATH=/usr/home/user; export PATH #Оставляем в путях только каталог пользователя user
alias ifconfig=»sudo /sbin/ifconfig» #Здесь делаем доступные команды для user «прозрачными»

5. Создаем в домашнем каталоге пользователя user файл с названием bash следущего содержания:

#!/bin/sh /usr/local/bin/bash —rcfile /usr/home/user/.bash_profile -r # Запускать bash в ограниченном режиме

#(ключ -r) c указанием файла с начальными настроками (—rcfile /usr/home/user/.bash_profile)

6. Создаем пользователя с именем user:

pw adduser user -g nogroup -d /usr/home/user -s /usr/home/user/bash

7. Задаем ему пароль:

passwd user

8. Безопасность. Действия совершаются во избежание записи чего-либо пользователем user в свой каталог (для дальнейшего возможного повышения привелегий :)) :

Меняем владельца/группу каталога пользователя user на user:nobody:

chown -R user:nogroup /usr/home/user

Профайл bash оставляем за root’ом:

chown root:wheel /usr/home/user/.bash_profile

Выставляем права:

сhmod -R 400 /usr/home/user #устанавливаем на всё права «только чтение только для владельца»

сhmod 500 /usr/home/user #устанавливаем на каталог бит «х» для возможности владельцу войти в него

сhmod 500 /usr/home/user/bash #для запуска нашего «модифицированного» баша

Профайл bash доступен для чтения всем:

chmod 444 /usr/home/user/.bash_profile

9. Делаем символическую ссылку на sudo в домашнем каталоге пользователя user:

ln -s /usr/local/bin/sudo /usr/home/user

Листинг домашнего каталога пользователя user выглядит, примерно, так:
-r—r—r— 1 root wheel 122 Sep 2 22:42 .bash_profile
-r-x—— 1 user nogroup 73 Sep 2 22:39 bash
lrwxr-xr-x 1 root nogroup19 Sep 2 22:42 sudo -> /usr/local/bin/sudo

Все, пользователь user ограничен в действиях: ему доступна только команда ifconfig и без параметров.

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

ls
bash: ls: command not found
/bin/ls
bash: /bin/ls: restricted: cannot specify `/’ in command names
sudo /bin/ls
Sorry, user user is not allowed to execute ‘/bin/ls’ as root on subnets.ru.

При запуске разрешенных команд идет логирование в /var/log/messages:

Sep 8 16:53:37 subnets.ru sudo: user : TTY=ttyp3 ; PWD=/usr/home/user ; USER=root ; COMMAND=/sbin/ifconfig

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА !

Авторы: TheFeaR, ace, Панфилов Алексей (lehis (at) subnets.ru)

З.Ы.Ы.  Хорошая статейка на тему sudo:

Как обойтись без прав root.

Майкл Лукас (перевод Станислава Лапшанского)
Оригинал статьи находится по адресу: http://www.onlamp.com/pub/a/bsd/2002/08/29/Big_Scary_Daemons.html

Правильная реализация системы безопасности на основе групп помогает резко уменьшить необходимость в применении пароля суперпользователя, однако, несмотря на это, время от времени пользователям все же необходимо выполнять команды с правами какого-нибудь другого пользователя (обычно это суперпользователь). Так как вы являетесь системным администратором, вам часто приходится стоять перед нелегким выбором, или постоянно выполнять просьбы ваших пользователей, или раздать всем желающим суперпользовательский пароль. Утилита sudo позволит разрубить вам этот гордиев узел, предоставляя третий, более рациональный путь. Впрочем, не следует забывать, что это довольно тонкая программа, требующая аккуратности при ее конфигурировании. sudo непосредственно интегрирована в OpenBSD, но с таким же успехом может быть установлена почти в любой версии UNIX в качестве стороннего приложения.

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

При соответствующей настройке, системный администратор может позволить любому пользователю выполнять любые программы от имени любого другого пользователя. sudo очень мощная утилита, с ее помощью можно разрешить или запретить практически любой набор команд. Как результат такой гибкости, документация sudo, отпугивает новичков своей сложностью. Мы займемся конфигурированием sudo, на уровне, которого вполне должно хватить для большинства пользователей, однако вам следует помнить, что существует большое количество различных дополнительных параметров конфигурирования, которые описаны в руководстве sudo (8) и sudoers (5).

Преимущества от использования sudo не ограничиваются предоставлением четкой системы разграничения доступа. Одним из важнейших преимуществ является журналирование выполняемых пользователями команд. Каждая команда выполняемая sudo, записывается в журнал, что чрезвычайно упрощает выяснение того, кто, что и когда изменял. Кроме того, когда вы корректно настроите sudo, вы наконец сможете поменять суперпользовательский пароль и никогда больше никому его не давать. Более того, если вы все правильно настроите, то суперпользовательский пароль вообще никому не потребуется. Сокращение количества людей, знающих пароль суперпользователя ведет к увеличению защищенности вашей системы. И наконец, один и тот же конфигурационный файл программы sudo может применяться на всех ваших серверах, тем самым значительно сокращая временные затраты на администрирование системы.

Наиболее серьезным недостатком sudo является, чрезвычайно негативное отношение к ней пользователей и младших администраторов. Так как люди традиционно пользовались суперпользовательским паролем для выполнения своих действий, они подозревают, что при установке в систему sudo они потеряют некоторые прежде доступные им возможности. Для преодоления такого отношения к sudo, вы, в первую очередь должны будете удостовериться, что пользователи с ее помощью смогут выполнять свою работу в полном объеме. Если пользователи уверяют вас, что им требуется суперпользовательский пароль для выполнения других задач, то вы должны просто разобраться кто и за что отвечает. Вероятно такие пользователи брали на себя решение несвойственных им задач, вместо того, что бы озаботить ими вас.

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

Система sudo состоит из трех частей. Во-первых, это сама программа sudo (8) – программа-посредник с установленным setuid-битом, с которой непосредственно взаимодействуют пользователи. Во-вторых это конфигурационный файл sudo /etc/sudoers. Этот файл содержит таблицу прав доступа, в которой указывается кому и какие команды позволено запускать от имени какого пользователя. Его структура полностью описана в руководстве man 5 sudoers. И наконец команда visudo, которая позволяет администраторам редактировать файл sudoers без риска заблокировать себе вход в систему. Мы рассмотрим каждый компонент по очереди: visudo, sudoers и sudo.

Если файл sudoers имеет неправильный синтаксис, sudo просто не запустится. Если вы понадеетесь на sudo (имеется в виду случай, когда вы полностью отказались от использования суперпользовательского аккаунта забыв его пароль – прим. переводчика), предоставите через него доступ к файлу sudoers и при этом это файл испортите, то вы тем самым заблокируете доступ к любым действиям требующим прав суперпользователя и, к тому же, не сможете ничего исправить. Это плохо. Программа visudo (8) призвана обеспечить определенную защиту от подобных ситуаций.

Подобно утилите vipw (8), visudo (8) блокирует редактируемый файл для того чтобы в один момент времени его мог редактировать только одни человек. visudo открывает конфигурационный файл sudoers в редакторе (по умолчанию это редактор vi (1), однако такое поведение системы можно изменить, поменяв содержимое переменной $EDITOR). Когда вы покидаете редактор, visudo проверяет отредактированный файл на наличие синтаксических ошибок, о которых сообщает пользователю. Разумеется такая проверка не дает гарантии того, что конфигурационный файл будет таким как вы хотите, она просто подтверждает его синтаксическую корректность. Например утилита visudo (8) не моргнув глазом примет конфигурационный файл, в котором никто при помощи sudo сможет сделать ничего, если этот файл имеет правильный синтаксис.

Если программа visudo найдет в отредактированном файле ошибку, она выдаст на терминал номер строки в которой встретилась ошибка и спросит вас, что теперь делать:
# visudo
>>> sudoers file: syntax error, line 44 <<<
What now?

В данном случае в 44 строке мы допустили ошибку. Есть три варианта действий: вернуться к редактированию, выйти не сохраняя сделанных изменений или заставить visudo сохранить файл sudoers, несмотря на найденные ошибки.

При нажатии клавиши e, visudo вернет вас в режим редактирования, где вы сможете попытаться исправить обнаруженную ошибку.

Если нажать на x, visudo завершится и возвратит конфигурационный файл в состояние, в котором он был до начала редактирования. Сделанные вами изменения будут потеряны, но возможно это именно то, что нужно в такой ситуации, поскольку лучше иметь старую, но работающую конфигурацию, чем новую, но неработоспособную.

Клавиша Q заставит visudo принять сделанные изменения, несмотря на найденную ошибку. Не забывайте, что если конфигурационный файл содержит ошибку, sudo не запустится. Делая это, вы, в сущности, на некоторое время выключаете sudo, до тех пор, пока вы не отредактируете конфигурацию под аккаунтом суперпользователя. В подавляющем большинстве случаев это не то что вам нужно.

Файл sudoers сообщает sudo, кто может выполнять какие команды и от какого пользователя. OpenBSD хранит файл sudoers в каталоге /etc, а FreeBSD в каталоге /usr/local/etc. Никогда не редактируйте этот файл напрямую, даже если вы уверены, что точно знаете, что именно вы хотите изменить. Всегда используйте visudo.

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

Разнообразные примеры файлов sudoers, которые вы можете легко найти в Интернете, часто бывают слишком сложны и запутаны для понимания, но в них можно увидеть все интересные штучки которые предоставляет пользователю sudo. Однако базовый синтаксис очень прост. Каждая запись правил доступа в файле sudoers имеет следующий формат:
username host = command

Где username это имя пользователя, который может выполнять команду. Параметр host представляет собой имя машины, для которой применимо соответствующее правило. Таким образом есть возможность устанавливать правила для конкретной машины в сети.

В поле command содержится список команд для которых применимо данное правило.

Вы должны указать полный путь для каждой команды, или sudo не будет их распознавать. (Вы ведь не хотите, что бы пользователи могли, просто поменяв переменную $PATH, выполнять совсем другие команды с теми же именами?)

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

Вы можете использовать ключевое слово ALL в любом из трех полей для указания значения подходящего для всего. Например, предположим, что я полностью доверяю пользователю chris и хочу позволить ему выполнять абсолютно любую команду от имени суперпользователя на любой машине:
chris ALL = ALL

Однако давать младшему администратору полный контроль над одной из моих машин не очень разумно. Как главный администратор, я должен знать, какие команды понадобятся Крису для выполнения его работы. Предположим, что Крис администрирует DNS-сервер. К файлам, описывающим зоны сервера имен, доступ ограничивается при помощи групп, но они не смогут нам помочь, когда понадобится стартовать, перезапустить или остановить сервер. Вот как я дал ему права на запуск программы контролирующей демона DNS-сервера:
chris ALL = /usr/sbin/ndc

Если я распространю этот файл на несколько машин, есть высокая вероятность, что далеко не на всех из них окажется сервер имен. Вот так я ограничиваю круг машин, на которых Крис сможет запускать управляющую программу, одним компьютером с именем dns1:
chris dns1 = /usr/bin/ndc

С другой стороны, Крис является еще и администратором машины почтового сервера mail. Он полностью отвечает за этот сервер, и, поэтому может выполнять на нем любые команды, как ему заблагорассудится. Я могу установить для него совершенно другие права доступа к почтовому серверу и, несмотря на это, использовать один и тот же файл sudoers на обеих машинах:
chris dns1 = /usr/bin/ndc
chris mail = ALL

Для того что бы указать несколько значений в одном поле, их можно разделять запятыми. Вот как можно разрешить Крису монтировать гибкий диск при помощи команды mount (8) и одновременно позволить управление сервером имен:
chris dns1 = /usr/bin/ndc, /bin/mount

В файле sudoers, вы можете указать sudo, что ей необходимо выполнять определенные команды от пользователя отличного от root. Для этого вставьте имя нужного пользователя в скобках перед командой. Допустим, что наш сервер имен выполняется не от имени суперпользователя, а от имени пользователя named и все команды для управления им должны запускаться от имени этого пользователя.
chris dns1 = (named) /usr/bin/ndc

Каждая запись в файле /etc/sudoers должна занимать одну строку. В связи с этим строки могут быть непомерно длинными. В таком случае вы можете перенести строку на другую воспользовавшись символом \ в конце строки:
chris server1 = /sbin/fdisk,/sbin/fsck,/sbin/kldload, \ /sbin/newfs,/sbin/newfs_msdos,/sbin/mount

Теперь, когда вы ознакомились, как задаются правила доступа, давайте поглядим, как использовать sudo. Воспользуйтесь visudo, и разрешите своему аккаунту выполнять любую команду. (Если вы смогли установить sudo, значит вы уже обладаете правами суперпользователя и, поэтому то, что вы дали своему аккаунту неограниченные привилегии, не будет дырой в безопасности).

При запуске sudo, во-первых она спросит вас пароль. Введите пароль своего аккаунта (не пароль суперпользователя). Если вы неправильно введете пароль, sudo оскорбит ваши умственные способности или родословную, и предложит ввести пароль еще раз. После третьего раза, sudo отвяжется от вас. Если вы хотите попытаться еще, запустите sudo снова.

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

Если вы простой пользователь и на вашей машине установлена sudo, то весьма вероятно, что вам будет интересен список команд, которые системный администратор счел допустимыми для выполнения вами при помощи sudo. Для вывода этого списка вам пригодится ключ -l:
$ sudo -l
Password:
User mwlucas may run the following commands on this host:
(root) ALL

Если у вас более серьезные ограничения чем у меня, все они будут выведены на экран.

Для того что бы выполнить команду при помощи sudo, просто поставьте перед ней слово sudo. Например, вот как можно выполнить команду su при помощи sudo:
$ sudo su
Password:

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

При помощи sudo вы, так же можете запускать и более сложные команды передавая им все необходимые аргументы. Например, команда tail -f прекрасно подходит для просмотра последних сообщений в файле журнала, кроме того, новые записи будут появляться на экране по мере их появления в файле журнала. Просмотр некоторых файлов журналов доступен только для суперпользователя. Журнал программы sudo является отличной кандидатурой на такую роль. Наверняка вы хотите иметь возможность просмотра журналов без необходимости входить под аккаунтом суперпользователя.
$ sudo tail -f /var/log/authlog
openbsd/usr/src/usr.bin/sudo;sudo tail -f /var/log/secure
Jul 29 13:24:19 openbsd sudo: mwlucas : TTY=ttyp0 ;
PWD=/home/mwlucas ; USER=root ; COMMAND=list
Jul 29 13:30:03 openbsd sudo: mwlucas : TTY=ttyp0 ;
PWD=/home/mwlucas ; USER=root ;
COMMAND=/usr/bin/tail -f /var/log/authlog

Если вы обладаете достаточными правами, то вы сможете запускать программы не только от имени суперпользователя, но и от имени любого другого пользователя. Предположим, например, что у нас есть сервер баз данных, для работы с которым команды надо отдавать от имени пользователя под которым выполняется этот сервер. Вы можете указать необходимого пользователя в ключе -u. Например оператор базы данных имеет привилегии для выполнения программы dump, используемой для резервного копирования:
$ sudo -u operator dump /dev/sd0s1

Все это замечательно, но как проконтролировать использование sudo?

Сообщения от sudo журналируются в источник LOCAL2. Каждое сообщение содержит время его записи, имя пользователя, каталог, где запускалась sudo и команду, которая была выполнена.
Jul 29 11:21:02 openbsd sudo: chris : TTY=ttyp0 ;
PWD=/home/chris ; USER=root ;
COMMAND=/sbin/mount /dev/fd0 /mnt

При худшем варианте развития событий (если в системе что-то нарушится), вы сможете отследить, что происходило. Например, если одна из моих машин не можеhrкорректно перезагрузиться из-за того, что файл /etc/rc.conf испорчен или отсутствует, я могу проверить журнал sudo на предмет операций с этим файлом:
Jul 29 11:34:56 openbsd sudo: chris : TTY=ttyp0 ;
PWD=/home/chris ; USER=root ;
COMMAND=/bin/rm /etc/rc.conf

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

С журналами sudo я всегда могу выяснить кто виноват, как только доберусь до компьютера. Только из-за одного этого sudo стоит установить!

Самым сложным этапом на пути использования sudo, несомненно является написание конфигурационного файла sudoers. Легко представить, что при наличии нескольких машин, с несколькими администраторами, которым требуются различные полномочия, файл sudoers быстро станет слишком большим и запутанным. Использование псевдонимов, может сильно упростить управление sudo и значительно прояснить конфигурационный файл.

Говоря по-русски, псевдоним — это просто группа пользователей, хостов или команд. Если служебные обязанности пользователя меняются, то для придания ему необходимых полномочий, вам следует просто добавить его в описание того или иного псевдонима. Для того что бы ваши системные операторы по прежнему могли делать резервное копирование, но при этом не имея полномочий для восстановления данных, вам придется всего лишь удалить из их псевдонима восстанавливающие команды. Когда вы запустите в эксплуатацию новый сервер, добавление имени этого сервера в соответствующий псевдоним позволит вам незамедлительно дать администраторам системы права, необходимые им для выполнения их работы.

Перед использованием в конфигурации, псевдонимы необходимо определить, поэтому описания псевдонимов обычно находится в начале файла sudoers. Определение псевдонима начинается с метки, которая указывает на вид объектов описываемых этим псевдонимом, затем идет название псевдонима и список объектов скрывающихся под объявляемым псевдонимом.

Пользовательский псевдоним описывает группу пользователей. Объявление пользовательского псевдонима начинается с метки User_Alias. Как нетрудно догадаться, пользовательский псевдоним содержит в себе список пользователей. Описанный в данном примере пользовательский псевдоним DNSADMINS, содержит двух пользователей mwlucas и chris:
User_Alias DNSADMINS = chris,mwlucas

Псевдоним Runas является специальным псевдонимом. Он определяет список пользователей от имени которых другие пользователи могут запускать свои команды.

Многие серверы имен могут выполняться от имени пользователя named. Очевидно, что администратору DNS-сервера может понадобиться запускать команды от имени этого пользователя, следовательно, вы можете определить для него Runas-псевдоним. Многие приложения в составе серверов баз данных выполняются под своим собственным пользователем. Во многих случаях системный администратор, отвечающий за эксплуатацию приложения захочет иметь возможность выполнять резервное копирование от имени пользователя operator. Вы можете создать один Runas-псевдоним для группы таких команд. Псевдоним Runas начинается с метки Runas_Alias.
Runas_Alias APPADMIN = named,dbuser,operator

«Хостовой» псевдоним является просто списком сетевых хостов. Признаком хостового псевдонима является метка Host_Alias. В списке хостов могут присутствовать DNS-имена машин, IP-адреса и адреса сетей. (Помните, что если вы используете DNS-имена, то ваша sudo-конфигурация будет подвержена уязвимостям связанным с системой DNS). Вот примеры записей со всеми тремя типами адресов:
Host_Alias DNSSERVERS = dns1,dns2,dns3
Host_Alias SECURITYSERVERS = 192.168.1.254,192.168.113.254
Host_Alias COMPANYNETWORK = 192.168.1.0/16

Командный псевдоним состоит из списка команд операционной системы. Он начинается с метки Cmnd_Alias. Запишем псевдоним, который будет объединять команды необходимые для резервного копирования и восстановления данных:
Cmnd_Alias BACKUPS = /bin/mt,/sbin/restore,/sbin/dump

Вы можете создать псевдоним, который будет объединять все команды в определенном каталоге. Предположим, что у нас есть некое приложение, которое выполняется от имени определенного пользователя, кроме того, все утилиты этого приложения находятся в домашнем каталоге этого пользователя. Вместо того, что бы указывать в псевдониме все эти команды по очереди, мы можем указать только полный путь к каталогу и образец имени файла, подходящий под все содержимое этого каталога:
Cmnd_Alias DBCOMMANDS = /usr/home/dbuser/bin/*

Для того что бы воспользоваться созданным псевдонимом просто подставьте его имя туда, куда вы обычно пишете имя пользователя, машины или команды соответственно. Выше мы определили пользовательский псевдоним DNSADMINS. Пусть пользователи упомянутые в этом псевдониме имеют право выполнять любые команды на любых серверах:
DNSADMINS ALL = ALL

Давайте предположим что пользователь Фил (Phil) управляет приложением, которое выполняется от имени определенного пользователя. Он может выполнить любую команду на сервере от имени этого пользователя. Воспользуемся ранее определенным Runas-псевдоним APPADMIN и командным псевдонимом DBCOMMANDS, включающим в себя необходимые команды.
phil ALL = (APPADMIN)DBCOMMANDS

Филу требуется делать резервное копирование данных его приложения. Мы уже упомянули пользователя operator в псевдониме APPOWNER (судя по всему автор просто забыл вставить абзац с определением псевдонима APPOWNER, однако его нетрудно восстановить: Runas_Alias APPOWNER = dbuser,operator – прим. переводчика), и описали командный псевдоним BACKUPS для осуществления резервного копирования. Скомбинируем их:
phil ALL = (APPOWNER) DBCOMMANDS, (APPOWNER) BACKUPS

Это выглядит куда проще «развернутой» записи, которую пришлось бы писать не будь у sudo конструкции псевдонимов.
phil ALL = (dbuser,operator)/usr/home/dbuser/bin/*,
(dbuser,operator)/bin/mt, (dbuser,operator)/sbin/restore,
(dbuser,operator)/sbin/dump

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

Имеется возможность использовать вложенные псевдонимы. Например вы хотите объединить псевдонимы DBCOMMANDS и BACKUPS в один общий псевдоним. Разумеется объединяемые псевдонимы уже должны быть описаны перед объединением.
Cmnd_Alias DBADMINS = BACKUPS,DBCOMMANDS

sudo умеет брать информацию о группах пользователей определенных в операционной системе и использовать ее в качестве псевдонимов в файле sudoers. Вместо того, что бы определять пользовательский псевдоним вы можете просто взять имя группы пользователей и использовать его, поставив впереди значок процента %, для того, что бы показать, что это именно имя группы.
%wheel ALL = ALL

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

Вы можете использовать имена псевдонимов повторно. Пользовательский псевдоним DBADMINS это совсем не то же самое что командный псевдоним DBADMINS. Это вполне позволяет делать следующие записи в файле sudoers.
Cmnd_Alias DBAPP = /usr/home/dbuser/bin/*
Host_Alias DBAPP = server8,server12,server15
RunasAlias DBAPP = dbuser,operator
User_Alias DBAPP = chris,mwlucas
DBAPP DBAPP = (DBAPP) DBAPP

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

Теперь давайте пробежимся по неприятным ситуациям в которые попадают даже опытные системные администраторы. Иногда вам требуется запретить пользователям выполнять определенный набор команд, разрешив при этом выполнение всех остальных. Вы можете попробовать сделать это при помощи оператора отрицания !. Имейте в виду, что это абсолютно неэффективно. Поскольку такие попытки делаются довольно часто, мы обсудим, как это работает и в чем тут подвох.

Во-первых определим командный псевдоним, в котором будут описаны запрещенные команды. Часто запрещаются оболочки командных интерпретаторов (поскольку если вы можете выполнить оболочку от имени определенного пользователя, то вы можете делать все под именем этого пользователя) и команда su (1). А теперь давайте запретим вашему пользователю использовать команды описанные этим псевдонимом при помощи модификатора !:
Cmnd_Alias SHELLS = /bin/sh,/bin/csh,/usr/local/bin/tcsh
Cmnd_Alias SU = /usr/bin/su
mwlucas ALL = ALL,!SHELLS,!SU

Выглядит замечательно, не правда ли? Поглядим, как это работает:
$ sudo sh
Password:
Sorry, user mwlucas is not allowed
to execute ‘/bin/sh’ as root on openbsd.

Вспомните, sudo использует полные пути для описания команд. Вы позволили пользователю запускать любую требующуюся ему команду, кроме нескольких запрещенных, описанных полными именами. Все что требуется пользователю для запуска запрещенных команд, это сменить путь к их файлам. Простейшим средством для реализации этой затеи будет простое копирование файлов в необходимое место.
$ id
uid=1000(mwlucas) gid=1000(mwlucas) groups=1000(mwlucas), 0(wheel)
$ cp /bin/sh .
$ sudo ./sh
$ id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys),
4(tty), 5(operator), 20(staff), 31(guest)

Привет, root!

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

Если у вас есть пользователи, которым вы не можете доверить неограниченный доступ к системе, не пользуйтесь исключением команд при описании их привилегий. Ограничьтесь списком явно разрешенных для выполнения команд. Исключение команд может пригодиться только в случае доверенных пользователей (работников), в качестве напоминания (крайне спорно, на мой взгляд лучше вообще не пользоваться, что бы не вводить «во искушение» – прим. переводчика). Т.е. когда я зайду на машину и напечатаю sudo su, sudo скажем мне, что мне не стоит выполнять здесь такие команды.

Взято тут:  http://citkit.ru/articles/132/

Похожие статьи:

    Не найдено

Прочитано: 28 961 раз(а)
Ничего не понялТак себе...Не плохоДовольно интересноОтлично ! То что нужно ! (голосов: 6, среднее: 4,33 из 5)
Загрузка...
Отправить на почту Отправить на почту

Комментариев: 1

  1. TheFeaR сказал:

    Вместо пятого пункта можно просто в master.passwd посредствам vipw, или подобного установить в качестве шелла для юзверя rbash.

Добавить комментарий

Вам следует авторизоваться для размещения комментария.