mirror of
https://github.com/reactos/reactos.git
synced 2024-06-30 09:50:07 +00:00
55c117c4c9
There are two fundamental problems when it comes to access checks in ReactOS. First, the internal function SepAccessCheck which is the heart and brain of the whole access checks logic of the kernel warrants access to the calling thread of a process to an object even though access could not be given. This can potentially leave security issues as we literally leave objects to be touched indiscriminately by anyone regardless of their ACEs in the DACL of a security descriptor. Second, the current access check code doesn't take into account the fact that an access token can have restricted SIDs. In such scenario we must perform additional access checks by iterating over the restricted SIDs of the primary token by comparing the SID equality and see if the group can be granted certain rights based on the ACE policy that represents the same SID. Part of SepAccessCheck's code logic will be split for a separate private kernel routine, SepAnalyzeAcesFromDacl. The reasons for this are primarily two -- such code is subject to grow eventually as we'll support different type ACEs and handle them accordingly -- and we avoid further code duplicates. On Windows Server 2003 there are 5 different type of ACEs that are supported for access checks: - ACCESS_DENIED_ACE_TYPE (supported by ReactOS) - ACCESS_ALLOWED_ACE_TYPE (supported by ReactOS) - ACCESS_DENIED_OBJECT_ACE_TYPE - ACCESS_ALLOWED_OBJECT_ACE_TYPE - ACCESS_ALLOWED_COMPOUND_ACE_TYPE This gives the opportunity for us to have a semi serious kernel where security of objects are are taken into account, rather than giving access to everyone. CORE-9174 CORE-9175 CORE-9184 CORE-14520 |
||
|---|---|---|
| .. | ||
| access.c | ||
| accesschk.c | ||
| acl.c | ||
| audit.c | ||
| priv.c | ||
| sd.c | ||
| semgr.c | ||
| sid.c | ||
| sqos.c | ||
| srm.c | ||
| token.c | ||