Майкл Джонсон - Разработка приложений в среде Linux. Второе издание

• Название: Разработка приложений в среде Linux. Второе издание
• Автор: Майкл Джонсон
• Издательство: Вильямс
• Жанр: Программное обеспечение
• Год: 2007
• ISBN: 978-5-8459-1143-8

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

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

---

Для восстановления полномочий процесса необходимо использовать один или более из следующих методов: setuid(), setgid(), setgroups(). Этот прием эффективен только в том случае, если используется настоящая действующая файловая система и для всех сохраненных идентификаторах uid (или gid) установлены соответствующие значения. Если программа является setuid (или setgid), то процесс, вероятно, пожелает присвоить данным идентификаторам uid их сохраненное значение uid. Системные демоны, передающие управление другому пользователю после запуска от имени root, должны изменять пользовательские и групповые идентификаторы, а также очищать свой дополнительный групповой список. Более подробное описание того, как процесс может изменять свои сертификаты, можно найти в главе 10.

22.2.2. Получение вспомогательной программы

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

Применение маленьких вспомогательных программ приобрело широкую популярность в сообществе Linux. Библиотека utempter (обсуждаемая в главе 16) использует вспомогательную setgid-программу для обновления базы данных utmp. Эта программа очень внимательно проверяет правильность аргументов командной строки, а также контролирует, имеет ли вызывающее приложение разрешение на обновление базы данных utmp. Тем программам, которые предусматривают данную службу через вспомогательное приложение utempter, вообще не требуется никаких особых полномочий. До создания этой библиотеки каждая программа, использующая псевдотерминалы, была обязана быть setgid для той группы, которой принадлежит база данных utmp.

Еще одним примером вспомогательной программы может послужить программа unix_chkpwd, которая используется РАМ (Pluggable Authentication Modules — подключаемые модули аутентификации, подробнее рассматривается в главе 28). Пароли в большинстве систем Linux хранятся в файле, доступном для чтения только пользователю root. Это предотвращает словарные атаки на зашифрованные пароли пользователей[159]. Некоторые программы проверяют, действительно ли возле компьютера находится тот пользователь, который вошел в систему (программа xscreensaver может применяться для блокировки экрана до возвращения пользователя), но они обычно работают не как программы root. Вместо того чтобы делать такие программы setuid на root, дабы они могли проверить правильность пользовательского пароля, стандартная аутентификация РАМ Unix вызывает unix_chkpwd для подтверждения пароля. Таким образом, необходимость быть setuid на root существует только для программы unix_chkpwd. Это означает, что потребность создавать xscreensaver как привилегированную программу отпадает, а также что все слабые места в системе безопасности библиотек X11 не допускают локальной эксплуатации.

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

Довольно часто между главным приложением и вспомогательной программой передаются конфиденциальные данные. Например, для программы unix_chkpwd необходимо передавать незакодированный пароль пользователя для подтверждения его правильности. При передаче такой информации нужно принять некоторые меры предосторожности. Очень заманчиво использовать аргумент командной строки, однако это позволит любому пользователю, который в нужное время запустит ps, увидеть незакодированные пользовательские пароли. Если вместо этого для подачи данных применяется канал (обычно указанный в качестве стандартного ввода для вспомогательной программы), то во время передачи ни одна другая программа не сможет увидеть данные.

Вспомогательные программы также должны тщательно проверять тот факт, что вызывающая их программа имеет разрешение на выполнение запрашиваемого действия. Вспомогательная программа unx_chkpwd не позволяет программе проверять пароли ни одного пользователя, кроме того, который ее запустил. Здесь применяется свой собственный uid для подтверждения того, что активизирующая программа может проверять пароль пользователя. Вспомогательная программа utempter выполняет аналогичные проверки для того, чтобы убедиться, что программы не могут удалять терминалы из базы данных utmp, если только они не предназначены делать это.

22.2.3. Ограничение доступа к файловой системе

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

Анонимные ftp-серверы являются наиболее распространенными программами, использующими преимущества механизма chroot(). В последнее время он становится более популярным и в других программах, многие системные администраторы применяют команду chroot для того, чтобы перевести работу системных демонов в ограниченное окружение и предусмотреть проникновение "незваных гостей".

22.3. Общие бреши системы безопасности

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

22.3.1. Переполнение буфера

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

 1: /* bufferoverflow.с */

 2:

 3: #include <limits.h>

 4: #include <stdio.h>

 5: #include <string.h>

 6:

 7: int main(int argc, char ** argv) {

 8:  char path[_POSIX_PATH_MAX];

 9:

10:  printf("копирование строки длиной %d\n", strlen(argv[1]));

11:

12:  strcpy(path, argv[1]);

13:

14:  return 0;

15: }

16:

На первый взгляд код кажется довольно безопасным; хотя в итоге эта программа фактически даже ничего не делает. Она копирует строку, передаваемую пользователем, в фиксированное пространство стека, даже не проверяя, есть ли в стеке для этого свободное место. Попробуйте запустить эту программу с одним длинным аргументом командной строки (скажем, 300 символов). Это вызовет ошибку сегментации, когда strcpy() попытается записать информацию, превышающую пространство, выделенное для массива path.

Чтобы лучше понять, как происходит распределение памяти для программного стека, взгляните на рис. 22.1. В большинстве систем стек процессора растет вниз; то есть, чем раньше какой-либо объект размещается в стеке, тем больший адрес логической памяти он получает. К тому же первый элемент стека является защищенной областью памяти; любая попытка получить к нему доступ приводит к ошибке сегментации.