Журнал LinuxFormat - перейти на главную

LXF108:DrBraun1

Материал из Linuxformat
Перейти к: навигация, поиск

Введение в Posix

Capabilities Почти удавшаяся попытка комитета Posix скорректировать старую модель Unix, где root – это «царь и бог».

Передо мной – статья Денниса Ритчи [DennisRitchie] (отец-основатель Unix), опубликованная в Bell System Technical Journal [внутренний журнал для научных сотрудников Bell Labs/Alcatel-Lucent, который выходит раз в квартал с 1922 г., – прим. пер.] от июля 1978 г., где он описывает данную модель – и даже эта статья называется «Взгляд в прошлое» (A Retrospective)! Модель, несомненно, довольно грубая, и Ритчи признает, что «классификация недостаточно хороша, чтобы отвечать нуждам всех инсталляций». Одно из свойств модели Unix – концепция суперпользователя root, имеющего право выполнить любую операцию и получить доступ ко всем файлам. Это очень рискованный способ предоставления привилегий, и Ритчи пишет: «Мы отдаем себе отчет в том, что сама идея суперпользователя – это теоретический, а чаще практический, недостаток любой схемы защиты». Проблема в том, что желающим сделать нечто безобидное (например, установить время) приходится давать права на все что угодно. Но как бы там ни было, эта древняя модель безопасности была унаследована Linux и отлично работает более 30 лет. Хотя было несколько попыток расширить ее.

Стандарт, которого не было

В 1997 году комитет по стандартам (POSIX 1003.1e) создал черновую версию различных расширений механизма защиты UNIX/Linux. В одном из них, названном «разделение привилегий», определялся набор из 30 специальных возможностей [capabilities], которые могут быть у процесса. Идея заключалась в том, чтобы предложить более тонкий механизм по сравнению с обычным разделением «root или не root».

Увы, комитет POSIX лишился спонсорства, и стандарт так и остался черновиком. Однако специфика- ция была полностью завершена, и фактически даже реализована в ядре Linux. Подробности см. в man 7 capabilities.

Возможности Posix навскидку

Возможность Описание
CAP_CHOWN Разрешить менять пользователя и группы владельца
CAP_DAC_OVERRIDE Игнорировать проверку прав на чтение, запись и выполнение файлов. (DAC = «дискреционное управление доступом – discretionary access control».)
CAP_KILL Игнорировать проверку прав на отправку сигналов процессам.
CAP_NET_RAW Разрешить использование сокетов RAW и PACKET.
CAP_SYS_BOOT Разрешить использование системного вызова reboot().
CAP_SYS_MODULE Разрешить загрузку и выгрузку модулей ядра.

В таблице показаны не все возможности: просто дано представление об общей идее.

Персональные инструменты
купить
подписаться
Яндекс.Метрика