Удосконалені ACL у Windows Vista та Windows Server 2008, Windows IT Pro

У нових версіях Windows з'явилися невеликі вдосконалення для роботи зі списком керування доступом Access Control List (ACL). Поліпшення часто бувають пов'язані з фундаментальними змінами застосування дозволів, тому важливо зрозуміти, як вони впливають на безпеку. ACL являє собою список дозволів (наприклад, Administrators — Full Control, Users — Read), призначених розділу реєстру, папці NTFS або іншому об'єкту. Кожен запис у списку ACL, наприклад Users — Read, називається елементом керування доступом Access Control Entry (ACE).

У цій статті розглядаються зміни у роботі зі списком ACL у Vista та Windows Server 2008 та наступних версіях та можливість більш надійно захистити операційну систему та спростити керування безпекою.

Права власника

Однією з найважливіших змін у Vista та Windows Server 2008 є додавання нового ідентифікатора безпеки (SID), що називається OWNER RIGHTS. У нових операційних системах будь-які діючі дозволи, які застосовуються до призначеного власнику об'єкта, мають пріоритет перед володінням. Якщо власник папки не має права запису, він не зможе скопіювати файл до цієї папки. Функція контролю облікових записів (UAC) не підвищує дозволи. Необхідно змінити список ACL для папки, і це може зробити власник об'єкта, якщо тільки права власника за замовчуванням не були змінені.

Ідентифікатор безпеки OWNER RIGHTS дозволяє змінитицей порядок. Припустимо, власник папки має лише роздільну здатність READ для списку ACL. Якщо додати елемент ACE, в якому ідентифікатор безпеки OWNER RIGHTS має дозвіл WRITE (екран 1), можна буде скопіювати новий файл у папку.

Якщо після цього спробувати змінити папку ACL, з'ясується, що втрачено право доступу для її зміни, оскільки призначення дозволу WRITE ідентифікатору безпеки OWNER RIGHTS не дозволяє змінити список ACL. Якщо замість WRITE задати FULL CONTROL, можна буде скопіювати файл і змінити дозволи папки. Однак, якщо змінити власника об'єкта, OWNER RIGHTS не передається новому власнику автоматично. Тому, якщо користувач позбавив себе права змінювати дозволи, можна змінити власника та усунути будь-які проблеми, пов'язані з дозволами. OWNER RIGHTS ACE залишається, але наслідування присвоюється режим Nothing, що фактично скасовує всі вказані в елементі дозволу.

Ідентифікатор безпеки OWNER RIGHTS у Vista та Windows Server 2008 дозволяє адміністратору призначати права володіння користувачеві або групі, але надає механізм, за допомогою якого користувачеві або групі можна заборонити змінювати дозволи для об'єкта. Ідентифікатор безпеки OWNER RIGHTS дозволяє спростити призначення прав, якщо потрібно надати користувачеві або групі можливість створювати нові папки та файли, але не змінювати дозволи для них, додаючи належним чином елемент ACE для OWNER RIGHTS.

Якщо користувач створює об'єкт і згодом видаляється з групи, яка застосовується для призначення дозволів на цей об'єкт, користувач залишається власником об'єкта. Це дозволяє йому відредагувати список об'єкта ACL і додати елемент ACE для облікового запису користувача, щоб зновуотримати доступ до об'єкта. Однак, якщо призначити роздільну здатність DENY для WRITE_DAC (Change permissions) для вкладених папок і папок (екран 2), коли користувач видалено з групи, що використовується для призначення дозволів об'єктам, користувач не зможе повернути доступ до об'єктів, створених шляхом зміни списків ACL.

Розглянемо список ACL для папки з іменем Accounts:

OWNER RIGHTS: (OI) (CI) (IO) (DENY)

NT AUTHORITYSYSTEM: (OI) (CI)F

FILESERVERAкоменти: (OI) (CI)C

BUILTINAdministrators: (OI) (CI)F

Стандартні дозволи CREATOR OWNER у XP, Windows Server 2003 та Windows Server 2008 дають власнику нових об'єктів право FULL CONTROL тільки для цих об'єктів, додаючи елемент ACE, що містить ідентифікатор безпеки власника об'єкта. У Windows XP і Windows Server 2003, незалежно від видалення CREATOR OWNER ACE, підсумковий результат буде таким самим, як у описаному випадку; мені буде відмовлено у доступі до папки Confidential Spreadsheets.

Жирним шрифтом показані відмінності у структурі та результатах між двома сценаріями. Навряд чи Authenticated Users будуть на практиці мати будь-які дозволи в папці, що містить конфіденційні дані. Однак, настроюючи OWNER RIGHTS ACE, можна сформувати додатковий рівень захисту та зменшити вразливість у випадках, коли списки ACL складені неправильно.

Якщо додати елемент ACE для OWNER RIGHTS у папці Accounts під час створення папки, а потім спробувати змінити власника з облікового запису користувача, наприклад, призначивши власником групу Administrators, необхідно скинути OWNER RIGHTS ACE.

На екрані 3 показано, як Windows призначає успадкування ACE значення Nothing після зміни власника. Розкрийте меню та встановіть режимуспадкування Subfolders and files only, як показано малюнку 2.

Стандартні списки ACL

У таблицях показані списки ACL для кореневого каталогу системного диска (зазвичай C:) та каталогу Windows (C:Windows) у Windows XP, Vista, Server 2003 та 2008. Ці таблиці були підготовлені з використанням утиліти cacls.exe, на зміну якої у Vista прийшла утиліта icacls.

