Дополнительные флаги

Ещё одна особенность: есть общий каталог, который всем доступен на запись, то получается, что вася пупкин может удалить мои файлы. Есть такое специальное свойство: если каталог доступен на 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.

Сведения о ресурсах

CategoryLectures CategoryCmc CategoryUneex