Защита системы с помощью fpm

Обеспечение защиты SUID-приложений

Менеджер файловых разрешений fpm (File Permissions Manager) позволяет ограничивать приложения путем изменения разрешений SUID или SGID, не позволяя им запускаться в сеансе текущего пользователя. Таким образом, эти приложения смогут запускать только привилегированные пользователи. Такой подход с использованием fpm является частью постоянно совершенствуемой политики безопасности IBM® AIX®, помогающей системным администраторам обеспечивать защиту систем.

Дэвид Тенсли, системный администратор, Ace Europe

фото Дэвида ТенслиДэвид Тенсли (David Tansley) — один из внештатных авторов IBM developerWorks. У него более 15 лет опыта администрирования UNIX-систем, а последние 8 лет он специализируется на AIX. В сферу его личных интересов входят бадминтон и Формула 1, но наибольшее удовольствие он получает, путешествуя на своём мотоцикле вместе с женой.



11.09.2013

Немного о SUID

SUID или SGID – это биты разрешений, устанавливаемые на исполняемые файлы для того, чтобы непривилегированные пользователи могли запускать их от имени их владельцев; как правило (но не всегда), эти разрешения действуют только во время работы приложений. В качестве примера рассмотрим команду для управления паролями (ее владельцем является пользователь root):

$ ls -l passwd
-r-s r-x r-x   1 root security   29122 Aug 8 00:16 passwd

Если бы я захотел изменить мой пароль, то для этого я бы выполнил предыдущую команду, которая позволила бы мне изменить пароль и записать его в зашифрованном виде в файл /etc/security/passwd (конечно, при этом выполняются и другие действия, но мы не будем рассматривать их здесь). Являясь обычным пользователем, я не смог бы обновить файл /etc/security/passwd. Но поскольку программа passwd имеет бит SUID и ее владельцем является пользователь root, то этот файл будет обновлен от имени пользователя root, а не от имени пользователя с моим идентификатором. В двух словах, непривилегированный пользователь может запускать приложение с установленным битом SUID от имени его владельца.

В AIX используются следующие два типа идентификаторов пользователей:

  • Реальный идентификатор пользователя.
  • Эффективный (привилегированный) идентификатор пользователя.

Эффективный идентификатор – это идентификатор владельца программы или файла. Если вернуться к примеру с программой passwd, то когда пользователь dxtans выполняет команду passwd, мы получаем следующие идентификаторы:

  • Реальным идентификатором пользователя является dxtans.
  • Эффективным идентификатором пользователя является root.

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

$ whoami
dxtans
$ id
uid=204(dxtans) gid=1(staff) groups=201(admin),208(sysmaint)

Чтобы установить для скомпилированной программы бит SUID или SGID, используйте команду chmod; в восьмеричном представлении используется первый октет, в котором:

  • 4 означает установку бита SUID.
  • Например, чтобы разрешить чтение и запуск программы для всех пользователей:

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

команда chmod 4555 <имя-файла> устанавливает для файла бит SUID:

r-s r-x r-x

команда chmod 6555 <имя-файла> устанавливает для файла бит SGID:

r-s r-s r-x

Для снятия бита SUID, установленного в первом примере, выполните следующую команду:

chmod 555 < file-name>

Если команда id запускается из приложения-упаковщика с битом SUID, владельцем которого является пользователь root и которое запустил другой (непривилегированный) пользователь, то будут показаны как реальный, так и эффективный идентификаторы. Следующий код на языке C вызывает команду id. Если для программы установлен бит SUID, то мы сможем увидеть оба идентификатора.

# cat idshow.c
int main(void)

{
system("/usr/bin/id");

}

Создайте файл с именем idshow.c с кодом из предыдущего примера от имени пользователя root и скомпилируйте его.

# gcc -o idshow idshow.c

Далее установите бит SUID для исполняемого файла.

# chmod 4555 idshow
# ls -l
-r-s r-x r-x 1 root system   52699 Nov 28 10:07 idshow

Теперь выполните команду id от имени другого пользователя (в этом примере используется учетная запись dxtans):

$ id
uid=204(dxtans) gid=1(staff) groups=201(admin),208(sysmaint)

Запустите только что созданную программу от имени другого пользователя:

$ ./idshow
uid=204(dxtans) gid=1(staff) euid=0(root) groups=201(admin),208(sysmaint)

