Сегодня я наткнулся на этот пример, и мне стало интересно, насколько надежны права доступа к файлам Linux для сокрытия информации.
$ mkdir fooledYa
$ mkdir fooledYa/ohReally
$ chmod 0300 fooledYa/
$ cd fooledYa/
$ ls
>>> ls: cannot open directory .: Permission denied
$ cd ohReally
$ ls -ld .
>>> drwxrwxr-x 2 user user 4096 2012-05-30 17:42 .
Сейчас я не эксперт по ОС Linux, поэтому не сомневаюсь, что кто-нибудь объяснит мне, что это совершенно логично с точки зрения ОС. Тем не менее, мой вопрос все еще остается в силе: можно ли обмануть, а не взломать ОС, чтобы она позволяла вам просматривать информацию о файлах / индексных дескрипторах, которые вы не должны? Что, если бы я дал команду chmod 0000 fooledYa, мог бы опытный программист найти способ прочитать файл, например fooledYa/ohReally/foo.txt?
$ ls -lhd fooledYa/
d-wx------ #snip
Перво-наперво: я могу писать в каталог (делать новые записи) и могу выполнять (cd) в каталог. Однако я не могу читать каталог. Что это значит, не интуитивно понятно.
Когда вы работаете с каталогами в системах Unix, каталог указывает на inodes, которые отличаются от записи указателя. Возможность отслеживать ссылки вниз по дереву каталогов контролируется eXecute немного. Для каждого уровня каталогов вниз по дереву операционная система проверяет бит выполнения перед переходом на следующий уровень.
Между тем Read bit контролирует доступ к содержимому inode. Все, что вы можете ссылаться на свою файловую систему, - это запись inode. Каталоги или файлы, они указывают на индексный дескриптор.
ls -ldi fooledYa/
121100226 d-wx------ #snip
В этом случае индексный дескриптор каталога - 121100226. Разрешение на чтение указывает, могу ли я получить доступ к этому файлу индексного дескриптора в пользовательском пространстве для чтения его содержимого. Содержимое inode каталога - это ссылки на другие файлы. Ядро всегда может это прочитать. Вы, как пользователь, управляете решениями ядра относительно записей в нем.
Таким образом, поскольку ls пытается прочитать содержимое, чтобы сказать мне, что там (как проверено Read flag), это отклонено. Поскольку у меня все еще есть eXecute однако, ядро позволит мне переходить к файлам, которые я указываю, если все каталоги над файлом, который я хочу, разрешают мне eXecute в них, независимо от того, могу ли я их прочитать, чтобы увидеть, на что ссылается.
Итак, чтобы подвести итог для каталогов, подумайте о выполнении как о главном разрешении. Без него вы не сможете войти в каталог, чтобы что-либо делать. После этого считайте их файлом из двух столбцов. Если у вас есть разрешение на чтение, вы можете видеть записи. Если у вас есть разрешение на запись, вы можете добавлять или удалять записи. Если у вас нет этих двух разрешений, но у вас есть выполнение, вы можете делать ссылки на записи в списке, но не можете читать список.
Это хорошие иллюстративные примеры inodes и того, как они представляют ссылки на каталоги и блок файлов на дисковых ссылках: http://teaching.idallen.com/dat2330/04f/notes/links_and_inodes.html
Как вы и ожидали, многие объяснили, насколько ваш пример совершенно логичен. «Работает так, как задумано».
Чтобы ответить на ваш вопрос, это было бы вопиющей ошибкой ядра, если бы вы могли обмануть ОС, позволив вам просматривать информацию о файлах / индексных дескрипторах, чего вы не должны. Права доступа к файлу связаны с самим индексным дескриптором и применяются, когда вы действительно пытаетесь открыть файл. Если вы не поняли это из других ответов, я укажу, что у каталога есть индексный дескриптор, как и у любого файла, просто разрешения означают что-то немного (или сильно) другое в применении к каталогам.
Права доступа к файлам являются оригинальным механизмом безопасности Unix и по-прежнему являются неотъемлемой частью безопасности Unix / Linux. Любой сценарий, который вы можете придумать и который выглядит так, будто вы обманули систему, почти наверняка является случаем, когда вы не понимаете, что такое правильное поведение. Если вы найдете законный способ обхода безопасности, даже при взломе, это будет считаться критической ошибкой безопасности и одной из самых приоритетных задач для исправления.
Например, если вы смогли прочитать содержимое файла, который вы не должны были читать, вы могли бы украсть (хешированные) пароли всех пользователей и личные ssh ключ для системы и приват ssh ключи всех пользователей системы (хотя, надеюсь, они будут зашифрованы) и через индексный дескриптор устройства прочитать все содержимое системной памяти (и многое другое). Было бы менее опасно, если бы вы могли читать информацию о файлах, которую не должны были, но это все равно будет считаться серьезным нарушением.
Я считаю, что вас вводит в заблуждение то, что каждый каталог ниже / имеет как минимум две ссылки на него: запись каталога в его родительском элементе и . внутри себя (плюс любые .. ссылки из дочерних каталогов). Когда вы печатаете ls -ld . это смотрит на . ссылка в текущем каталоге (который у вас есть разрешение на чтение), а не ссылка на текущий каталог из родительского каталога (который у вас нет разрешения на чтение).
Для + x я нашел самый простой способ понять, как это работает с каталогами, - это разрешение "попасть в" каталог. Вы вообще не можете попасть в каталог без + x, даже если у вас есть доступ для чтения и записи к нему. Если вам не разрешено входить в каталог, вы не можете попасть в подкаталоги, независимо от того, установлен ли в них + x или нет. Итак, если у вас есть fooledYa/ohReally/foo.txt и fooledYa это chmod 0000, предполагая, что никакая другая система ACL не отменяет файловый режим, только root сможет войти в ohReally/ или открыть foo.txt даже если они знают путь к файлу, не перечисляя содержимое каталога.
Одна из странностей этих разрешений заключается в том, что если каталог + r, но не + x, у вас есть разрешение на чтение содержимого каталога, поэтому вы можете «заглянуть внутрь» извне и прочитать список файлов в каталоге, но без + x вы не сможете попасть в каталог для доступа (stat) отдельные файлы. Поэтому, если вы попытаетесь ls -l в таком каталоге вы получите имена файлов, но все остальные поля для размеров файлов, режимов, владения и т. д. будут ? Метки.