Права доступа

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

Права доступа

В качестве бонуса для тех, кто более-менее в танке, лектор расскажет ...

Азы. Азы состоят в следующем: пользователи в Линух-системе отличаются в первую очередь друг от друга двумя вещами: есть понятие login name и есть user id. Между ними существует путаница. В общем случае одно не есть другое. Тем не менее, если мелко всё это видеть, то можно приравнять одно к другому. Логин набираем при регистрации в системе, оно текстовое (повелось, что это маленькие латинские буквы), оно хранится в /etc/passwd с качестве первого поля. В этом же файле каждому имени соответсвует user id (вообще, реальная ситуация, когда несколько имён соотв одному user id). Зачем это нужно? Это нужно, чтобы разобраться, какой ресурс какому пользователю принадлежит. Этот user id --- некий идентификатор, указывающий на пользователя. Присваивается процессам и файлам всем, наличествующим в системе. Задача ФС: обеспечить достаточную информацию в поле метаинф. графы имя хранение user id. Что касается процессов, то это задача системы.

Зачем это надо: когда процесс что-то делает с файлом, вступает в силу информация какому пользователю принадлежит процесс и файл. Вот эти самые идентификаторы, которые участвуют, одинаковые на файл и процесс. По крайней мере, по умолчанию, не используются идентификаторы файла и правила, кто с ним что может делать, это может быть в качестве расширения, оно есть в посих ACL. Далее можно ввести такое бинарное деление: если uid процесса и файла совпадают, то будем считать, что процесс - хозяин файла, иначе файл для процесса чужой, и принятие решение будет на основании того, что файл чужой. Под файлом имеется в виду любой объект ОС. Здесь берём файлы как наиболее распространённый вид объектов. Какая проблема с простейшим бинарным делением: есть PUID, FUID, мой-немой файл. В случае, если мой файл, то разрешаю только чтение и запись, если чужой, то хозяин разрешил только чтение. Это субъект-субъектная модель доступа ... . Чем это плохо: иногда удобно организовать доступ сразу для нескольких уидов, например, хорошие пользователи имеют право писать, плохие --- нет. Не нарушая модели, вводятся пользователи. В /etc/passwd /etc/group записан список пользователей, членом группы которых они являются. Заметка: это не единственное место, с помощью PAM можно прикручивать произвольные бэкенды. Первая группа указывается в /etc/passwd, остальные опциональны. И дополнительно указываются права для группы.

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

Теперь временно отвлекаемся... Итак, очень простой, трёхступенчатый алгоритм: у файла есть UID и GID, у процесса есть владелец и список групп, членом которых он является. Если совпадают UID, то файл считает принадлежащим пользователю. Если UID не совпадают, но есть совпадающие группы, то файл считается принадлежащим группе. Иначе файл чужой. Итого, три категории доступа: владелец(u), группа(g), другие(o).

Всего прав три: чтение(r), запись(w) и использование(x). Что касается файлов, то очевидно, что означают эти права. Использование для разных файлов означает разное: если это файл в бинарном формате (ELF), то понятно, что значит запустить его: загрузить, передать. Если это ... , то можно зарегистрировать запускатель. Если файл текстовый, то шелл пытается его исполнить. Есть тонкость, как эти права интерпретируются для каталога: есть такая замечательная команда ls при листинге с ключом -l показывает в правах у директорий первую букву d. Что такое директория? Это специальный файл, он просто другого типа, тип каталог. В этом файле на самом деле хранятся всего две веще: список имён, которые считаются принадлежащими этому катологу, а так же, как этот файл лежит на диске. Уникальным идентификатором файла является не имя, которых может быть много, а индексный дескриптор. Буква r позволяет прочитать список имён. Буква w означает право изменить этот список. То есть, если есть право на запись в каталоге, то можно переименовать файл, удалить его. Если есть право на использование, то можно осуществить доступ к файлу в каталоге. Это значит, что: если права dr--, то какие файлы там лежат, увидите, а прочитать из файла не сможете, то есть, получить индексный дескриптор. Обратная ситуация: если есть только право на использование (--x), то нельзя получить список файлов, но если вы знаете имя, то можно его открыть. Обычно права на каталог есть и на использование и на чтение. В частности, если в каталоге, который ваам доступен на запись, есть файл, на который прав нет, то его можно удалить из этого каталога. Но это не обязательно значит, что это удаление файла, потому что это может быть не последнее имя файла.

Ещё одна особенность: есть общий каталог, который всем доступен на запись, то получается, что вася пупкин может удалить мои файлы. Есть такое специальное свойство: если каталог доступен на w и x, и у него стоит sticky bit (t), то из него могут удалить файлы только владельцы (так и работает tmp)

Команда chmod. Сначала умножим три права доступа на три категории доступа. Каждая категория может иметь три права, и получается 9 бит, например: rwxr-x--x. То есть владелец может делать всё, члены группы могут читать и исполнять, остальные только исполнять. Другой способ написания: восьмеричные права. Формат чмод: можно записать два вариант: просто числовой, либо такая штука: [ugoa]+[\+\-\=][rwx]+. например: chmod og+rx file. Мелкая деталь: у chmod есть ключик -R --- рекурсивно.

