Управление доступом на основе ролей в SELinux

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

Управление доступом на основе ролей (Role-based access control, RBAC) – это общая модель обеспечения безопасности, которая упрощает администрирование путем назначения ролей пользователям и установки разрешений для этих ролей. RBAC в Linux с повышенной степенью безопасности (Security-Enhanced Linux или SELinux) действует как уровень абстракции между пользователем и лежащей на более низком уровне моделью type-enforcement (TE), которая обеспечивает более точное управление доступом, но не ориентирована на простоту управления. Узнайте, как совместная работа трёх элементов контекста SELinux (политика, ядро и пространство пользователя) реализует RBAC и связывает пользователей Linux® с политикой TE.

Серж Е. Халлин, штатный программист, IBM

Серж Халлин (Serge Hallyn) — сотрудник Linux Technology Center корпорации IBM, специализирующийся на разработке ядра и системы безопасности Linux. Он получил степень Ph.D. в области компьютерных наук в College of William and Mary. Он является автором и соавтором ряда модулей безопасности. Сейчас он занимается реализацией поддержки функциональности виртуальных серверов, контрольных точек/рестарта приложений и разрешений POSIX для файлов.



13.03.2008

В Linux с повышенной степенью безопасности (Security-Enhanced Linux или SELinux) под уровнем управления доступом на основе ролей (RBAC) реализована политика обеспечения безопасности type enforcement. (Кроме того, в SELinux также независимо реализована многоуровневая система обеспечения безопасности (MLS), но она лежит за рамками темы этой статьи.) Поскольку сервер TE, обеспечивая детальное управление разрешениями, чаще всего находится на виду, он более широко известен: когда что-то идёт не так из-за неожиданного отказа в доступе, в этом, вероятнее всего, виноват TE. Домен безопасности процесса (область его влияния на систему) в TE определяется историей задачи и выполняемой на текущий момент программой.

Концепция RBAC обсуждается не так часто, как TE, и способ её интеграции с TE может вызвать некоторое замешательство. Как правило, RBAC понимают как задание уровня доступа, который могут получить пользователи определённых ролей. Однако SELinux определяет ролевой доступ в понятиях TE, поэтому цель RBAC в SELinux состоит в том чтобы обеспечить возможность управления привилегиями на основе ролей, которые может выполнять тот или иной пользователь, а затем - ограничить области влияния, в которые может входить роль, путём указания допустимых сочетаний ролей и доменов TE.

Понять работу этой схемы можно на простом примере обеспечения безопасности с помощью SELinux в системе бухгалтерского учёта с контрольно-кассовыми машинами. Одно и тоже решение представлено в двух различных средах (код для обоих случаев приведен в разделе Материалы для загрузки ):

  • Система SELinux, собранная в статье developerWorks "SELinux с нуля." Эта система демонстрирует, как связываются между собой некоторые элементы ядра и пространства пользователя.
  • Система Fedora Core 8. Система Fedora Core 8 (самая новая на момент написания этой статьи) иллюстрирует тесную интеграцию SELinux и RBAC.

Работа с ролями

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

Несмотря на то, что файлы политик в двух системах могут выглядеть по-разному, в обеих системах используется одна и та же схема данных и программа работы с кассовым аппаратом. Все данных сохраняются в папке /data, а доступ к ним осуществляется только из программы /bin/register.py. Сохранять данные с помощью программы register.py могут и управляющие, и кассиры. С целью упрощения кода набор функций ограничен. Кассир может записывать только данные своего кассового аппарата. Управляющий может сохранять значения других сотрудников и, если и управляющий, и кассир сохранили одну и ту же сумму кассы в конце дня, управляющий может подтвердить эти данные.

