Enhanced RBAC в AIX 6.1


Что делать, если под рукой нет sudo, но есть AIX 6.1? Одна из задач системного администратора – предоставление прав, которые необходимы пользователю для его каждодневной деятельности. Но иногда пользователю требуются расширенные права – например, администратор приложения хочет рестартовать свое приложение, но запускается оно только под root’ом, а администратор Oracle хочет знать, какие параметры выставлены у vmo.

  Если бы у меня был только один сервер в эксплуатации, наверно, не было бы проблем выполнить их запросы, но поскольку количество серверов и LPAR’ов на них стремится к бесконечности, то надо либо принимать на работу еще администраторов, которые только и будут целыми днями перезапускать приложения и выдавать результаты вывода vmo -L, либо искать способы, как предоставить необходимые права пользователям, но при этом не дать им слишком много прав, чтобы сервер все-таки продолжал работать.

В AIX 6.1 для решения подобных задач появилась новая функция – Enhanced RBAC, которая позволяет выдавать пользователям права на основании присвоенных им администратором ролей. По умолчаниюEnhanced RBAC включается при установке системы. Для проверки необходимо посмотреть атрибуты sys0:

$ lsattr -El sys0 -a enhanced_RBAC

enhanced_RBAC true Enhanced RBAC Mode True

Если опция выключена, то после ее включения необходимо перезапустить сервер.

$ lsattr -El sys0 -a enhanced_RBAC

enhanced_RBAC false Enhanced RBAC Mode True

$ chdev -l sys0 -a enhanced_RBAC=true

$ lsattr -El sys0 -a enhanced_RBAC

enhanced_RBAC true Enhanced RBAC Mode True

$ shutdown -Fr

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

Первый шаг  – узнать авторизации, требуемые для запуска vmo.

$ lssecattr -c /usr/sbin/vmo

/usr/sbin/vmo egid=0 accessauths=aix.system.config.perf innateprivs=PV_KER_VARS,PV_KER_VMM,PV_KER_RAC secflags=FSF_EPS

Команда lssecattr показывает security-атрибуты команд, которые есть в соответствующих таблицах ядра. Нас интересует поле accessauths – перечень авторизаций, обладая которыми пользователь может запускать команду. Авторизации назначаются каким-либо ролям, поэтому следующим этапом необходимо найти роль, которой присвоена авторизация aix.system.config.perf. Сделать это можно при помощи команды lsrole:

$ lsrole ALL | grep aix.system.config.perf

SysConfig authorizations=aix.system.boot.create,aix.system.config.bindintcpu,aix.system.config.console, aix.system.config.date,aix.system.config.diag,aix.system.config.dlpar,aix.system.config.inittab, aix.system.config.io,aix.system.config.kext,aix.system.config.mode,aix.system.config.perf, aix.system.config.rset,aix.system.config.uname,aix.system.config.write,aix.system.stat,aix.wpar rolelist= groups= visibility=1 screens=* dfltmsg=System Configuration Administration msgcat=role_desc.cat msgnum=10 msgset=1 auth_mode=INVOKER id=10

Таким образом получается, что самый простой способ выдать пользователю права на запуск vmo, это предоставить ему роль SysConfig. Не стоит этого делать в реальной жизни, но для примера вполне подойдет.

$ chuser roles=SysConfig user

$ setkst

Successfully updated the Kernel Authorization Table.

Successfully updated the Kernel Role Table.

Successfully updated the Kernel Command Table.

Successfully updated the Kernel Device Table.

Командой chuser мы назначили пользователю user роль Sysconfig, а командой setkst обновили все таблицы ядра. Команду setkst надо обязательно применять после любых изменений в настройках RBAC. В данном случае мы не вносили никаких изменений в настройки RBAC, мы лишь добавили роль пользователю, но тем не менее лучше перестраховаться и обновить таблицы ядра, чем потом долго вместе с IBM Support выяснять, почему ничего не работает.

Теперь проверим из-под пользователя, что получилось.

user$ rolelist

SysConfig            System Configuration Administration

user$ vmo

ksh: vmo: 0403-006 Execute permission denied.

user$ swrole SysConfig

user’s Password:

user$ vmo

Usage: vmo -h [tunable] | {[-F] -L [tunable]} {[-F] -x [tunable]}

       vmo [-p|-r] (-a [-F] | {-o tunable})

       vmo [-p|-r] (-D | ({-d tunable} {-o tunable=value}))

user$ ^D

 При помощи команды rolelist можно посмотреть, какие роли есть у пользователя – в данном случае только SysConfig. Но несмотря на то, что у пользователя есть роль SysConfig, он не может просто так выполнить команду vmo. Для этого ему сначала надо сменить свою текущую роль с обычного пользователя на SysConfig, воспользовавшись командой swrole. Команда swrole запрашивает текущий пароль пользователя и, в случае если он введен верно, запускает shell с новыми правами. Для того, чтобы понять, в каком из shell’ов находится пользователь (в привилегированном или обычном), необходимо дать команду rolelist -e:

