Hi @ll, the following is a substantially shortened version of and Windows NT supports access control for (almost) all its objects, "How Security Descriptors and Access Control Lists Work" and "How Permissions Work" provide a comprehensive and exhaustive explanation. "Access Control Lists" provides an abstract: | An access control list (ACL) is a list of access control entries (ACE). | Each ACE in an ACL identifies a trustee and specifies the access rights | allowed, denied, or audited for that trustee. The security descriptor | for a securable object can contain two types of ACLs: a DACL and a SACL. | | A discretionary access control list (DACL) identifies the trustees that | are allowed or denied access to a securable object. When a process tries | to access a securable object, the system checks the ACEs in the object's | DACL to determine whether to grant access to it. If the object does not | have a DACL, the system grants full access to everyone. If the object's | DACL has no ACEs, the system denies all attempts to access the object | because the DACL does not allow any access rights. The system checks the | ACEs in sequence until it finds one or more ACEs that allow all the | requested access rights, or until any of the requested access rights are | denied. [...] False claim #1 ~~~~~~~~~~~~~~ "File Security and Access Rights" specifies for directories and files: | The valid access rights for files and directories include the DELETE, | READ_CONTROL, WRITE_DAC, WRITE_OWNER, and SYNCHRONIZE standard access | rights. ... | By default, authorization for access to a file or directory is controlled | strictly by the ACLs in the security descriptor associated with that file ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | or directory. In particular, the security descriptor of a parent directory | is not used to control access to any child file or directory. REALLY? Demonstration #1 ~~~~~~~~~~~~~~~~ Run the following command lines to prove the above claim wrong for files: | CHDIR /D "%PUBLIC%" | REM create an empty file | COPY NUL: file | 1 file(s) copied. | REM remove all (inherited) ACEs | ICACLS.exe file /Inheritance:R | processed file: file | Successfully processed 1 files; Failed processing 0 files | | REM (try to) read the file | TYPE file | Access denied | | REM display the (now empty) DACL | CACLS.exe file /S | C:\Users\Public\file "D:PAI" Although the (empty) DACL grants no access, the object's owner has (documented) implicit READ_CONTROL access permission (and WRITE_DAC too)! | REM add an ACE to deny the owner's implicit access permissions | ICACLS.exe file /Deny *S-1-3-4:(F) | processed file: file | Successfully processed 1 files; Failed processing 0 files | | REM (try to) display the DACL | CACLS.exe file /S | C:\Users\Public\file | | Access denied | | REM delete the file | ERASE file Although even the owner had no access any more, the file is gone: "DeleteFile function", "DeleteFileTransacted function", "MoveFileEx function", "MoveFileWithProgress function", "ReplaceFile function" tell why, and contradict the above claim! | To delete or rename a file, you must have either delete permission on | the file, or delete child permission in the parent directory. Demonstration #2 ~~~~~~~~~~~~~~~~ Run the following command lines to prove the above claim also wrong for directories: | CHDIR /D "%PUBLIC%" | REM create an empty directory | MKDIR directory | REM remove all (inherited) ACEs | ICACLS.exe directory /Inheritance:R | processed file: directory | Successfully processed 1 files; Failed processing 0 files | | REM (try to) list the directory | DIR directory ... | File not found | | REM (try to) remove the directory | RMDIR directory | Access denied Works as designed and documented! BUT: contrary to "file" child objects, DELETE_CHILD permission on the parent directory does NOT allow removal of "directory" child objects! | REM display the (now empty) DACL | CACLS.exe directory /S | C:\Users\Public\file "D:PAI" Although the (empty) DACL grants no access, the object's owner has (documented) implicit READ_CONTROL access permission (and WRITE_DAC too)! | REM add an ACE with only SYNCHRONIZE to deny the implicit access permissions | ICACLS.exe directory /Grant *S-1-3-4:(S) | processed file: directory | Successfully processed 1 files; Failed processing 0 files | | REM (try to) display the DACL | CACLS.exe directory /S | C:\Users\Public\directory | | Access denied | | REM remove the directory | RMDIR directory OUCH: although no DELETE permission was granted the directory is gone! Bug^WVULNERABILITY or feature? See the vendor statement below! False claim #2 ~~~~~~~~~~~~~~ "SACL Access Right" | The ACCESS_SYSTEM_SECURITY access right is not valid in a DACL because | DACLs do not control access to a SACL. REALLY? False claim #3 ~~~~~~~~~~~~~~ "Requesting Access Rights to an Object" | (!) Note | | The MAXIMUM_ALLOWED constant cannot be used in an ACE. REALLY? Demonstration #3 ~~~~~~~~~~~~~~~~ | CHDIR /D "%PUBLIC%" | REM create an empty file | COPY NUL: file | 1 file(s) copied. | REM remove all (inherited) ACEs | ICACLS.exe file /Inheritance:R | processed file: file | Successfully processed 1 files; Failed processing 0 files | | REM (try to) add ACEs with ACCESS_SYSTEM_SECURITY and MAXIMUM_ALLOWED access permissions | ICACLS.exe file /Deny *S-1-1-0:(AS) /Grant *S-1-1-0:(MA) | processed file: file | Successfully processed 1 files; Failed processing 0 files | | REM display the DACL | CACLS.exe file /S | C:\Users\Public\file "D:PAI" OOPS: despite the "success" message no ACEs were added! | REM second try | ICACLS.exe file /Deny *S-1-3-4:(AS) /Grant *S-1-3-4:(MA) /Grant "%USERNAME%":(F) | processed file: file | Successfully processed 1 files; Failed processing 0 files | | REM display the DACL | CACLS.exe file /S | C:\Users\Public\file "D:PAI(D;;;;;OW)(A;;FA;;;S-1-5-21-3150931553-3643200234-2488609525-1000)(A;;;;;OW)" OUCH: both (AS) and (MA) create ACEs WITHOUT any access permission! | REM display the DACL again | ICACLS.exe file | file OWNER RIGHTS:(DENY)(S) | AMNESIAC\Stefan:(F) | OWNER RIGHTS: OOPS: ICACLS.exe shows (S) "SYNCHRONIZE" access permission despite that NO_ACCESS is present! | REM remove the deny ACE for the owner and the allow ACE for the user, | REM leaving the allow ACE for the owner | ICACLS.exe file /Remove:d *S-1-3-4 /Remove:g "%USERNAME%" | processed file: file | Successfully processed 1 files; Failed processing 0 files | | REM (try to) display the DACL | CACLS.exe file /S | C:\Users\Public\file | | Access denied OUCH: the allow ACE with empty access mask REMOVES the owner's implicit READ_CONTROL and WRITE_DAC access permissions! | ERASE file See above! JFTR: these demonstrations uncover just the tip of the iceberg! Vendor statement ~~~~~~~~~~~~~~~~ | Thank you for your submission. We determined your finding does not meet | our bar for immediate servicing. For more information, please see the | Microsoft Security Servicing Criteria for Windows | (https://aka.ms/windowscriteria). | | However, we've marked your finding for future review as an opportunity | to improve our products. I do not have a timeline for this review and | will not provide updates moving forward. As no further action is | required at this time, I am closing this case. You will not receive | further correspondence regarding this submission. stay tuned, and far away from defective products! Stefan Kanthak