четверг, 18 сентября 2008 г.

Новый подход к назначению разрешений на файловую систему в Win2008/Vista

Мне не так давно (ага, годика пол назад ;) ) поступил вопрос от тогда еще совсем не MVP Александра Станкевича – частого участника посиделок у Паши Нагаева, теперь уже MVP и всегда хорошего человека и специалиста. Вопрос звучал как-то так: «а почему теперь на многих папках в Windows есть пары разрешений для одного и того же объекта и одного и того же участника безопасности?». Я долгое время не мог добраться до ответа, но, в процессе подготовки к выпуску своего поста об SDDL, который скоро опубликую, наткнулся на, как мне кажется, ответ.

Если говорить сначала о самом вопросе, то вот что имеется в виду:

image

Как видно, здесь есть две записи для каждого пользователя/группы. Если же заглянуть внутрь, то окажется, что одна предоставляет права на саму папку, а вторая уже описывает права на подобъекты и наследование этих прав

 

 

 

image image .

Собственно, это и есть ответ (IMHO) на поставленный вопрос: Двойная запись служит для разделения управления разрешениями собственно папки и ее содержимого. То есть одна запись описывает разрешения на саму папку, а вторая те разрешения, которые наследуют от нее дочерние объекты. Разница в данном конкретном случае такая:

image

Как видно, на саму папку не выдано право изменения подпапок, изменения разрешений и take ownership, в то время, как вторая запись, описывающая поддерево дает полный доступ. В чем плюс? Не дается лишних прав на подобъекты (или наоборот, на сами объекты), унифицируется работа с разрешениями, да и вообще удобнее, если уж приспичит поковырять там что-то. В общем, я, пожалуй, перейму и для себя – надо будет попробовать именно так выдавать пермиции.

В общем, мне кажется, что я ответил на вопрос (кстати, спасибо, Stanky, сам я внимания и не обратил ;) )

2 комментария:

Stanky комментирует...

Спасибо, конечно, что даже спустя полгода не забыл про мой вопрос:-)!
Но, честно говоря, ответа на него я так и не получил.
Как мне кажется, ты просто не до конца понял, в чём именно он заключается;-).

Постараюсь сформулировать ещё раз:
Сейчас права разбиты на две части – Только эта папка и Для подпапок и файлов. Создавать файлы/папки могут TrustedInstaller, SYSTEM и Administrators. Кто бы из этой троицы ни создал файл/папку, он получит полный доступ к объекту.
По поводу того, что на саму папку нам не даны права (Удаление подпапок и файлов, Смена разрешений и Смена владельца):
Удаление подпапок и файлов – его отсутствие нам ничем не мешает, ибо на сами объекты (подпапки и файлы) у нас есть право Удаление.
Смена владельца – тоже не препятствие ни для SYSTEM ни для Administrators. Такое право у них (Administrators) есть по умолчанию и его отсутствие на самой папке ничуть не мешает нам стать владельцами.
Смена разрешений – ну а раз уж мы можем стать владельцами, значит сможем и изменять права!

Внимание вопрос: так в чём же глубинный смысл такого разделения прав доступа, если они ни чему не препятствуют?

KomatoZo комментирует...

Угу. Значит по поводу того, что на остальные объекты внутри у нас есть права - не всегда правда, потому что наследование оторвано в большинстве случаев. Из этого получается, что права, которые даны на подобъекты будут присвоены только вновь образованным объектам.
Дальше - больше, при изменении прав в ACE, на папку не трогается ничто внутри.
По поводу разрешений для Администраторов и System. Да, они все могут поменять. Давай им дадим везде все права по умолчанию. Слабо? Мне слабо =) Потому что тогда достаточно будет просто запустить что-то от имени систем и оно может (неважно, злонмеренно или по ошибке) все нафиг порушить. С такими разрешениями мы хотя бы защищаемся от ошибок. Потому что на подавляющее большинство файлов в папке, скажем, system32 стоят разрешения read и read & execute для всех, кроме Trusted Installer.
Потому ответ на твой вопрос: они препятствуют ошибочному снесению/модификации объектов. Помимо того, они все-таки защищают, хоть и слабо от различных угрох, потому что я помню мало массового софта, который заморачивается изменением владельца и/или разрешений на объекты файловой системы.
А то, что от администратора защиты нет, кроме аудита, иначе он не администратор... Факт известный и при текущей архитектуре точно неизменный. А другую я придумать пока не в состоянии =)