Help with SeQueryInformationToken leaks

I’m using SeQueryInformationToken as shown below to retrieve the SID of the user opening a file. The code is pretty simple (all error checking has been removed to make it more readable)

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS = pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT = SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

Using the PoolTag app from OSR (Thank you OSR!) I’ve found that the ‘se’ tag is growing like crazy. If I comment out the SeQueryInformationToken call above, se stays quiet.

After Googling I’ve found one post from someone on this list from 2001 saying that he discovered (despite what the documentation says) that you have to free what you get back from this call. I’ve apparently confirmed this.

Can anyone tell me how to free it? Maybe I just need to free the SID within the TOKEN_USER? I’m stuck on this one.

Thanks for any help.

Doug

Your call is wrong. It should be something like:

PTOKEN_USER tu = NULL;

SeQueryInformationToken(pT, TokenUser, &tu);

Then reference the SID by tu->User.Sid

I’m not aware of anything that needs to be freed. I use it extensively
without leaks.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@poweradmin.com
Sent: Thursday, November 09, 2006 12:35 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Help with SeQueryInformationToken leaks

I’m using SeQueryInformationToken as shown below to retrieve the SID of the
user opening a file. The code is pretty simple (all error checking has been
removed to make it more readable)

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

Using the PoolTag app from OSR (Thank you OSR!) I’ve found that the ‘se’ tag
is growing like crazy. If I comment out the SeQueryInformationToken call
above, se stays quiet.

After Googling I’ve found one post from someone on this list from 2001
saying that he discovered (despite what the documentation says) that you
have to free what you get back from this call. I’ve apparently confirmed
this.

Can anyone tell me how to free it? Maybe I just need to free the SID within
the TOKEN_USER? I’m stuck on this one.

Thanks for any help.

Doug


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

I know it took a lot of playing around to get the SID out, so I could be calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew there was any leak at all until it got called roughly a million times–then the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to make sure the SID is valid?

Doug

Your call is wrong. It should be something like:

PTOKEN_USER tu = NULL;

SeQueryInformationToken(pT, TokenUser, &tu);

Then reference the SID by tu->User.Sid

I’m not aware of anything that needs to be freed. I use it extensively
without leaks.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@poweradmin.com
Sent: Thursday, November 09, 2006 12:35 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Help with SeQueryInformationToken leaks

I’m using SeQueryInformationToken as shown below to retrieve the SID of the
user opening a file. The code is pretty simple (all error checking has been
removed to make it more readable)

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

Using the PoolTag app from OSR (Thank you OSR!) I’ve found that the ‘se’ tag
is growing like crazy. If I comment out the SeQueryInformationToken call
above, se stays quiet.

After Googling I’ve found one post from someone on this list from 2001
saying that he discovered (despite what the documentation says) that you
have to free what you get back from this call. I’ve apparently confirmed
this.

Can anyone tell me how to free it? Maybe I just need to free the SID within
the TOKEN_USER? I’m stuck on this one.

Thanks for any help.

Doug


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Are you using PsReferenceXxxxToken to get the token or using an already present token (from the IRP directly)?
If not, nothing needs freeing here.

xxxxx@poweradmin.com wrote:

I know it took a lot of playing around to get the SID out, so I could be calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew there was any leak at all until it got called roughly a million times–then the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to make sure the SID is valid?

Doug

> Your call is wrong. It should be something like:
>
> PTOKEN_USER tu = NULL;
> …
> SeQueryInformationToken(pT, TokenUser, &tu);
>
> Then reference the SID by tu->User.Sid


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.

I’ve changed to calling like Ken recommended, but no difference.

To answer Dejan’s question, I’m simply querying the PACCESS_TOKEN which I
got from SeQuerySubjectContextToken (which in turn comes from the
PIO_STACK_LOCATION).

Instead of that, I tried doing a SeCaptureSubjectContext and then
SeLockSubjectContext (and then unlock and release)–it makes no difference.

If I call SeQueryInformationToken from the dispatch routine, the Se paged
pool tag allocations goes through the roof.

I don’t see any other way to do this.

How else does one go about getting the user that is making an IRP_MJ_CREATE
call?

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

One final note: I’m compiling for Win2K, but even changing to WXP doesn’t
change anything.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
Sent: Thursday, November 09, 2006 1:33 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Help with SeQueryInformationToken leaks

