JEDI Windows API » Token

Setting the SessionID for a new process

Christian Wimmer — Fri, 23 May 2008 09:26:01 +0000

This simple example shows how you can change the target session of a new process.

uses
JwaWindows,
JwsclToken,
JwsclComUtils;

var
NewToken,
UserToken : TJwSecurityToken;

S : TStartupInfo;
P : TProcessInformation;
begin
UserToken := TJwSecurityToken.CreateWTSQueryUserTokenEx(nil, 1); //for example: here SessionID = 1
TJwAutoPointer.Wrap(UserToken); //automatic destroy

NewToken := TJwSecurityToken.CreateDuplicateExistingToken(UserToken.TokenHandle, MAXIMUM_ALLOWED);
TJwAutoPointer.Wrap(NewToken);

//needs TCB privilege -> Service
JwEnablePrivilege(SE_TCB_NAME, pst_Enable);
NewToken.TokenSessionId := 2; //e.g. set to session 2 – of course it must exist

ZeroMemory(@S, Sizeof(S));
S.cb := sizeof(S);
//examplary, but working CPAU call – adapt for your need
CreateProcessAsUser(NewToken.TokenHandle,‘C:\Windows\system32\cmd.exe’,nil,nil,nil,false, 0, nil, nil, S,P);

All the source is doing is to get a user’s token by calling CreateWTSQueryUserToken and then duplicate so it will become possible to change the Token SessionID. The session ID is changed by setting the property TokenSessionID which is only possible with the TCB privilege (we need it, but it needn’t to be active).
You can do the CreateProcess part a little better if you read this: “CreateProcess in full glory“.

Did you know?
1. You can test this example in your own Delphi environment without writing a service first.

2. It is not possible to change the session ID of a running process.

RunAsSYS 1.0 preview [update#1]

Christian Wimmer — Thu, 08 May 2008 19:10:53 +0000

This is the preview Version of RunAsSys for Windows XP and Vista made with the help of JWSCL.
RunAsSys runs applications as SYSTEM user in the current user’s session. If you start it without any parameters it creates a command prompt with SYSTEM privileges by default. Otherwise you can add an application with parameters to start this process as SYSTEM user. Use quotation marks if necessary for your path.
On Windows Vista and UAC it should prompt you for elevation. On XP without Admin privileges it should prompt you for Admin credentials.

Warning: On Windows XP (and older) the application shows the credential prompt dialog which allows you to run as the same user. If you just click OK button, the application will maybe response one more time but finally stop working. This is due to a bug in ShellExecuteEx with “runas” verb.

UPDATE

Version 1.2

This version fixes a bug that prevents the command prompt to be started sometimes. And it fixes a bug with Windows 7 where a dialog pops up with no use. (Most problems are fixed with the new JWSCL)
This version is also available as source (Subversion Link) from the preRelease of JWA 2.4a (Subversion Link) and JWSCL 0.9.4a (Subversion Link).

Download RunAsSys 1.2

Version 1.1

I publish Version 1.1 which fixes several errors and also makes it available to Windows 64bit systems.
The zip archive contains a 64bit version registry key file that is compatible with WOW64.
RunAsSys contains EurekaLog, which logs internal things. If you get an error, you can send the error report directly to us. However it is not the default behaviour. We use your error report only for improving our software. It will be used internally only and will be finally deleted. No screenshot is taken.

Download RunAsSys 1.1

Version 1.0

Additional Info:
The reg file creates a reg key that is used to enable logging and set the log output folder (default where exe resides)
It is located in HKEY_LOCAL_MACHINE\SOFTWARE\JEDI\WSCL\RunAsSys\1.0

Download RunAsSYS 1.0

Setting file security with JWSCL

Christian Wimmer — Mon, 28 Apr 2008 16:12:39 +0000

Sometimes it is necessary to change the security settings of a file or folder for getting or denying write access. With JWSCL this task is made very easy. However there are some pitfalls to avoid.

The following code will also be available in the example section of the source code. The application gets a file or folder name as parameter and tries to add the user with full access control. It even tries to get ownership if it can’t change the access control list.

First of all we need some JWSCL classes:

TJwSecurityDescriptor
A security descriptor contains all information about security of an object. It contains the owner and the access control list (also some other thing, we don’t need here)
TJwSecureFileObject
This class provides methods to read and write security information on a file or folder. Despite its name it does also support folders. It even supports inheritance.
You can access a file or folder through its name, a handle or the VCL class TFileStream.
TJwDAccessControlList
This class contains methods to maintain a discreationary access control list (DACL). A DACL contains a list of users and their possible access on the object.
TJwSecurityId
Every user is identified by a unique number which is maintained by this class.
TJwSecurityToken
Every logged on user gets a security pass which contains information what she can do or not. We mainly use it to retrieve the user’s SID (TJwSecurityID)

These classes are stored in the JWSCL units. We use the following ones:

uses
JwaWindows,
JwsclSid,
JwsclToken,
JwsclACl,
JwsclDescriptor,
JwsclSecureObjects,
JwsclKnownSid;

The units above are necessary and contain all the classes described earlier Of course we have to declare the classes:

var
UserToken : TJwSecurityToken;
SD : TJwSecurityDescriptor;
FileObject : TJwSecureFileObject;
Owner : TJwSecurityId;
DACL : TJwDAccessControlList;
begin
if not FileExists(ParamStr(1)) then
exit;

This example also shows how we can add well known Security Identifiers (SID) to a secured object. We have to initialize them. The variable JwWorldSID will then contain the correct SID for group Everyone. If we didn’t call it, we would get nil instead.
JwInitWellKnownSIDs;

The next steps are creating the classes. We get the user name through her token and save the SID into Owner.
Later we will use the Owner instance to add it into the security information of the object.

UserToken := TJwSecurityToken.CreateTokenEffective(MAXIMUM_ALLOWED);
Owner := UserToken.GetTokenOwner;
try
FileObject := TJwSecureFileObject.Create(ParamStr(1));

The actual class which does all the work on the file/folder is TJwSecureFileObject. We just apply the first parameter.

Notice: A user can only change security information of an object if she has the right to do it. There are two options to allow it.

The user is listed in the DACL. Additionally the right WRITE_DAC is granted for her.
The user is the owner. In this case she don’t need to be listed and allowed in the DACL. It is automatically granted

We can check both version in one call.

try
if not FileObject.AccessCheck(WRITE_DAC)
begin

This call is very easy. If we can’t change the DACL, we can try to become the owner. The only way to become an owner is to enable a privilege called SE_TAKE_OWNERSHIP_NAME. It is usually only granted to Administrators.

JwEnablePrivilege(SE_TAKE_OWNERSHIP_NAME, pst_Enable);
FileObject.Owner := Owner;
end;

JwEnablePrivilege will fail, if it can’t activate the privilege. Otherwise we can set the file/folder’s owner to the token user.

The main work is done here. We get the default DACL from the existing object and adapt it.

DACL := FileObject.DACL;

Adaption is done by adding the user to the DACL with full control. We additionally allow the Everyone group to demonstrate the well known Sids initialized by JwInitWellKnownSIDs. The last parameters (false) define that we don’t want the list to free the given SIDs (Owner and JwWorldSid) automatically.

DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create
(nil, [], GENERIC_ALL, Owner, false));
DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create
(nil, [], GENERIC_READ, JwWorldSID, false));

