![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Оказывается, в Windows 8.1 и Windows 10 у файлов и папок появился новый аттрибут, который мешает их модификации даже из-под учётной записи SYSTEM. Он предназначен для защиты приложений, установленных из магазина.
Физически этот аттрибут хранится в дескрипторе безопасности. Дескриптор безопасности (SDDL) ещё со времён Windows NT 4.0 традиционно состоит из владельца, группы, DACL и SACL. При этом DACL и SACL традиционно являются списками ACE-записей (Access Control Entry). Но в Windows 8.1 и Windows 10 в SACL появилась новая разновидность ACE-записей:
Type 0x14 (SYSTEM_PROCESS_TRUST_LABEL_ACE_TYPE)
Flags 0x03
Size 0x0018
Payload a9011f00010200000000001300020000
( https://wimlib.net/forums/viewtopic.php?f=1&t=261 )
Традиционный для Windows NT способ замены дескриптора безопасности файлового объекта (получить элевацию до прав локального админа; назначить процессу все привилегии в сфере backup/restore; для всех объектов в иерархии от корневой папки до файла: открыть с FILE_FLAG_BACKUP_SEMANTICS, принять владение объектом, задать объекту новый дескриптор безопасности) не работает: всё равно ACE-запись типа 0x14 остаётся в SACL дескриптора безопасности.
Эта ACE-запись типа 0x14 в SACL не всегда блокирует доступ к объекту, она действует совместно с ACE-записью типа 0x9 (ACCESS_ALLOWED_CALLBACK_ACE_TYPE, "XA") в DACL. Насколько я понимаю, ACE-запись типа 0x14 в SACL иерархически наследуется всеми объектами от корневой папки тома, и снять её можно только форматированием тома; и лишь комбинация ACE-записи типа 0x14 в SACL и ACE-записи типа 0x9 в DACL обеспечивает необходимую защиту.
Вот PowerShell, показывающий дескриптор безопасности за вычетом SACL:
Защита обеспечивается ядром или драйвером файловой системы, поэтому такие файлы нельзя изменить даже из среды Windows PE, хотя можно изменить в предыдущих версиях Windows, которые ещё не знают об ACE-записях типа 0x14 (например, в Windows XP/Vista/7/8) или в Linux/MacOS/FreeBSD (через драйвер ntfs-3g, который игнорирует дескрипторы безопасности).
Физически этот аттрибут хранится в дескрипторе безопасности. Дескриптор безопасности (SDDL) ещё со времён Windows NT 4.0 традиционно состоит из владельца, группы, DACL и SACL. При этом DACL и SACL традиционно являются списками ACE-записей (Access Control Entry). Но в Windows 8.1 и Windows 10 в SACL появилась новая разновидность ACE-записей:
Type 0x14 (SYSTEM_PROCESS_TRUST_LABEL_ACE_TYPE)
Flags 0x03
Size 0x0018
Payload a9011f00010200000000001300020000
( https://wimlib.net/forums/viewtopic.php?f=1&t=261 )
Традиционный для Windows NT способ замены дескриптора безопасности файлового объекта (получить элевацию до прав локального админа; назначить процессу все привилегии в сфере backup/restore; для всех объектов в иерархии от корневой папки до файла: открыть с FILE_FLAG_BACKUP_SEMANTICS, принять владение объектом, задать объекту новый дескриптор безопасности) не работает: всё равно ACE-запись типа 0x14 остаётся в SACL дескриптора безопасности.
Эта ACE-запись типа 0x14 в SACL не всегда блокирует доступ к объекту, она действует совместно с ACE-записью типа 0x9 (ACCESS_ALLOWED_CALLBACK_ACE_TYPE, "XA") в DACL. Насколько я понимаю, ACE-запись типа 0x14 в SACL иерархически наследуется всеми объектами от корневой папки тома, и снять её можно только форматированием тома; и лишь комбинация ACE-записи типа 0x14 в SACL и ACE-записи типа 0x9 в DACL обеспечивает необходимую защиту.
Вот PowerShell, показывающий дескриптор безопасности за вычетом SACL:
Защита обеспечивается ядром или драйвером файловой системы, поэтому такие файлы нельзя изменить даже из среды Windows PE, хотя можно изменить в предыдущих версиях Windows, которые ещё не знают об ACE-записях типа 0x14 (например, в Windows XP/Vista/7/8) или в Linux/MacOS/FreeBSD (через драйвер ntfs-3g, который игнорирует дескрипторы безопасности).
