Commit graph

7 commits

Author SHA1 Message Date
George Bișoc 8e2fe925f2
[NTOS:PS] Do not reference the copied token twice and properly assign the impersonation level in case the server can't impersonate
As it currently stands the PsImpersonateClient routine does the following approach.
If impersonation couldn't be granted to a client the routine will make a copy
of the client's access token. As it makes a copy of the said token PsImpersonateClient
will reference the copied token after impersonation info have been filled out.
In the same code path we are assigning the desired level for impersonation to thread
impersonation info.

This is wrong for two reasons:

- On a copy situation the SeCopyClientToken routine holds a reference as the object
has been created. Referencing it at the bottom of the PsImpersonateClient routine
will make it that the token is referenced twice and whenever a server stops
impersonation the token still has an extra reference count which keeps the token
still alive in object database and memory space.

- If client impersonation is not possible the thread impersonation info should
have been assigned SecurityIdentification level to further indicate that the
actual impersonation of the thread is not currently in force but instead we
are assigning the impersonation level that is supplied by the caller. For instance
if the requested level is SecurityDelegation but impersonation is not possible
the level will be assigned that of SecurityDelegation yet the token has an
impersonation level of SecurityIdentification. This could lead to erratic behaviors
as well as potential impersonation escalation.

Fix the aforementioned issues by avoiding a double reference and properly assign
the impersonation level to SecurityIdentification if the server is not able to
impersonate the target client.
2023-06-09 11:53:55 +02:00
George Bișoc 242efae9a2
[NTOS:PS] Make sure we can impersonate the given token first
PsImpersonateClient blindly impersonates the requested client even though it doesn't know if the actual token given to the call can be impersonated for the thread of the client which we are going to begin impersonation. In the case where impersonation is not possible, make a copy of the given token and assign the newly one for impersonation instead.
CORE-17539
2021-05-02 16:55:20 +02:00
Thomas Faber db180c29c7
[NTOS:SE] Implement job case in PsImpersonateClient. CORE-8787 2020-05-17 16:05:00 +02:00
Pierre Schweitzer f8a4d31da4
[NTOSKRNL] On process primary token change, dereference device map 2019-06-02 10:00:17 +02:00
Hermès Bélusca-Maïto 89c5191d3f
[NTOS:PS] In PspSetPrimaryToken(), check also for sibling token to determine whether it is required to have the SeAssignPrimaryTokenPrivilege.
In addition, it is the presence or absence of the 'Token' pointer that indicates whether or not we should use instead the provided token handle.
2018-09-28 00:45:03 +02:00
Hermès Bélusca-Maïto 813879f02f
[NTOS:PS] Adjust the PsReferenceEffectiveToken() prototype in the header; add a comment about the fact that the ImpersonationLevel parameter can be left untouched on purpose in one special case. 2018-06-27 23:40:13 +02:00
Colin Finck c2c66aff7d Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers into modules, and delete rossubsys. 2017-10-03 07:45:34 +00:00
Renamed from reactos/ntoskrnl/ps/security.c (Browse further)