Обратите внимание на то, что вывод команды id, вызванной из приложения idshow, содержит идентификатор пользователя dxtans. Тем не менее было также создано новое поле с именем euid, содержащее эффективный идентификатор пользователя предыдущей программы (в нашем случае пользователя root).

 Setting the SGID bit on directories that holds logs or documents, you can allow 
different group members to write to one directory, thus allowing the system administrator 
not having to go down the path of doing a chmod 777.

Внимательно подумайте о целесообразности использования SUID

Когда я говорю о битах SUID в этой статье, я также подразумеваю и биты SGID. Вообще говоря, некоторые SUID-приложения рассматриваются как потенциальная угроза безопасности. Такие приложения запускаются с эффективным идентификатором пользователя, и в большинстве случаев этим пользователем является root. Таким образом, полномочия пользователя root доступны всем пользователям SUID-приложений. Хотя сценарии командной оболочки, для которых были неосмотрительно установлены разрешения записи SUID, сегодня игнорируются ядром, они могли представлять собой серьезную проблему, поскольку делали систему полностью открытой для злоумышленников. Это лишь одна из причин, по которым AIX и большинство других систем UNIX® и Linux® игнорируют любые сценарии командной оболочки с установленными битами SUID или GUID, поскольку это является серьезной угрозой безопасности. Сегодня принято отключать или даже удалять некоторые системы и команды приложений с установленным битом SUID, а вместо этого использовать механизм sudo или полномочия на основе ролей для их запуска непривилегированными пользователями. Определенно это тот случай, когда необходимо придерживаться политик безопасности и ограничивать полномочия пользователя root. Это означает пересмотр некоторых SUID-команд, использующих такие полномочия. Операционная система AIX учитывает такую необходимость и содержит утилиту под названием fpm, удаляющую для приложений биты SUID. Утилита fpm контролирует количество приложений, для которых вы хотите установить или снять биты SUID или SGID. Хотя fpm является частью системы управления доступом на основе ролей (Role Based Access Control, RBAC) и реализацией команды aixpert для AIX 6, эта утилита также будет включена в состав версии 5.3 TL6. Несмотря на то, что всегда следует рассматривать использование всех SUID-приложений, я еще раз подчеркну, что существует довольно мало SUID-приложений, аналогичных команде passwd, которые можно было бы оставить без рассмотрения.

To locate all the SUID and SGID programs in your server, use the following find command:
# find / -perm -4000 -o -perm
-2000|more
/usr/bin/acctctl/usr/bin/acctras

Познакомьтесь с fpm

Утилита fpm позволяет ограничивать выполнение SUID-приложений путем удаления соответствующих битов SUID. В AIX предусмотрены следующие уровни безопасности, основанные на генеральной политике безопасности и типовых действиях, выполняемых непривилегированными пользователями:

  • Высокий уровень.
  • Средний уровень.
  • Низкий уровень.
  • Дополнительный пользовательский уровень.

Файлы, используемые утилитой fpm, хранятся в следующих директориях:

  • /usr/lib/security/fpm/data – в этой директории хранятся файлы, для которых изменяются системные биты SUID для различных уровней безопасности.
  • /usr/lib/security/fpm/custom – в этой директории хранятся определяемые пользователями файлы, для которых изменяются биты SUID,.

В директории usr/lib/security/fpm/data вы найдете следующие списки изменяемых файлов:

  • Для высокого уровня безопасности используется список high_fpm; для файлов, включенных в этот список, будут удалены все биты SUID/SGID.
  • Для среднего уровня безопасности используется список med_fpm; для файлов, включенных в этот список, будут удалены все биты SUID/SGID.
  • Для низкого уровня безопасности используется список med_fpm; для файлов, включенных в этот список, будут удалены все биты SUID.
  • Для уровня безопасности по умолчанию используется список default_list_example; для файлов, включенных в этот список, все биты SUID/SGID будут восстановлены до значений по умолчанию на момент инсталляции AIX.

В директории usr/lib/security/fpm/custom вы найдете следующие поддиректории, которые могут содержать пользовательские списки в зависимости от используемых уровней безопасности, для которых добавляются или удаляются биты SUID:

  • Default
  • High
  • Medium

Чаще всего команда fpm используется следующим образом:

fpm -l <level>  -p -v -f

Здесь:

  • level – уровень безопасности: высокий (high), средний (medium), низкий (low) или по умолчанию (default).
  • -p – предварительный просмотр результатов без фактического изменения файлов.
  • -v – подробный вывод; по умолчанию команда выводит минимум информации, если команда запущена без опции предварительного просмотра.
  • -f – имя файла списка, содержащего имена изменяемых файлов.