And finally we reset the DACL.

FileObject.SetDACL(DACL);

The DACL of the file or folder will receive the newly created control entries in addition to its existing ones. If it contains inherited entries (entries from a parent folder) they will be conserved. However if you don’t retrieve the DACL and just use an empty one, all previously existing entries which are not inherited will be removed. Of course the inherited entries will still remain intact.

And of course we free all allocated resources

finally
FileObject.Free;
end;

finally
Owner.Free;
UserToken.Free;
end;
end.

Since I cut the source code into pieces, I’ll show it here in full glory

program SetFileSecurity;

{$APPTYPE CONSOLE}

uses
SysUtils,
JwaWindows,
JwsclSid,
JwsclToken,
JwsclAcl,
JwsclDescriptor,
JwsclSecureObjects,
JwsclKnownSid;

var
UserToken : TJwSecurityToken;
SD : TJwSecurityDescriptor;
FileObject : TJwSecureFileObject;
Owner : TJwSecurityId;
DACL : TJwDAccessControlList;
begin
if not FileExists(ParamStr(1)) then
exit;

JwInitWellKnownSIDs;

UserToken := TJwSecurityToken.CreateTokenEffective(MAXIMUM_ALLOWED);
Owner := UserToken.GetTokenOwner;
try
FileObject := TJwSecureFileObject.Create(ParamStr(1));
try
//Make me owner if we cant access DACL
if not FileObject.AccessCheck(WRITE_DAC) then
begin
//try to become owner
JwEnablePrivilege(SE_TAKE_OWNERSHIP_NAME, pst_Enable);
FileObject.Owner := Owner;
end;

DACL := FileObject.DACL;
DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil, [], GENERIC_ALL, Owner, false));
DACL.Add(TJwDiscretionaryAccessControlEntryAllow.Create(nil, [], GENERIC_READ, JwWorldSID, false));

FileObject.SetDACL(DACL);
finally
FileObject.Free;
end;

finally
Owner.Free;
UserToken.Free;
end;
end.

New threads do not automatically impersonate themselves.

Christian Wimmer — Wed, 09 Apr 2008 19:58:02 +0000

Whenever you impersonate a running thread and create a new thread while impersonating, your new thread will not get impersonated, too. The new thread will run without any thread token and thus a called function will use the process token instead. So you have to impersonate the new thread again. Ignoring that fact may lead to problems if the process as a high access level (SYSTEM, Administrator) and the new thread touches resources e.g. files. These files are opened with higher privileges, even if the user usually cannot access them.

The sample shows how we can spawn a token for the new thread exclusively.

procedure ThreadFunc(Data : Pointer…)
var Token : TJwSecurityToken;
begin
Token := TJwSecurityToken(Data);
try
Token.ImpersonateLoggedOnUser;
…
…
except
//check here the problem
//and inform the thread creator
//To raise an exception within a thread does end it immediately.
end;
Token.Free;
end;

