Security Context in Redirector Thread

Hi,

I have developed an NT kernel mode file system filter driver, which
attaches to specified CDFS devices. Once attached, the filter driver checks
for every IRP_MJ_CREATE the rights of the calling user via SeAccessCheck()
agains a given Security Descriptor for that device. The Security
Descriptor’s ACL contains a single ACE granting full access to the group of
local administrators only.

My filter driver works well as long as I access the device locally, even
when a SUBST command is involved. The filter driver fails as soon as I
access the device via redirector, i.e when I map a network drive to the
shared CD devices. In this case access is granted to everyone, even when I
log on as guest.

By analysing the debug output, that my filter driver produces I can see
that the right security descriptor is used and that the rights are checked,
but granted instead of denied. The only explanation is, that the thread
calling my filter driver must be running in a security context of system or
administator account, but in the NT security specifications Microsoft says,
that the redirector server in such a case creates a worker thread
impersonating the calling user/client.

I have tried to impersonate the calling client myself within the filter
driver using SeCreateClientSecurity() und SeImpersonateClient(), but maybe
I didn’t use the calls the right way.

Here is the code segment in which the user’s rights are checked:

switch(currentIrpStack->MajorFunction)
{
case IRP_MJ_CREATE:
pSD = …; // our Security Descriptor
if (pSD)
{
bAccess = SeAccessCheck(pSD,

&(currentIrpStack->Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext),
FALSE,

currentIrpStack->Parameters.Create.SecurityContext->DesiredAccess,
(ACCESS_MASK)0,
&pPrivileges,
IoGetFileObjectGenericMapping(),
Irp->RequestorMode,
&GrantedAccess,
&status);

if (!bAccess)
{ // no rights for this volume!
Irp->IoStatus.Status = status;
}

How can I prevent a remote user accessing the CD device ‘protected’ by my
filter driver?

Lothar


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

The problem is that SRV requests always arrive from a kernel thread in the
system process context. Thus Irp->RequestorMode is probably KernelMode.

Unless I’m mistaken, you will note that SL_FORCE_ACCESS_CHECK is set in the
I/O stack location of the I/O request. IF this is the case, you should NOT
be using Irp->RequestorMode, but instead you should explicitly pass in
UserMode (to force an access check.)

Thus, change your SeAccessCheck call to:

bAccess = SeAccessCheck(pSD,

&(currentIrpStack->Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext),
FALSE,

currentIrpStack->Parameters.Create.SecurityContext->DesiredAccess,
(ACCESS_MASK)0,
&pPrivileges,
IoGetFileObjectGenericMapping(),
currentIrpStack->Flags & SL_FORCE_ACCESS_CHECK ?
UserMode : Irp->RequestorMode,
&GrantedAccess,
&status);

Otherwise, when you specify kernel mode access, the access is always going
to be granted.

I hope this helps.

Regards,

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

At 04:41 PM 3/16/2001 +0100, xxxxx@t-systems.de wrote:

Hi,

I have developed an NT kernel mode file system filter driver, which
attaches to specified CDFS devices. Once attached, the filter driver checks
for every IRP_MJ_CREATE the rights of the calling user via SeAccessCheck()
agains a given Security Descriptor for that device. The Security
Descriptor’s ACL contains a single ACE granting full access to the group of
local administrators only.

My filter driver works well as long as I access the device locally, even
when a SUBST command is involved. The filter driver fails as soon as I
access the device via redirector, i.e when I map a network drive to the
shared CD devices. In this case access is granted to everyone, even when I
log on as guest.

By analysing the debug output, that my filter driver produces I can see
that the right security descriptor is used and that the rights are checked,
but granted instead of denied. The only explanation is, that the thread
calling my filter driver must be running in a security context of system or
administator account, but in the NT security specifications Microsoft says,
that the redirector server in such a case creates a worker thread
impersonating the calling user/client.

I have tried to impersonate the calling client myself within the filter
driver using SeCreateClientSecurity() und SeImpersonateClient(), but maybe
I didn’t use the calls the right way.

Here is the code segment in which the user’s rights are checked:

switch(currentIrpStack->MajorFunction)
{
case IRP_MJ_CREATE:
pSD = …; // our Security Descriptor
if (pSD)
{
bAccess = SeAccessCheck(pSD,

&(currentIrpStack->Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext),
FALSE,

currentIrpStack->Parameters.Create.SecurityContext->DesiredAccess,
(ACCESS_MASK)0,
&pPrivileges,
IoGetFileObjectGenericMapping(),
Irp->RequestorMode,
&GrantedAccess,
&status);

if (!bAccess)
{ // no rights for this volume!
Irp->IoStatus.Status = status;
}

How can I prevent a remote user accessing the CD device ‘protected’ by my
filter driver?

Lothar


You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Hi Tony,

thanks for your help. You saved my life!

Lothar


You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com