Когда кассир Боб (Bob) записывает данные, выполнив команду register.py bob 109.95 в 21:00 12 декабря 2007 г., создаётся файл /data/cashier_r/bob/12-12-2007, который содержит "bob 09:00 109.95." После этого, управляющий Мэри (Mary) сохраняет то же значение в 21:25, что приводит к созданию файла /data/mgr_r/bob/12-12-2007, содержащего "mary 09:25 109.95". И, наконец, Мэри командой register.py bob commit подтверждает значение в 21:27, что приводит к созданию файла /data/final/bob/12-12-2007, содержащего значения "mary 09:27 bob mary 109.95."

Если значения, указанные Бобом и Мэри, различаются, то Мэри не сможет подтвердить значение Боба. Мэри придётся переговорить с Бобом и выяснить точную сумму, после чего выполнить приведённые выше команды /bin/register.py с одинаковыми значениями. Новые значения будут добавлены к предыдущим, что облегчит последующее их изучение владельцем магазина, а команда /bin/register.py bob commit будет использовать последние введенные значения из /data/cashier_r/bob/12-12-2007 и /data/mgr_r/bob/12-12-2007.

Примечание: Для реализации управления доступом в приведенных здесь примерах используются средства SELinux. В наших примерах все пользователи просто получают возможность полного доступа ко всем файлам и папкам, вложенным в папку /data. Однако в реальной среде вам нужно будет организовать более серьезную защиту с помощью разрешений DAC. В какой-то момент менеджерам может потребоваться возможность создавать файлы в /data/mgr_r/bob/ и /data/final/bob/, что приводит к необходимости очень тонкой настройки разрешений групп UNIX®. Однако давайте для простоты будем реализовывать управление доступом исключительно средствами SELinux.

Сначала необходимо запретить доступ менеджеров и кассиров к файлам папки /data без использования программы register.py. Например, Боб будет входить в систему под ролью cashier_r типа cashier_t. При этом cashier_t не должен иметь доступа к /data. Для реализации этой схемы он должен стать типом cashier_register_t, а это можно сделать только выполнением /bin/register.py. Таким же образом Мэри входит в систему под ролью mgr_r типа mgr_t, но для того, чтобы получить доступ к папке /data, ей необходимо стать типом mgr_register_t, выполнив /bin/register.py.

Первая проверка прав доступа производится при входе в систему, когда модуль PAM решает, что Боб должен войти под ролью cashier_r. Она продолжается, когда сервер type enforcement в ядре SELinux не даёт bob_u:cashier_r:cashier_t войти в bob_u:cashier_r:cashier_register_t никак иначе, кроме как выполнив файл типа cashier_exec_t, который назначен администратором только файлу /bin/register.py.

Обеспечение безопасности продолжается и в самом register.py, когда он не позволяет кассиру подтверждать значения и сохранять значения для другого пользователя. Реализация этого механизма выполняется политикой SELinux —и политикой обеспечения безопасности кода ядра—которая запрещает cashier_register_t доступ к файлам, хранящимся в папках /data/mgr_r и /data/final.


Реализация системы учета для кассовых аппаратов

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

Смонтируйте образ диска (с отключенным образом qemu) с помощью команды:

mount -oloop,offset=32256 -t ext2 gentoo.img /mnt

Загрузите файл code_for_fromscratch.tgz из раздела Материалы для загрузки и разархивируйте его на образ диска, выполнив следующую команду:

tar zxf selinuxregister.tgz -C /mnt
umount /mnt

Запустите образ qemu:

qemu -hda gentoo.img -m 512 -vnc :3 -kernel bzImage \
      -append "ro root=/dev/hda1 -p"

После входа в систему необходимо скомпилировать и установить новую политику, а также установить новый модуль PAM:

cd /usr/src
checkpolicy -c 19 -o policy.bin policy.conf
cp policy.bin /etc/
rc-update add selinuxenforce default
cp /etc/pam.d/system-auth /etc/pam.d/system-auth.orig
cp /etc/pam.d/system-auth.new /etc/pam.d/system-auth

Пользователи SELinux создаются в политике, но для этого необходимо создать соответствующих им пользователей Linux:

adduser mary
passwd mary
  (passwd)
