T-бит, SUID и SGID

Поработав с Linux какое-то время, вы, вероятно, обратите внимание, что кроме обычных «rwx» в правах доступа к некоторым файлам встречаются также буквы «s» и «t»:

>ls -ld /usr/bin/crontab  /usr/bin/passwd  /usr/sbin/sendmail  /tmp
drwxrwxrwt   5 root   root   1024 Jan 1 17:21 /tmp
-rwsr-xr-x   1 root   root   0328 May 6 1998 /usr/bin/crontab
-r-sr-xr-x   1 root   bin     5613 Apr 27 1998 /usr/bin/passwd
-rwsr-sr-x   1 root   mail   89524 Dec 3 22:18 /usr/sbin/sendmail

Что же это такое, и каким битам соответствуют эти «s» и «t»? В действительности, битовая маска прав доступа к файлам содержит 4 группы по 3 бита в каждой. Команда chmod 755 это всего лишь краткая запись полной формы команды: chmod 0755.

t-бит

t-бит (иногда его называют стики-бит («sticky bit») или «липучка») используется только с каталогами. Как видно из нашего примера, этот бит установлен для каталога /tmp.
Обычно (т.е. если t-бит для каталога не установлен) файл из этого каталога может удалить любой пользователь, имеющий к данному каталогу доступ по записи. Т.е. если у вас есть каталог, куда любой пользователь может поместить файл, то любой пользователь может и удалить файлы из этого каталога.

t-бит изменяет это правило. Если для кататлога установлен t-бит, то удалить файл из такого каталога может только владелец этого каталога или файла. Установить t-бит можно при помощи команд chmod a+tw или chmod 1777. Например:

Алиса создает каталог с установленным t-битом:
>mkdir mytmp
chmod 1777 mytmp
Боб помещает свой файл в этот каталог:
>ls -al
drwxrwxrwt   3 alice    users  1024 Jan  1 20:30 ./
-rw-r--r--  1 bob   users     0 Jan  1 20:31 f.txt

Теперь этот файл может удалить только Алиса (владелец каталога) или Боб (владелец файла), а вот Текс этого сделать не в состоянии:

>whoami
tux
rm -f f.txt
rm: f.txt: Operation not permitted

S-бит — установка для пользователя

Все процессы в Linux выполняются с некоторым идентификатором пользователя (user-ID). Это позволяет управлять доступом процесса к ресурсам системы, файлам и т.п. Но для каждого процесса можно установить два user-ID: фактический и эффективный. Правами доступа к файлам заведует именно эффективный user-ID. Сохраните следующий скрипт idinfo и сделайте его выполнимым (chmod 755 idinfo):

#!/bin/sh
#idinfo: Print user information
echo " effective user-ID:"
id -un
echo " real user-ID:"
id -unr
echo " group ID:"
id -gn

Выполнив скрипт можно узнать текущие значения эффективного, фактического и группового user-ID (например для пользователя Alice):

 effective user-ID:
alice
 real user-ID:
alice
 group ID:
users

Когда этот скрипт запустит Текс, то он увидит что-то подобное. Вывод этого скрипта зависит только от того, кто его запускает и никак не связан с тем, кто является владельцем файла.
По соображениям безопасности s-бит применим только для бинарных файлов, но не для скриптов (за исключением скриптов на языке Perl). Поэтому создадим простую С-программу, которая будет вызывать наш скрипт:

/*suidtest.c*/
#include 
#include 
int main(){
/*secure SUID programs MUST
*not trust any user input or environment variable!! */
char *env[]={"PATH=/bin:/usr/bin",NULL};
char prog[]="/home/alice/idinfo";
if (access(prog,X_OK)){
    fprintf(stderr,"ERROR: %s not executable\n",prog);
    exit(1);
}
printf("running now %s ...\n",prog);
execle(prog,(const char*)NULL,env);
perror("suidtest");
return(1);
}

Скомпилируем программу:

"gcc -o suidtest -Wall suidtest.c"

и установим для ее владельца s-бит:

>chmod 4755   suidtest
или
>chmod u+s   suidtest

Запускаем. Ничего не случилось? А теперь запустим эту программу от имени другого пользователя!.

Файлом suidtest владеет Алиса и, на первый взгляд, файл с установленным s-битом ведет себя также, как и обычный файл (т.е. с битом «x»). Однако при выполнении такого файла происходит подмена фактического user-ID (т.е. user-ID пользователя, запустившего программу) на эффективный user-ID, или user-ID владельца файла! Если несчастный Текс попробует запустить эту программу, то он увидит:

>ls -l suidtest
-rwsr-xr-x   1 alice   users   4741 Jan 1 21:53 suidtest
>whoami
tux
running now /home/alice/idinfo ...
effective user-ID:
alice
real user-ID:
tux
group ID:
users

Как мы видим, это очень мощное средство, особенно если s-бит установлен для программ, владельцем которых является root. Любой пользователь, запустив такую программу, получит права суперпользователя и сможет делать то что раньше было доступно только root’у.!
А теперь несколько слов о безопасности. Когда вы создаете программу и устанавливаете для нее s-бит, убедитесь в том, что она может быть использована только для того, для чего вы ее сделали. Пути доступа должны быть жестко прописаны в коде программы. Не используйте переменные окружения и функции, которые работают с переменными окружения и могут их изменять. Никогда не полагайтесь на честность пользователя и проверяйте каждый его шаг — байт за байтом, сравнивайте все аргументы, вводимые пользователем или параметры конфигурационных файлов с допустимыми значениями.

Когда владельцем SUID-программы является root то можно устанавливать и фактический и эффективный user-ID используя функцию setreuid().

Прием с подстановкой user-ID часто используется для того, чтобы дать обычным пользователям доступ к некоторым функциям администратора системы. Например, если вы имеет права root, то можете модифицировать нашу программу suidtest.c чтобы разрешить любому пользователю запускать скрипты ppp-on/ppp-off на вашей машине.

S-бит установленный для группы

Исполнимые файлы у которых s-бит установлен для группы запускаются с эффективным group-ID владельца файла. Процесс подстановки эффективного group-ID вместо фактического group-ID очень похож на тот, что был описан выше.
Когда групповой s-бит устанавливается для каталога, то каждый файл, создаваемый в этом каталоге будет отнесен к группе, к которой относится и сам каталог (но не пользователь, создающий этот файл). Например, Алиса включена в две группы:

>id
uid=550(alice)  gid=100(users)  groups=100(users),6(disk)

Обычно, все файлы, которые создает Алиса, относятся к группе users. Но если каталог отнесен к группе disk, то и все файлы, которые Алиса создаст в этом каталоге, будут отнесены к группе disk и получат соответствующий group-ID.

>chmod 2775 .
>ls -ld .
drwxrwsr-x  3 tux   disk     1024 Jan 1 23:02 .
Если Алиса попробует создать новый файл, то он будет отнесен к группе disk
>touch newfile
>ls -l newfile
-rw-r--r--   1 alice    disk      0 Jan 1 23:02 newfile

Это хорошая возможность для управления файлами в каталогах, к которым имеют доступ члены некоторой команды пользователей. Можно быть уверенным, что group-ID, для всех файлов этого каталога будет установлен правильно и все члены команды будут обладать равными правами по доступу к файлам (На уровне группы. Прим. перев.). Это особенно актуально если для файлов пользователей устанавливается маска «по умолчанию» umask 027, т.е. для не-членов группы файлы полностью недоступны.


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