user$ rolelist -e

rolelist: 1420-062 There is no active role set.

user$ swrole SysConfig

user’s Password:

user$ rolelist -e

SysConfig

user$ ^D

В первом приближении задача выполнена. Но пользователь вскоре прочитает man по команде rolelist и обнаружит еще один ключ – -a, который показывает список авторизаций для его роли.

user$ rolelist -a

SysConfig    aix.system.boot.create

             aix.system.config.bindintcpu

             aix.system.config.console

             aix.system.config.date

             aix.system.config.diag

             aix.system.config.dlpar

             aix.system.config.inittab

             aix.system.config.io

             aix.system.config.kext

             aix.system.config.mode

             aix.system.config.perf

             aix.system.config.rset

             aix.system.config.uname

             aix.system.config.write

             aix.system.stat

             aix.wpar

user$ swrole SysConfig

user’s Password:

user$ lsitab -a | head -1

init:2:initdefault

user$

Как и следовало ожидать, у пользователя оказалось чересчур много прав и он, например, может теперь самостоятельно добавить какую-нибудь команду для выполнения при старте системы. А если после его опытов система не стартует, то отвечать придется администратору. Поэтому надо срочно отобрать все лишние права.

Для этого нам надо создать еще одну роль, этой роли назначить авторизацию aix.system.config.perf, а затем назначить эту роль пользователю.

$ mkrole authorizations=aix.system.config.perf TunablesAdmin

$ lsrole TunablesAdmin

TunablesAdmin authorizations=aix.system.config.perf rolelist= groups= visibility=1 screens=* dfltmsg= msgcat= auth_mode=INVOKER id=11

$ chuser roles=TunablesAdmin user

$ lsuser -a roles user

user roles=TunablesAdmin

$ setkst

Successfully updated the Kernel Authorization Table.

Successfully updated the Kernel Role Table.

Successfully updated the Kernel Command Table.

Successfully updated the Kernel Device Table.

Если после этого пользователь запустит rolelist, то он увидит, что у него есть только одна роль – TunablesAdmin. Но если пользователь сменил свою роль на SysConfig до того, как мы поменяли его настройки, то у пользователя останутся все права до тех пор, пока он не выйдет из shell’а. Например:

user$ swrole SysConfig

user’s Password:

user$

<в этот момент мы поменяли настройки пользователя>

user$ rolelist

TunablesAdmin

user$ lsitab -a | head -1

init:2:initdefault:

<пользователь все еще может использовать команды для роли SysConfig>

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

$ for pid in `ps -U user | grep -v PID | awk ‘{ print $2 }’` ; do echo $pid ; rolelist -p $pid ; done

2301970

SysConfig       System Configuration Administration

3301576

3305474

$ kill -9 2301970

Мы нашли с помощью команды rolelist, что процесс 2301970 имеет привилегии SysConfig, а затем с помощью команды kill -9 убили его. Пользователь со своей стороны увидел надпись Killed:

user$ Killed

user$ rolelist

TunablesAdmin

user$ swrole TunablesAdmin

user’s Password:

user$ vmo

Usage: vmo -h [tunable] | {[-F] -L [tunable]} {[-F] -x [tunable]}

       vmo [-p|-r] (-a [-F] | {-o tunable})

       vmo [-p|-r] (-D | ({-d tunable} {-o tunable=value}))

$ lsitab -a

ksh: lsitab: 0403-006 Execute permission denied.

Мы добились того, что пользователь может запускать только те команды, которые определены для aix.system.config.perf, но и их слишком много:

$ lssecattr -c ALL | grep aix.system.config.perf | awk ‘{ print $1 }’

/usr/bin/rmss

/usr/lib/perf/rmss_back

/usr/sbin/ioo

/usr/sbin/nfso

/usr/sbin/no

/usr/sbin/raso

/usr/sbin/schedo

/usr/sbin/tunchange

/usr/sbin/tuncheck

/usr/sbin/tundefault

/usr/sbin/tunrestore

/usr/sbin/tunsave

/usr/sbin/vmo

Это слишком большой перечень команд для пользователя, которому нужна лишь команда vmo. Сначала нам нужно создать какую-либо авторизацию, которой потом назначить право выполнения /usr/sbin/vmo.

$ mkauth rba

$ mkauth rba.vmouser

$ lsauth rba.vmouser

rba.vmouser id=10014

Для того, чтобы создать авторизацию rba.vmouse, сначала необходимо создать авторизацию rba. Лучше все свои авторизации объединить в одной какой-либо иерархии, чтобы в дальнейшем не путать их с системными авторизациями.