Пользовательская директория custom содержит список ваших собственных файлов, для которых необходимо изменять биты SUID.

Директория data содержит различные уровни безопасности, определенные в IBM AIX, и имена файлов говорят сами за себя. Вам следует просмотреть содержимое этих файлов, чтобы понять, какие приложения будут изменены. Всегда необходимо понимать последствия изменения битов SUID для того или иного приложения.

Все изменения, выполняемые утилитой fpm, записываются в log-файл, расположенный в директории /var/security/fpm/log.

При запуске fpm для указанного уровня безопасности также используется соответствующий список из директории custom, если таковой существует. Если, например, необходимо запустить fpm на среднем уровне безопасности, то будет использоваться список, содержащийся в директории /usr/lib/security/fpm/data/med_fpm_list, а также список, содержащийся в директории /usr/lib/security/fpm/custom/medium (если он существует).

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

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


Изменение разрешений SUID

Перед запуском fpm определитесь с необходимым уровнем безопасности. Например, если требуется реализовать средний уровень безопасности, то сначала просмотрите список /usr/lib/security/fpm/data/med_fpm_list, чтобы понять, для каких файлов будут изменены биты SUID.

После этого запустите fpm в режиме предварительного просмотра:

# fpm -l medium -p
chmod 0555 /sbin/helpers/jfs2/backbyinode
chmod 0550 /sbin/helpers/jfs2/diskusg
chmod 0555 /sbin/helpers/jfs2/restbyinode
..
..

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

# fpm -l medium
..
..

Один или несколько файлов уже защищены. Следовательно, текущие файловые разрешения могут не совпадать с разрешениями, устанавливаемыми по умолчанию. Если вам необходимо вернуть разрешения, которые были установлены до запуска этой команды, выполните команду /usr/bin/fpm -l default -f /var/security/fpm/log/12062011_17:48:35. После этого fpm продолжит удалять разрешения SUID.

Чтобы включить подробный вывод (как в случае запуска команды с опцией предварительного просмотра), используйте опцию v.

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

Теперь убедимся в том, что у некоторых файлов действительно были удалены биты SUID.

# ls -l /usr/sbin/chdev
-r-xr-x---    1 root     system        27496 Mar 22 2011  /usr/sbin/chdev

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

# fpm -s
Medium level security.

Следующая задача состоит в проверке того, что изменения SUID не повлияли на работу приложений и операционной среды.


Возврат к предыдущему состоянию

Если после перехода на средний уровень безопасности вы решите, что он не подходит для использования в вашей рабочей среде, то просто верните старые файловые разрешения. Log-файлы находятся в директории /var/security/fpm/log.

Содержимое log-файла имеет следующий формат:

Кликните, чтобы увидеть код

<значение восстанавливаемого suid в восьмеричном формате> <полный путь/имя-файла> <текущее разрешение в восьмеричном формате>

Простой пример содержимого log-файла приведен ниже.

# cat 12062011_17:48:35
4550 /usr/sbin/cfgmgr 0550
4550 /usr/sbin/chcod 0550
4550 /usr/sbin/chcons 0550
4550 /usr/sbin/chdev 0550
…
…

С помощью log-файла, сгенерированного на предыдущем шаге при переходе на средний уровень безопасности, можно восстановить систему до предыдущего состояния. Для этого используйте опцию -f и укажите уровень безопасности по умолчанию (default).

 # fpm -l default  -f /var/security/fpm/log/12062011_17:48:35

Теперь убедитесь, что изменения вступили в силу, просмотрев восстановленные файловые разрешения.

# ls -l /usr/sbin/chdev
-r-sr-x---    1 root     system        27496 Mar 22 2011  /usr/sbin/chdev

Далее проверим статус уровня безопасности. Мы увидим, что используется пользовательский (customized) уровень безопасности, а список SUID восстановлен из ранее созданной резервной копии.

# fpm -s
Customized level security.

Хотя в AIX определены списки изменяемых файлов для различных уровней безопасности, вы можете самостоятельно добавить или исключить из них определенные файлы. Я исключил довольно много SUID-приложений из списка для среднего уровня безопасности (файл /usr/lib/security/fpm/data/med_fpm_list) и использую его для стандартных настроек. Этот список хорошо подходит для системных администраторов.

Для сброса значений SUID к настройкам по умолчанию (т. е. к значениям SUID, действующим сразу после инсталляции AIX) используйте следующую команду:

# fpm -l default

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

# fpm -s
Default level security.

Создание собственного списка файлов, для которых необходимо изменять биты SUID