Are you using PsReferenceXxxxToken to get the token or using an already
present token (from the IRP directly)?
If not, nothing needs freeing here.

xxxxx@poweradmin.com wrote:

I know it took a lot of playing around to get the SID out, so I could be
calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew
there was any leak at all until it got called roughly a million times–then
the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to
make sure the SID is valid?

Doug

> Your call is wrong. It should be something like:
>
> PTOKEN_USER tu = NULL;
> …
> SeQueryInformationToken(pT, TokenUser, &tu);
>
> Then reference the SID by tu->User.Sid


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

> How else does one go about getting the user that is making an
IRP_MJ_CREATE call?

This is how I do it in my minifilter, but I think it’s generic:

  1. Check to see if the thread is impersonating anyone.

SECURITY_IMPERSONATION_LEVEL ImpersonationLevel;
BOOLEAN EffectiveOnly, CopyOnOpen;
PACCESS_TOKEN lpToken;

lpToken = PsReferenceImpersonationToken( PsGetCurrentThread(),
&CopyOnOpen, &EffectiveOnly, &ImpersonationLevel );

1a. If you get a non-NULL value in lpToken, the thread is impersonating
someone and you must use the impersonation token. However, if it is
impersonating someone and the process is the System Process ID and the
TokenSource is “NtLmSsp”, then the user is remote and you cannot get his SID
(by any means I’m aware of).

1b. If it’s not impersonated (lpToken == NULL), get the primary token:

lpToken = PsReferencePrimaryToken( PsGetCurrentProcess() );

  1. Using this token, call SeQueryInformationToken to get the user:

PTOKEN_USER lpTokenUser;
status = SeQueryInformationToken( lpToken, TokenUser, &lpTokenUser );

  1. You now have the SID in lpTokenUser->User.Sid. Have your way with it.

  2. When you’re done, dereference the access token:

PsDereferencePrimaryToken( lpToken );
or
PsDereferenceImpersonationToken( lpToken );

Note that most of this will only work in the DISPATCH side of IRP_MJ_CREATE,
when you’re usually in the user context (however, there may be times when
that’s not true, like calls from drivers above you).

HTH,
Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Buy
Sent: Thursday, November 09, 2006 8:31 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Help with SeQueryInformationToken leaks

I’ve changed to calling like Ken recommended, but no difference.

To answer Dejan’s question, I’m simply querying the PACCESS_TOKEN which I
got from SeQuerySubjectContextToken (which in turn comes from the
PIO_STACK_LOCATION).

Instead of that, I tried doing a SeCaptureSubjectContext and then
SeLockSubjectContext (and then unlock and release)–it makes no difference.

If I call SeQueryInformationToken from the dispatch routine, the Se paged
pool tag allocations goes through the roof.

I don’t see any other way to do this.

How else does one go about getting the user that is making an IRP_MJ_CREATE
call?

if(IRP_MJ_CREATE == pIrpStack->MajorFunction)
{
PACCESS_STATE pAS =
pIrpStack->Parameters.Create.SecurityContext->AccessState;
PACCESS_TOKEN pT =
SeQuerySubjectContextToken(&pAS->SubjectSecurityContext);
TOKEN_USER tu = {0};
char buffer[SECURITY_MAX_SID_SIZE + 100] = {0};
tu.User.Sid = (PSID)buffer;
SeQueryInformationToken(pT, TokenUser, (PVOID)&tu);

One final note: I’m compiling for Win2K, but even changing to WXP doesn’t
change anything.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Dejan Maksimovic
Sent: Thursday, November 09, 2006 1:33 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Help with SeQueryInformationToken leaks

Are you using PsReferenceXxxxToken to get the token or using an already
present token (from the IRP directly)?
If not, nothing needs freeing here.

xxxxx@poweradmin.com wrote:

I know it took a lot of playing around to get the SID out, so I could be
calling it wrong.

Have you watched the ‘se’ tag when your app is running? I never knew
there was any leak at all until it got called roughly a million times–then
the server hung.

Could it possibly be the call to RtlValidSid (not shown) that I use to
make sure the SID is valid?

Doug

> Your call is wrong. It should be something like:
>
> PTOKEN_USER tu = NULL;
> …
> SeQueryInformationToken(pT, TokenUser, &tu);
>
> Then reference the SID by tu->User.Sid


King regards, Dejan
http://www.alfasp.com
File system audit, security and encryption kits.


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@poweradmin.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com