Отступление: про chown/chgrp и рута. Вообще говоря, можно изменить файлу хозяина и/или группу. Если что касается группы, то тут понятно: если вы владелец, то можете изменить группу. А можно ли сменить владельца своему файлу: нет. Тут надо подумать над такой штукой, как наследование идентификаторов. Если права

r--, то его не смогут прочесть владельцы и те, кто входит в группу. Другое дело, владелец может сменить это безобразие.

Любому процессу в системе присваивается uid. Шелл имеет ваш uid. А до логина он был чей? И этот откуда появлися? Ответ: есть root, у него uid=0, и ему права доступа не в указ. Те самые действие, которые нельзя привести с ФС, и поэтому пользователь не может разрушить, пользователь рут может совершить в доли секунды. Поэтому не рекомендуется работать под рутом часто и много. Процессу, уид которого равен 0, закон не писан. В частности, есть системные выхоывы setuid и setgid, которые позволяют их сменить. Т. о., когда вы рассказываете программе логин, свои логин и пароль, она вас идентифицирует и после того, как выясняется, что вы это вы, она запускает шелл, присваивая ему ваш уид и гид. При этом в системе существует строгий закон, что при порождении процессов сохраняется контекст, в том числе уид и гид. К счастью для системных администраторов, системные вызовы setgid и setuid могут вызывать процессы с uid=0.

Теперь у лектора такой странный вопрос/утверждние: вот пароль, он где хранится? /etc/shadow, он в отличие от /etc/passwd, недоступен на чтение никому, кроме рута. Там хранится не пароль, а хэш. Есть программа passwd, позволяет сменить свой пароль, то есть она не только читает, но и пишет в /etc/shadow. Некое несоответствие. В чём проблема? Как эта задача решается? Первый способ: если мы очень строго придерживаемся только правила, что данные можно только засекречивать, то в конце всё засекретится. Это неправильно. В данном случае нужно заиметь способ менять программе uid. Исторически это решалось так: если у программы есть бит s (setuid), то она не унаследует uid от пользователя, она унаследует его от файла. И если файл принадлежал руту, то у процесса будет uid 0. В правах это так: rws--x--x. По причине того, что это security-дырка, таких программ нужно делать как можно меньше. 10 лет назад большая часть атак делалась так: находился очередной buffer-overrun в очередной сетуидной программе, но сейчас этого меньше. Чуть менее опасная штука: setgid, rwx--s--x, типичное применение --- игры, чтобы с одной стороны нельзя было менять hiscores, с другой стороны нужно сохранять uid.

chow -R: маленькая часто встреч. потребность, которая решается одной командой: есть каталог, который скопировали от рута, надо поменять владельца: chown -R dir. Другой случай: скопировать файлы с сидюка, в результате у них владелец рут, да и права r-x

... Другой пример: допустим, есть каталог, который создали сами, и он такой: rwx

. Как сделать так, чтобы он был всем доступен на чтение, а каталоги ещё и на использование. Говорите chmod -R a+rX dir, X делает более хитрую операцию: утсанавливает его только в том случае, если у пользователя он стоит.

Дмитрий Левин зверски не любит сетуидные процессы, как видит, так сразу думает, как его сделать несетуидным. Есть два способа: сетуидный процесс нужен для доступа к каким-то объектам системы, к которым имеет доступ только рут, например, ip-stack. Один из способов: мы можем вычленить подмножество используемых ресурсов и изолировать его, используя chroot. chroot делает только одно: процесс, который запущен из под чрута, будет считать, что файловая система начинается с указанного каталога. Чем это хорошо? Даже если процесс сетуидный, то максимум, что он сделает --- испортит каталог. Единственная проблема в седующем --- такой чрутовый процесс надо патчить. Это более-менее универсалный способ, мы отодвигаем пробему, а не решаем её. Другой способ используется в способе хранения паролей.

В классическом варианте есть /etc/passwd/ и /etc/shadow root:shadow 640. Проблема не в том, что /usr/bin/passwd имеет доступ, проблема в том, что любой, кто решил написать очередную графическую логинилку, должен делать её сетуидный. И задача организовать это так, что нужно было пользоваться только сетгидом. Как это делается: есть каталог /etc/tcb root:shadow rwx--x---, в этом каталоге есть подкаталоги user/ user:auth rwxr-x---, root/, ... и там уже user.auth. И /usr/bin/passwd bin:shadow 2711. В результате, пассвд может воспользоваться /etc/tcb/, а дальше вы можете входить в свой каталог. Далее, если вы в группе auth, то можете прочитать весь shadow. Что для этого пришлось сделать: написать собственный PAM-модуль, и не один для того, чтобы это работало. Единственное, что на этом потеряли --- погрепать /etc/shadow.