После создания авторизации назначаем команде /usr/sbin/vmo две авторизации – системную и нашу.

$ setsecattr -c accessauths=rba.vmouser,aix.system.config.perf /usr/sbin/vmo

$ lssecattr -c /usr/sbin/vmo

/usr/sbin/vmo egid=0 accessauths=rba.vmouser,aix.system.config.perf innateprivs=PV_KER_VARS,PV_KER_VMM,PV_KER_RAC secflags=FSF_EPS

Таким образом нам не надо переделывать системные роли, чтобы добавить в них свою авторизацию на запуск vmo, но в то же время мы можем создать свою роль, которая будет обладать правами лишь на запуск одной команды.

$ mkrole authorizations=rba.vmouser VmoAdmin

$ chuser roles=VmoAdmin user

$ setkst

Successfully updated the Kernel Authorization Table.

Successfully updated the Kernel Role Table.

Successfully updated the Kernel Command Table.

Successfully updated the Kernel Device Table.

$ for pid in `ps -U user | grep -v PID | awk ‘{ print $2 }’` ; do echo $pid ; rolelist -p $pid ; done

3301576

3305474

Теперь проверим из-под пользователя, какие права у него есть:

user$ rolelist -a

VmoAdmin       rba.vmouser

user$ swrole VmoAdmin

user’s Password:

user$ vmo

Usage: vmo -h [tunable] | {[-F] -L [tunable]} {[-F] -x [tunable]}

       vmo [-p|-r] (-a [-F] | {-o tunable})

       vmo [-p|-r] (-D | ({-d tunable} {-o tunable=value}))

user$ schedo

ksh: schedo: 0403-006 Execute permission denied.

Мы наконец-то добились, чтобы у пользоветеля были права лишь на запуск vmo! Но этого мало – нам пользователю надо дать права лишь на чтение параметров, а не на их изменение. Поэтому права надо выдать лишь на один ключ команды vmo – -L. Указать для команды какие-либо дополнительные ключи при использовании setsecattr, к сожалению, невозможно. Поэтому единственный выход – написать свой скрипт, который будет делать лишь то, что необходимо, а затем выдать права на этот скрипт.

$ cat >/usr/ucb/vmol

#!/usr/bin/sh

/usr/sbin/vmo -L

^D

$ chmod +x /usr/ucb/vmol

$ vmol

<вывод убран>

Из-под пользователя user в нормальной ситуации этот скрипт не запускается:

user$ vmol

/usr/ucb/vmol[3]: /usr/sbin/vmo: 0403-006 Execute permission denied.

Выдаем пользователю права на запуск vmol, не забывая отобрать права на запуск vmo.

$ setsecattr -c egid=0 accessauths=rba.vmouser /usr/ucb/vmol

$ setsecattr -c accessauths=aix.system.config.perf /usr/sbin/vmo

$ lssecattr -c /usr/ucb/vmol

/usr/ucb/vmol egid=0 accessauths=rba.vmouser

$ lssecattr -c /usr/sbin/vmo

/usr/sbin/vmo egid=0 accessauths=aix.system.config.perf innateprivs=PV_KER_VARS,PV_KER_VMM,PV_KER_RAC secflags=FSF_EPS

$ setkst

Successfully updated the Kernel Authorization Table.

Successfully updated the Kernel Role Table.

Successfully updated the Kernel Command Table.

Successfully updated the Kernel Device Table.

Теперь в очередной раз проверяем:

user$ swrole VmoAdmin

user’s Password:

$ vmol |  head -1

NAME                          CUR       DEF    BOOT   MIN   UNIT              TYPE           DEPENDENCIES

$ vmo

ksh: vmo: 0403-006 Execute permission denied.

Вот теперь задача выполнена полностью, остались лишь мелочи. Мне не очень нравится для выполнения одной команды регулярно вводить swrole и собственный пароль. Для облегчения жизни у пользователей есть атрибут default_roles.

$ chuser default_roles=VmoAdmin user

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

user$ rolelist -e

VmoAdmin

user$ vmol

<вывод вырезан>

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

$ lsrole -a auth_mode VmoAdmin

VmoAdmin auth_mode=INVOKER

$ chrole auth_mode=NONE VmoAdmin

$ setkst

Successfully updated the Kernel Authorization Table.

Successfully updated the Kernel Role Table.

Successfully updated the Kernel Command Table.

Successfully updated the Kernel Device Table.

После этого команда swrole не будет спрашивать пароль пользователя, когда он будет менять свою роль на VmoAdmin.

Более подробно об Enhanced RBAC можно прочитать в AIX V6 Advanced Security Features .

 

 

Оставьте комментарий