# ACLs - DACLs/SACLs/ACEs
\
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) для легкої побудови та **автоматизації робочих процесів**, які працюють на основі найбільш **продвинутих** інструментів у спільноті.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
Вивчайте хакінг AWS від нуля до героя зhtARTE (HackTricks AWS Red Team Expert)!
Інші способи підтримки HackTricks:
* Якщо ви хочете побачити свою **компанію в рекламі на HackTricks** або **завантажити HackTricks у PDF-форматі**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Отримайте [**офіційний PEASS & HackTricks мерч**](https://peass.creator-spring.com)
* Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family)
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи Telegram**](https://t.me/peass) або **слідкуйте** за нами на **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Поділіться своїми хакерськими трюками, надсилайте PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв GitHub.
## **Список керування доступом (ACL)**
Список керування доступом (ACL) складається з упорядкованого набору записів керування доступом (ACE), які визначають захист для об'єкта та його властивостей. В сутності, ACL визначає, які дії від яких безпекових суб'єктів (користувачів або груп) дозволені або заборонені для певного об'єкта.
Існують два типи ACL:
* **Список керування доступом за власним бажанням (DACL):** Визначає, які користувачі та групи мають або не мають доступ до об'єкта.
* **Список керування доступом системи (SACL):** Керує аудитом спроб доступу до об'єкта.
Процес доступу до файлу включає в себе перевірку дескриптора безпеки об'єкта на відповідність токену доступу користувача для визначення, чи слід надавати доступ та обсяг цього доступу, на основі ACE.
### **Ключові компоненти**
* **DACL:** Містить ACE, які надають або відмовляють у правах доступу користувачам та групам до об'єкта. Це, по суті, основний ACL, який визначає права доступу.
* **SACL:** Використовується для аудиту доступу до об'єктів, де ACE визначають типи доступу, які слід реєструвати в журналі подій безпеки. Це може бути надзвичайно корисно для виявлення несанкціонованих спроб доступу або усунення проблем доступу.
### **Взаємодія системи з ACL**
Кожна сесія користувача пов'язана з токеном доступу, який містить інформацію про безпеку, що стосується цієї сесії, включаючи ідентифікатори користувача, груп та привілеї. Цей токен також включає SID входу, який унікально ідентифікує сесію.
Місцевий орган безпеки (LSASS) обробляє запити на доступ до об'єктів, переглядаючи DACL для ACE, які відповідають безпековому суб'єкту, який намагається отримати доступ. Доступ негайно надається, якщо відповідні ACE не знайдені. В іншому випадку LSASS порівнює ACE з SID безпекового суб'єкта в токені доступу для визначення можливості доступу.
### **Узагальнений процес**
* **ACL:** Визначають права доступу через DACL та правила аудиту через SACL.
* **Токен доступу:** Містить інформацію про користувача, групу та привілеї для сесії.
* **Рішення про доступ:** Приймається порівнянням DACL ACE з токеном доступу; SACL використовується для аудиту.
### ACEs
Існують **три основних типи записів керування доступом (ACE)**:
* **ACE відмови в доступі**: Цей ACE явно відмовляє у доступі до об'єкта вказаним користувачам або групам (у DACL).
* **ACE дозволу доступу**: Цей ACE явно надає доступ до об'єкта вказаним користувачам або групам (у DACL).
* **ACE аудиту системи**: Розташований у Списку керування доступом системи (SACL), цей ACE відповідає за створення журналів аудиту при спробах доступу до об'єкта користувачами або групами. Він документує, чи був доступ наданий або відмовлений та характер доступу.
Кожен ACE має **чотири ключові компоненти**:
1. **Ідентифікатор безпеки (SID)** користувача або групи (або їхнє ім'я представлене графічно).
2. Прапорець, який ідентифікує тип ACE (доступ відмовлено, дозволено або системний аудит).
3. **Прапорці успадкування**, які визначають, чи можуть дочірні об'єкти успадковувати ACE від батьківського об'єкта.
4. [**Маска доступу**](https://docs.microsoft.com/en-us/openspecs/windows\_protocols/ms-dtyp/7a53f60e-e730-4dfe-bbe9-b21b62eb790b?redirectedfrom=MSDN), 32-бітне значення, що вказує надані права об'єкту.
Визначення доступу проводиться шляхом послідовного перегляду кожного ACE до:
* **ACE відмови доступу** явно відмовляє у запитаних правах довіреному особі, вказаному в токені доступу.
* **ACE дозволу доступу** явно надають усі запитані права довіреному особі в токені доступу.
* Після перевірки всіх ACE, якщо будь-яке запитане право **не було явно дозволено**, доступ автоматично **відмовляється**.
### Порядок ACE
Спосіб розміщення **ACE** (правила, які вказують, хто може або не може отримати доступ до чогось) у списку, який називається **DACL**, є дуже важливим. Це тому, що як тільки система надає або відмовляє у доступі на основі цих правил, вона перестає переглядати решту.
Є найкращий спосіб організувати ці ACE, і його називають **"канонічний порядок"**. Цей метод допомагає забезпечити безперервну та справедливу роботу. Ось як це працює для систем, таких як **Windows 2000** та **Windows Server 2003**:
* Спочатку розмістіть всі правила, які створені **спеціально для цього елемента**, перед тими, які походять з іншого джерела, наприклад, батьківської папки.
* У цих конкретних правилах розмістіть ті, які говорять **"ні" (відмовити)** перед тими, які говорять **"так" (дозволити)**.
* Для правил, які походять з іншого джерела, почніть з тих, які походять від **найближчого джерела**, наприклад, батька, а потім переходьте назад. Знову ж таки, розмістіть **"ні"** перед **"так"**.
Ця настройка допомагає у двох великих аспектах:
* Вона переконується, що якщо є конкретне **"ні,"** воно поважається, незалежно від того, які інші правила **"так"** є наявні.
* Власник елемента може **останнім** вирішувати, хто отримує доступ, перш ніж будь-які правила від батьківських папок або далі вступлять в силу.
Таким чином, власник файлу або папки може бути дуже точним у визначенні, хто має доступ, переконуючись, що правильні люди можуть отримати доступ, а неправильні - ні.
Таким чином, цей **"канонічний порядок"** спрямований на забезпечення ясності та ефективності прав доступу, розміщаючи специфічні правила спочатку та організовуючи все розумно.
\
Використовуйте [**Trickest**](https://trickest.com/?utm\_campaign=hacktrics\&utm\_medium=banner\&utm\_source=hacktricks) для легкої побудови та **автоматизації робочих процесів**, які працюють на основі найбільш **продвинутих** інструментів у спільноті.\
Отримайте доступ сьогодні:
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
### GUI Приклад
[**Приклад звідси**](https://secureidentity.se/acl-dacl-sacl-and-the-ace/)
Це класична вкладка безпеки папки, яка показує ACL, DACL та ACE:
Якщо ми натиснемо **Розширені** кнопку, ми отримаємо більше опцій, таких як успадкування:
І якщо ви додаєте або редагуєте Security Principal:
І на останок у нас є SACL на вкладці Аудиту:
### Пояснення керування доступом у спрощеному вигляді
При керуванні доступом до ресурсів, таких як папка, ми використовуємо списки та правила, відомі як Списки керування доступом (ACL) та Записи керування доступом (ACE). Вони визначають, хто може або не може отримати доступ до певних даних.
#### Відмова в доступі до конкретної групи
Уявіть, що у вас є папка з назвою Cost, і ви хочете, щоб всі мали до неї доступ, за винятком маркетингової команди. Встановивши правила правильно, ми можемо забезпечити, що маркетинговій команді явно відмовлено в доступі перед наданням доступу всім іншим. Це досягається розміщенням правила відмови в доступі для маркетингової команди перед правилом, яке дозволяє доступ всім іншим.
#### Надання доступу конкретному члену відхиленої групи
Скажімо, Боб, директор з маркетингу, потребує доступу до папки Cost, навіть якщо загалом маркетинговій команді не слід мати доступ. Ми можемо додати конкретне правило (ACE) для Боба, яке надає йому доступ, і розмістити його перед правилом, яке відмовляє доступу маркетинговій команді. Таким чином, Боб отримує доступ, незважаючи на загальне обмеження для його команди.
#### Розуміння Записів керування доступом
ACE - це окремі правила в ACL. Вони ідентифікують користувачів або групи, вказують, який доступ дозволяється або відмовляється, і визначають, як ці правила застосовуються до підпунктів (спадковість). Є два основних типи ACE:
* **Загальні ACE**: Ці застосовуються широко, впливаючи або розрізняючи тільки між контейнерами (такими як папки) та не-контейнерами (такими як файли). Наприклад, правило, яке дозволяє користувачам бачити вміст папки, але не мати доступу до файлів всередині неї.
* **Об'єкт-специфічні ACE**: Ці надають більш точний контроль, дозволяючи встановлювати правила для конкретних типів об'єктів або навіть окремих властивостей всередині об'єкта. Наприклад, у каталозі користувачів правило може дозволяти користувачеві оновлювати свій номер телефону, але не години входу.
Кожен ACE містить важливу інформацію, таку як на кого поширюється правило (з використанням ідентифікатора безпеки або SID), що дозволяє або відмовляє (з використанням маски доступу) та як воно успадковується іншими об'єктами.
#### Основні відмінності між типами ACE
* **Загальні ACE** підходять для простих сценаріїв керування доступом, де одне правило застосовується до всіх аспектів об'єкта або до всіх об'єктів всередині контейнера.
* **Об'єкт-специфічні ACE** використовуються для складніших сценаріїв, особливо в середовищах, таких як Active Directory, де може знадобитися контроль доступу до конкретних властивостей об'єкта по-різному.
У підсумку, ACL та ACE допомагають визначити точні керування доступом, забезпечуючи, що доступ до чутливої інформації або ресурсів мають лише відповідні особи або групи, з можливістю налаштування прав доступу до рівня окремих властивостей або типів об'єктів.
### Макет Запису керування доступом
| Поле ACE | Опис |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Тип | Прапорець, який вказує тип ACE. Windows 2000 та Windows Server 2003 підтримують шість типів ACE: Три загальні типи ACE, які додаються до всіх об'єктів, які можна захистити. Три типи ACE, специфічні для об'єктів, які можуть виникати для об'єктів Active Directory. |
| Прапорці | Набір бітових прапорців, які контролюють успадкування та аудит. |
| Розмір | Кількість байтів пам'яті, які виділяються для ACE. |
| Маска доступу | 32-бітне значення, чиї біти відповідають правам доступу до об'єкта. Біти можуть бути встановлені або вимкнені, але значення налаштування залежить від типу ACE. Наприклад, якщо біт, який відповідає праву на читання дозволів, увімкнено, і тип ACE - Відмова, ACE відмовляє у праві на читання дозволи об'єкта. Якщо той самий біт встановлено, але тип ACE - Дозвіл, ACE надає право на читання дозволів об'єкта. Детальніші відомості про маску доступу знаходяться в наступній таблиці. |
| SID | Ідентифікує користувача або групу, доступ до якого контролюється або моніториться цим ACE. |
### Макет маски доступу
| Біт (Діапазон) | Значення | Опис/Приклад |
| ----------- | ---------------------------------- | ----------------------------------------- |
| 0 - 15 | Об'єкт-специфічні права доступу | Читати дані, Виконати, Додати дані |
| 16 - 22 | Стандартні права доступу | Видалити, Записати ACL, Записати власника |
| 23 | Може отримати доступ до безпеки ACL | |
| 24 - 27 | Зарезервовано | |
| 28 | Загальний ВСЕ (Читати, Писати, Виконати) | Все нижче |
| 29 | Загальний Виконати | Все необхідне для виконання програми |
| 30 | Загальний Запис | Все необхідне для запису в файл |
| 31 | Загальний Читати | Все необхідне для читання файлу |
## Посилання
* [https://www.ntfs.com/ntfs-permissions-acl-use.htm](https://www.ntfs.com/ntfs-permissions-acl-use.htm)
* [https://secureidentity.se/acl-dacl-sacl-and-the-ace/](https://secureidentity.se/acl-dacl-sacl-and-the-ace/)
* [https://www.coopware.in2.info/\_ntfsacl\_ht.htm](https://www.coopware.in2.info/\_ntfsacl\_ht.htm)
 (1) (1) (1) (1) (1).png)