mkdir /home/mary
adduser boss
passwd boss
  (passwd)
mkdir /home/boss
adduser bob
passwd bob
  (passwd)
mkdir /home/bob

После этого создайте структуру папок для хранения данных:

mkdir /data
mkdir /data/cashier_r
mkdir /data/mgr_r
mkdir /data/final
chmod 777 /data/*

И, наконец, переименуйте файловую систему:

setfiles /usr/src/filecontexts /
poweroff

Теперь образ готов. Перезапустите его без флага -p , чтобы загрузилась политика SELinux:

qemu -hda gentoo.img -m 512 -vnc :3 -kernel bzImage \
      -append "ro root=/dev/hda1"

После этого войдите как root и попробуйте выполнить:

ls /data

В доступе отказано. Выйдите и войдите как bob (наш кассир). Зарегистрируйте новое значение, например:

register bob 25.22

А теперь попытайтесь обмануть систему, выполнив:

register bob commit

Не работает. Выйдите и войдите как Mary, наш управляющий:

register bob commit

Правильно, Мэри сначала нужно ввести своё значение:

register bob 27
register bob commit

Значения не совпадают. Не знаете, что ввёл Боб?

cat /data/cashier_r/bob/(day)

Ах да, просмотр запрещён. Нужно пойти и обсудить это с Бобом. Предположим, вы всё пересчитали, и он оказался прав. Поэтому:

register bob 25.22
register bob commit

Сработало. Теперь можно войти как root и:

cat /data/final/bob/(day)

Так вы увидите все введенные значения.


Более подробное описание type enforcement

Различные пользователи, работая с одной программой /bin/register, могут записывать и считывать различные файлы, доступ к которым без этой программы был бы закрыт. Это одно из ключевых понятий type enforcement: авторизованный контекст пользователя и выполняемого кода вместе определяют результирующую "область влияния" процесса на систему (домен TE).

На рисунке 1 показаны домены и типы системы:

Рисунок 1. Домены и типы
Домены и типы

Но что же не даёт Бобу войти в систему как управляющему, а Мэри - как кассиру? И ещё интереснее - как Хозяину удается войти под любым именем?

Первую задачу выполняет модуль PAM. Вкратце, PAM (pluggable authentication modules -- встраиваемые модули аутентификации) позволяют выполнять на различных этапах аутентификации различные фрагменты кода и обеспечивают гибкость в указании того, какие именно модули когда будут выполняться. Я добавил новый модуль, pam_ctx.so, его код можно найти в /usr/src/pam_ctx. Он выполняет поиск имени входящего пользователя по файлу /usermap.conf и определяет его контекст по умолчанию. Контекст по умолчанию для Боба - cashier_u:cashier_r:cashier_t. Контекст по умолчанию для Мэри mgr_u:mgr_r:mgr_t. А для Хозяина (Boss) контекст full_u:mgr_r:mgr_t. Обратите внимание, что все контексты состоят из трёх элементов, разделённых двоеточиями:

  • Последний элемент определяет домен, который и ограничивает права доступа пользователя к системе.
  • Второй элемент - это роль, которая ограничивает домены, в которые может входить пользователь.
  • Первый элемент - это "пользователь SELinux". Так же, как и роль и домен, этот элемент ограничивает роли, под которыми может войти процесс.

Модуль PAM устанавливает контекст, записывая его в файл /proc/$$/attr/exec, после чего запускает командный процессор соответствующего новому домену типа. Если посмотреть на исходный код политики, можно увидеть, что роль mgr_r может быть связана только с доменами mgr_t, mgr_register_t и rolechange_t. Роль cashier_r может быть связана только с доменами cashier_t и cashier_register_t. Аналогичным образом, пользователь SELinux mgr_u может связываться только с ролью mgr_r, а пользователь cashier_u – только с ролью cashier_r. Пользователь full_u может связываться и с mgr_r, и с cashier_r.

На рисунке 2 показано взаимодействие этих элементов.

Рисунок 2. Совместная работа элементов
Совместная работа элементов

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

user full_u roles { mgr_r cashier_r };

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

role cashier_r types { cashier_t cashier_register_t };

определяет элемент из средней строки и его связи с нижней строкой.

Но что не даёт Бобу просто записать "full_u:mgr_r:mgr_t" в /proc/$$/attr/exec? Несколько факторов. Первый связан с type enforcement. Возвращаясь к рисунку 1, если вы входите в тип cashier_t, мы можете входить только в cashier_write_t. Кроме того, политика SELinux задает возможные переходы между ролями. Итак, у нас есть:

allow mgr_r cashier_r;

указывающая, что процесс, запущенный под ролью mgr_r, может переключаться в допустимый контекст роли cashier_r. Однако строки:

allow cashier_r mgr_r;

нет, поэтому Боб не может перейти в другой контекст cashier_r .

Кроме того, мы не даем Мэри возможности входить в домен cashier_t. Если посмотреть на рисунок 1, можно увидеть, что сам переход к другому домену разрешен. А строка политики:

allow mgr_r cashier_r;

также разрешает переход к роли. Однако политика определяет, что для перехода сначала нужно выполнить вход в rolechange_t через точку входа /bin/role_change. Эта программа не позволит перезаписывать часть контекста пользователя SELinux. Таким образом, если пользователь войдёт под mgr_u:mgr_r:mgr_t, он не сможет перейти в роль cashier_r; для этого ему нужно войти снова как пользователь full_u, авторизуемый файлом /usermap.conf и обрабатываемый файлом pam_ctx.so.

Есть один момент, про который не стоит забывать при разработке политики. Обратите внимание, что внутренние средства управления переходами пользователя в SELinux отсутствуют. Такое управление должно быть реализовано путём привязывания пользователей SELinux к ролям и доменам, чтобы они не допускали перехода в контекст другого пользователя SELinux — если мы этого не желаем.

Давайте попробуем следующий вариант. Войдите как root и измените /bin/register.py, чтобы он сообщал контекст, в котором он работает. Мы добавим несколько строк в новый файл addme, после чего вставим этот файл в верхнюю часть /bin/register.py.

echo 0 > /selinux/enforce
cat > /root/addme << EOF
f=open("/proc/self/attr/current", "r")
print f.readlines()
f.close()
EOF
nano /bin/register.py

Теперь нажмите стрелку вниз и переведите курсор под строки import, нажмите Control-r дляRead File, и введите /root/addme. Нажмите Control-O для записи файла, Return для подтверждения его имени и Control-X для выхода. И, наконец, переведите SELinux в режим обеспечения безопасности.

echo 1 > /selinux/enforce
logout

Войдите под пользователем bob, сделайте явный запрос SELinux на смену домена и запустите register.py:

echo "full_u:cashier_r:cashier_register_t" > /proc/self/attr/exec
/bin/register.py bob 25

Теперь register.py работает как full_u:cashier_r:cashier_register_t! Вывод контекста в файл /proc/pid/attr/exec приводит к тому, что SELinux пытается перейти к этому контексту во время следующего выполнения. Конечно же, это сработает только в том случае, если переход будет допустимым. В данном случае переход будет допустимым, поскольку изменения ролей не происходит, и cashier_t, выполняющий файл типа cashier_exec_t, может перейти в cashier_register_t. Если вы попробуете сделать:

echo "full_u:mgr_r:mgr_register_t" > /proc/self/attr/exec
/bin/register.py bob 25

вы увидите, что доступ будет закрыт. И, наконец, вы можете попробовать:

echo "full_u:mgr_r:cashier_register_t" > /proc/self/attr/exec
/bin/register.py bob 25

На этот раз запрета доступа не было, но программа вывела контекст cashier_u:cashier_r:cashier_register_t. Откуда такое различное поведение? Поскольку full_u:mgr_r:mgr_register_t -- это допустимый контекст, и при следующем запуске действительно производится попытка смены домена, которая завершается неудачей. С другой стороны, full_u:mgr_r:cashier_register_t не был даже допустимым контекстом, поскольку mgr_r не может быть связан с cashier_register_t. Если бы мы проверили возвращаемое значение после вывода контекста в /proc/self/attr/exec, мы обнаружили бы ошибку.

echo "full_u:mgr_r:cashier_register_t" > /proc/self/attr/exec
echo $?
    1

Поэтому при следующем запуске register.py не выполнил запрошенную смену домена, а просто перешел в домен по умолчанию, что и было успешно сделано.

На этом этапе может показаться, что нашей цели можно было достичь с помощью одного TE, не используя роли и пользователей SELinux. Однако использование ролей и пользователей может значительно упростить дальнейшее администрирование. Это станет понятнее далее, когда вы увидите, как реализовать эту систему в Fedora Core 8.


Использование Fedora Core 8

По умолчанию Fedora 8 поставляется с включенной SELinux. В ней интегрированы новые технологии SELinux, в которых используются загружаемые модули политики, упрощающие настройку, и semanage, которая облегчает управление пользователями и RBAC. (Semanage служит для настройки некоторых параметров политик SELinux без изменения и перекомпиляции их исходного кода.)

Давайте начнём с совершенно неинтересной установки, почти не отличающейся от установки по умолчанию. Сначала загрузите Fedora-8-i386-DVD.iso (ссылку можно найти ниже, в разделе Ресурсы). Для удобства можно переименовать его в f8.img. Установите Fedora 8, используя его в качестве образа компакт-диска в qemu:

dd if=/dev/zero of=f8.img bs=1G seek=10 count=1
qemu -hda f8.img -cdrom f8.iso -boot d -m 1024 -vnc 3

Теперь запустите VNCviewer:

vncviewer :3

Выполните в окне VNC установку со всеми параметрами по умолчанию, с одним лишь исключением: На странице вопроса об устанавливаемых пакетах снимите отметку в поле "Офис и повседневные приложения" ("Office and Productivity") и установите её в поле "Разработка программного обеспечения" ("Software Development").

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

Откройте эту статью в браузере и загрузите архив исходного кода Fedora 8 (ссылку можно найти в разделе Ресурсы). Сохраните его в домашней директории как ~myuser/cash_register_f8.tgz.

Выберите в расположенном в левом верхнем углу меню "Applications" пункт System Tools > Terminal. После этого откройте командный процессор root, введя su - и указав пароль root. Теперь всё готово к настройке нашей системы бухгалтерского учёта с контрольно-кассовыми машинами.

(Примечание: если система работает слишком медленно, вы можете выйти из X-windows, введя runlevel 3. Это можно сделать командой /sbin/init 3. Вы всегда можете запустить X-windows снова, введя runlevel 5 в команде /sbin/init 5. На runlevel 3 просто войдите в систему на терминале под пользователем root.)

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

killall -9 yum-updatesd

После этого установите пакет разработки модуля политик SELinux:

yum install selinux-policy-devel.noarch

Теперь скопируйте директорию с примером модуля политики, перепишите в неё файлы политики кассового аппарата и скомпилируйте её:

cd /usr/share/selinux/
cp -r devel cash_register
cd cash_register
rm example.*
tar zxf ~myuser/cash_register_f8.tgz
mv register.py /bin
make

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

semodule -i cash_register.pp

Теперь создайте пользователей mary и bob:

adduser bob
adduser mary
passwd bob
passwd mary

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

semanage user -a -R cashier_r -P cashier bob_u
semanage login -a -s bob_u bob

semanage user -a -R mgr_r -P mgr mary_u
semanage login -a -s mary_u mary

Команда semanage user создаёт нового пользователя SELinux. Пользователь SELinux - это не имя пользователя Linux, а первый элемент контекста SELinux (возвращается командой id -Z), прикрепляемый к процессу и файлу. Если вы введете в окне терминала id -Z, результат может быть system_u или unconfined_u. Хотя имя пользователя Linux и имя пользователя SELinux могут быть идентичными, они никак не связаны между собой. Впрочем, процесс входа в систему использует имя пользователя Linux для выбора пользователя SELinux в вашем контексте обеспечения безопасности. Как мы уже говорили в предыдущем разделе, пользователь SELinux может быть связан с ограниченным числом ролей, а роль SELinux ограничена в доменах (типах)SELinux, с которыми она может быть связана.

Команда semanage user создает двух пользователей SELinux, mary_u и bob_u. Одновременно вы указываете роли, с которыми они могут быть связаны. Пользователь bob_u может использовать только роль cashier_r, а mary_u - только mgr_r. Кроме того, необходимо указывать префикс типа домашней директории пользователя. Для Мэри нужно указать mgr, которая будет расширена до mgr_home_dir_t для её домашней директории и mgr_home_t для находящихся в ней файлов.

Команды semanage login связывают имена пользователей Linux с пользователями SELinux. Мы указываем, что mary входит в систему как mary_u, а bob как bob_u.

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

mkdir /data
mkdir /data/final
mkdir /data/cashier_r
mkdir /data/mgr_r
chmod 777 /data/cashier_r
chmod 777 /data/mgr_r
chmod 777 /data/final

И, наконец, назначим новым пользователям все файлы, и созданные, и установленные, а также домашние директории:

fixfiles -f relabel /data /bin/register.py /home

Обратите внимание, что на этот раз мы не определяли в нашей политике пользователей SELinux. Это команды semanage создали пользователей и связали их с соответствующими ролями.

Если вы хотите только, чтобы bob входил как cashier_r, а mary - как mgr_r, всё будет отлично работать. Однако предположим, что вам нужно, чтобы пользователь charlie смог входить либо как mgr_r, либо как cashier_r. Для этого потребуется ещё несколько изменений. Сначала создайте пользователя:

adduser charlie
passwd charlie
semanage user -a -R mgr_r -R cashier_r -P mgr charlie_u
semanage login -a -s charlie_u charlie

Теперь укажите PAM, что charlie будет получать запрос о том, под какой ролью он хочет входить. Откройте файл /etc/pam.d/login и замените строку:

session required pam_selinux.so open

строкой:

session required pam_selinux.so open select_context

Тем самым вы сообщите модулю pam_selinux.so, что пользователь может выбирать контекст по умолчанию во время входа в систему. Теперь определите в системе тип, который будет использоваться для роли charlie_r по умолчанию. Во время входа в систему Чарли (charlie) сможет указать другую роль, отличную от назначаемой по умолчанию (mgr_r, поскольку её мы указали первой в команде semanage user). В качестве возможных вариантов можно указать любую роль, указанную с флагом -R при создании пользователя. При этом SElinux будет использовать тип по умолчанию, связанный с указанной ролью, поэтому необходимо указать тип для cashier_r:

echo "cashier_r:cashier_t" >> \
      /etc/selinux/targeted/contexts/default_type

Теперь, когда Чарли входит в консоль (либо нажав Ctrl-Alt-F2, либо указав runlevel 3, как было описано выше), у него будут спрашивать, под какой ролью он хочет войти. По умолчанию будет выбрана роль mgr_r, но он также может выбрать и cashier_r. Если он это сделает, он сможет записывать свои данные как кассир, но, согласно определенной нами политике, он не сможет прочитать файлы, хранящиеся в его домашней директории.

Обратите внимание, что register.py не запрещает Чарли записывать значения собственного кассового аппарата и впоследствии подтверждать их. Естественно, реализовать такое изменение очень просто.


Загрузка

ОписаниеИмяРазмер
Sample from-scratch codecode_for_fromscratch.tgz7KB
Sample Fedora Core 8 codecode_for_f8.tgz2KB

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=294832
ArticleTitle=Управление доступом на основе ролей в SELinux
publish-date=03132008