Результати роботи icacls трохи відрізняються, тому щоб уникнути плутанини, дані для всіх операційних систем підготовлені з використанням cacls.

У цих команд спочатку важко розібратися (таблиця 1), тому корисно порівняти таблицю 1 з екранами 4 і 5.

Кореневий каталог системного диска (C:)

Дозволи BUILTINAdministrators і SYSTEM були поділені на два елементи ACE. Видалено такі елементи ACE, як Everyone та CREATOR OWNER. Елементи BUILTINUsers були замінені на Authenticated Users, за винятком BUILTINUsers: (OI) (CI)R ACE, який компенсує відсутність Everyone.

Головна відмінність – відсутність CREATOR OWNER. У Vista користувачеві, який створює папку в кореневому каталозі системного диска, не призначається жодних конкретних дозволів.

Група Authenticated Users отримує дозвіл MODIFY. CREATOR OWNER залишається у Windows Server 2008, як показано в таблиці 2 (див. також екрани 6 та 7).

Каталог Windows (C:Windows)

Дозволи в каталозі Windows трохи змінилися (таблиця 3).

Не стало групи Power Users, натомість з'явився TrustedInstaller. Елементи ACE для SYSTEM та BUILTINAdministrators трохи змінені; вказані інші дозволи: MODIFY для каталогу Windows верхнього рівня та FULL CONTROL для вкладенихпапок та файлів.

Тому, якщо переглядати ці дозволи в інтерфейсі користувача Vista, можна побачити два елементи для BUILTINAdministrators та SYSTEM відповідно (екрани 8 та 9).

У Windows XP файлів операційної системи в каталозі Windows за промовчанням призначено роздільну здатність Full Control для групи Administrators. Тепер це не так, і новому ідентифікатору безпеки з ім'ям TrustedInstaller надається повне керування та володіння файлами операційної системи (таблиця 4).

Мета цієї зміни – перешкодити установнику програм автоматично замінювати файли операційної системи під час роботи з обліковими даними адміністратора (див. також екрани 10 та 11).

Контроль облікових записів та списки ACL

При переході до папки, для читання якої користувач не має дозволу, функція контролю облікових записів (UAC) видає діалогове вікно, що містить попередження про відсутність дозволу для доступу до папки та запрошення клацнути на кнопці Continue, щоб отримати доступ до папки. З діалогового вікна не зрозуміло, як буде надано доступ. Коли UAC надає доступ до файлу або папки, на відміну від інших операцій UAC, провідник Windows не перезапускається з розширеним маркером, який надає тимчасовий доступ до папки для читання. Натомість створюється READ ACE для об'єкта, у свою чергу успадкований усіма дочірніми об'єктами. Після натискання кнопки Continue можна помітити невелику затримку. Це тому, що до об'єктів в ієрархії папки додається новий елемент ACE. Тому не дивуйтеся, якщо після такої операції користувач отримує доступ для читання частини файлової системи, яка раніше недоступна.

Інше відбувається при записі в папку,для якої користувач не має необхідних дозволів. Спробуйте скопіювати файл у папку, для якої немає дозволу запису, і на екрані з'явиться схоже діалогове вікно з попередженням про те, що для копіювання до цієї папки потрібні адміністративні повноваження. Файл буде скопійовано, але доступ до читання буде наданий лише до скопійованого файлу.

Рассел Сміт ([email protected]) - незалежний ІТ-консультант, спеціалізується на управлінні системами

Прапори наслідування доступу

Короткий опис контейнера Access Inheritance Flags допоможе краще зрозуміти інформацію, наведену у статті. Ці прапори використовуються для представлення параметрів успадкування в командному рядку таких програм як cacls:

(IO) Inherit Only - елемент ACE не впливає на об'єкт, до якого він застосовується;

(OI) Object Inherit - елемент ACE впливатиме на підлеглі файли;

(CI) Container Inherit — елемент ACE впливатиме на підлеглі папки.

Наприклад, (OI) (CI) разом означають, що елемент ACE застосовується до вкладених папок, але не файлів, і не впливає на об'єкт, до якого застосований. У графічному інтерфейсі це буде представлено як Subfolders only. (IO) (CI) (OI) відображаються у графічному інтерфейсі як Subfolders and files only. Дозволи не застосовуються до об'єкта, якому призначається елемент ACE, але поширюються на вкладені папки та файли.

F - Full Control

C - Modify (Change)

Стандартні облікові записи та групи - учасники безпеки

З'явилися нові групи: IIS_IUSRS з такими ж функціями, як обліковий запис IUSR_ в XP. Завдяки видаленню частини імені облікового запису простіше керувати обліковим записом за допомогою таких автоматизованих механізмів, як групова політика,оскільки ім'я однаково всіх комп'ютерах; Event Log Readers, яка усуває необхідність змінювати рядки Security Description Definition Language (SDDL) у журналах подій; група Performance Log Users може призначати розклад внесення до журналу показників лічильника продуктивності, включати провайдерів трасування, локально та віддалено перераховувати сліди подій, але право контролю системних процесів, як і раніше, надається через привілей Profile system performance (SeSystemProfilePrivilege); група Performance Monitor Users має доступ до даних лічильників продуктивності; група Distributed COM Users спочатку з'явилася у Windows Server 2003 SP1, щоб забезпечити простий спосіб застосувати до облікових записів користувачів налаштування обмеження комп'ютера DCOM; у Vista SP1 та Server 2008 група Cryptographic Operators активізує Cryptography API: Next Generation (CNG), надаючи доступ до таких елементів, як налаштування шифрування в політиці IPSec брандмауера Windows.

Поділіться матеріалом з колегами та друзями