Добавить в список собственные файлы, для которых необходимо изменять биты SUID, можно несколькими способами.

  • Создать список, содержащий имена файлов, для которых необходимо удалить биты SUID.
  • Создать список, содержащий имена файлов, для которых необходимо восстановить биты SUID.

Директория /usr/lib/security/fpm содержит поддиректорию с именем custom, которая, в свою очередь, содержит следующие директории: default, medium и high.

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

<значение восстанавливаемого suid в восьмеричном формате> <путь/имя-файла>

Например, чтобы включить в файл с именем mydefaults собственные значения SUID для файлов grab_db2_audit и load_extract, выполните следующие команды:

# pwd
/usr/lib/security/fpm/custom/default

# cat mydefaults
4550 /usr/local/bin/grab_db2_audit
4550 /usr/local/bin/load_extract

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

Если вы восстанавливаете систему до уровня default, то при изменении разрешений SUID будет учитываться каждый файл, расположенный в этой директории (при условии, что он имеет правильный формат).

 # fpm -l default
…
...
chmod 4550 /usr/sbin/invscoutd
chmod 4550 /usr/local/bin/grab_db2_audit
chmod 4550 /usr/local/bin/load_extract

Чтобы снять биты SUID с указанных приложений, создайте список, содержащий имена соответствующих им файлов. Этот файл имеет следующий формат:

<полный путь/имя-файла>

Например, содержимое моего файла mydefaults2 может быть таким:

# pwd
/usr/lib/security/fpm/custom/med

# cat  mydefaults2
/usr/local/bin/load_extract
/usr/local/bin/grab_db2_audit

В директории /usr/local/bin располагаются два файла; их биты SUID еще не сняты программой fpm:

# pwd
/usr/local/bin

# ls -lt |head
total 9512
-r-sr-x---    1 root     app1          30681 Dec 05 22:17 load_extract
-r-sr-x---    1 aixdev   app1          52697 Dec 05 18:08 grab_db2_audit

Теперь запустим команду fpm для изменения уровня безопасности на medium. Убедимся, что уровень безопасности был изменен, а затем проверим, были ли сняты биты SUID для пользовательских файлов, которые мы указали ранее.

# fpm -l medium

# fpm -s
Medium level security.
# ls -lt |head
total 9512
-r-xr-x---    1 root     app1          30681 Dec 05 22:17 load_extract
-r-xr-x---    1 aixdev   app1          52697 Dec 05 18:08 grab_db2_audit

Обратите внимание на списки контроля доступов (ACL)

Важный момент, на который необходимо обратить внимание, заключается в том, что применение команды fpm к файлу списка контроля доступов (ACL) отключает для него данный атрибут. Хотя атрибуты ACL остаются не затронутыми, данный файл отключается по причине того, что для него выполняется восьмеричное преобразование chmod, в результате чего атрибут ACL сбрасывается. Посмотрим на ACL-файл с именем load_extract до того, как будет выполнена команда fpm:

# aclget load_extract
*
* ACL_type   AIXC
*
attributes: SUID
base permissions
    owner(root):  r-x
    group(app1):  r-x
    others:  ---
extended permissions
    enabled
    deny     r-x     u:alpha

Мы видим, что для файла установлены биты SUID и ACL, и что пользователь alpha не имеет разрешений на его запуск. Также убедимся в том, что файл действительно является ACL-файлом – для этого в следующем примере обратите внимание на символ + в конце строки атрибутов:

# ls -lUt |head
total 9512
-r-sr-x---+    1 root     app1          30681 Dec 05 22:17 load_extract

Если файл load_extract будет обработан командой fpm, то для него будут отключены атрибуты ACL:

#  fpm -l medium
# fpm -s
Medium level security.

# ls -lUt |head
-r-xr-x---    1 root     app1          30681 Dec 05 22:17 load_extract

Обратите внимание на то, что символ + уже не присутствует в листинге, поскольку команда fpm сбросила атрибут ACL. В этом можно убедиться при помощи команды aclget.

# aclget load_extract
*
* ACL_type   AIXC
*
attributes:
base permissions
    owner(root):  r-x
    group(app1):  r-x
    others:  ---
extended permissions
    disabled
    deny     r-x     u:alpha

Не забудьте составить список всех ACL-файлов и заново включить для них атрибут ACL с помощью команды acledit.


Заключение

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

Ресурсы

Комментарии

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=AIX и UNIX
ArticleID=944734
ArticleTitle=Защита системы с помощью fpm
publish-date=09112013