var Token, Token2 : TJwSecurityToken;
begin
…
try
Token.ImpersonateLoggedOnUser;
//the new thread will not run in Token context
//get a second handle to the token for the thread
Token2 := TJwSecurityToken.CreateDuplicateExistingToken(Token.TokenHandle, TOKEN_ALL_ACCESS, true);
CreateThread(…, @ThreadFunc, Pointer(Token2));
…
finally
Token.Free;
end;

How to get the user’s token from a service?

Christian Wimmer — Mon, 31 Mar 2008 18:27:28 +0000

This simple code excerpt can only be run under SYSTEM account (say in a service). It retrieves the token from the logged on user – especially the user at the physical console. Or in other words the user data of the person that sits in front of the computer. The main code which does the task above can be seen here.

UserToken := TJwSecurityToken.CreateWTSQueryUserToken(WTS_CURRENT_SESSION);

CreateWTSQueryUserToken is only applicable in Windows XP or newer. Use CreateWTSQueryUserTokenEx if you need Windows 2000 support.
WTS_CURRENT_SESSION (-1) defines the console session to be retrieved. Any existing session ID (starting from zero (0) ) can be used instead. If a problems occurs (e.g. session does not exist) you get an exception (see documentation)

uses
JwaWindows,
JwsclToken,
JwsclSid,
JwsclStrings,
SysUtils;

…
var
UserToken : TJwSecurityToken;
ConsoleUser : TJwSecurityId;
UserSidString,
UserName : TJwString;
begin
//erst ab Windows XP
UserToken := TJwSecurityToken.CreateWTSQueryUserToken(WTS_CURRENT_SESSION);
try
ConsoleUser := UserToken.TokenUser;
try
UserSidString := ConsoleUser.StringSID;
UserName := ConsoleUser.GetAccountName(”);
//Writeln(UserSidString);
//Writeln(UserName);
finally
FreeAndNil(ConsoleUser);
end;
//User personifizieren
UserToken.ImpersonateLoggedOnUser;

***

UserToken.RevertToSelf;

finally
FreeAndNil(UserToken);
end;
end;

***) Place functions and do stuff here that needs to be run under the user’s context. Functions like SHGetSpecialFolder use the impersonated token to get the (correct) user folder. Additionally all security checks are made with the user’s token. This comes very handy because a service has (almost) always access to everything (files, reg keys, …) which means a security hole.

[UPDATE]
Fixed some minor mistakes.

Get the Windows Vista twin token

Christian Wimmer — Tue, 04 Mar 2008 11:29:11 +0000

Windows Vista contains a new feature that allows an administrator to work with less privileges. Every time a user who belongs to the administrator group logs on, the LogonUser API creates two tokens. One tokens contains the real power of the user and the second contains only restricted access. We call such a token restricted token. This feature was implemented way back in Windows 2000 . The changes on the restricted token starts with removed privileges and ends with setting the administrator group in the token groups to use for deny only. A deny only Sid is only used for access control entries that deny access. So in our case the access to a file which allows Administrators full access may be disallowed if there is not any other positive element that grants us the access.
Back to the topic. The token groups contains a special Sid that is called an integrity Sid. The token that has the administrator group enabled receives a high integrity Sid. Tthe medium integrity Sid goes to the groups of the restricted token.
The token returned bei LogonUser is always the restricted one. Although you can retrieve the the twin token, you cannot do anything with it if you are not a SYSTEM process or an administrator. However a SYSTEM process may return the powerful token to create a process with full administrator rights. UAC does not do anything else. It gets the user’s credentials, logs on and uses the twin token (if any, otherwise it prompts for an administrator account credentials) to create the process.

uses JwaWindows, JwsclExceptions, JwsclToken;var Token,
TwinToken : TJwSecurityToken;
begin
Token := TJwSecurityToken.CreateTokenEffective(MAXIMUM_ALLOWED);
try
TwinToken := Token.LinkedToken;
PrintTokenInfo(LToken);
except
On E : EJwsclSecurityException do
//error logic here
end;
try
//do stuff here
finally
TwinToken.Free;
Token.Free;
end;

Both tokens are linked together. Thus the following conditions are true.

Token.LinkedToken = TwinToken
TwinToken.LinkedToken = Token

You can use the twin token in any way you treat a token if you are powerful enough. Use it in CreateProcess or impersonate the user to do things as the user.

At the end I post a quite useful piece of code that displays primary information about a token.

uses …, JwsclSecurityId,…;
procedure PrintTokenInfo(const Token : TJwSecurityToken);
var SID, SID2 : TJwSecurityID;
begin
writeln(‘Access: ‘,JwFormatAccessRights(Token.AccessMask,TokenMapping ));

Sid := Token.TokenUser;
writeln(‘TokenUser: ‘,SID.GetText(true));
Sid.Free;

Sid := Token.TokenOwner;
writeln(‘TokenOwner: ‘,SID.GetText(true));
Sid.Free;

writeln(‘TokenGroups: ‘#13#10,Token.TokenGroups.GetText(true));
end;

Tell me how you liked this blog entry by adding a comment.