STATUS_LOGON_FAILURE returned in FltCreateFile of network file

OSR_Community_User · April 22, 2010, 8:45am

Hi everyone,

is my first time posting on the list. i am developping a file system
filter driver and i have found a problem when within the pre-create of
a network file i try to perform a FltCreateFile of another network
file in the same directory of the first one. The problem definition
is: given a network file f1.txt located in \192.168.1.2\testdir, i
perform the creation of a network file f2.txt located in the same
place via FltCreateFile getting as return status STATUS_LOGON_FAILURE.

The code is:

// Initialize object attributes
InitializeObjectAttributes(&objectAttributes,
&streamContext->AuxiliarFileName,
/* \Device\LanmanRedirector\192.168.1.2\testdir\f2.txt */
OBJ_KERNEL_HANDLE,
NULL,
NULL);

// Open/Create file
status = FltCreateFile(
FilterHandle,
Data->Iopb->TargetInstance,
AuxiliarFileHandle,
FILE_READ_DATA,
&objectAttributes,
&ioStatus,
(PLARGE_INTEGER) NULL,
FILE_ATTRIBUTE_NORMAL,
FILE_SHARE_READ | FILE_SHARE_WRITE |
FILE_SHARE_DELETE,
FILE_OPEN_IF,
FILE_COMPLETE_IF_OPLOCKED | FILE_WRITE_THROUGH ,
NULL,
0L,
IO_IGNORE_SHARE_ACCESS_CHECK);

Problem seems to be that filter code is executed in System thread
context, so user process network session privileges are not passed to
System thread context, is it like that?
I have tried to solve the problem using impersonation, but the problem
is not solved and the status returned is the same:
STATUS_LOGON_FAILURE.
The code used to impersonation is the following

SECURITY_QUALITY_OF_SERVICE ClientSecurityQos;

ClientSecurityQos.Length = sizeof(ClientSecurityQos);
ClientSecurityQos.ImpersonationLevel = SecurityDelegation;
ClientSecurityQos.ContextTrackingMode = SECURITY_STATIC_TRACKING;
ClientSecurityQos.EffectiveOnly = TRUE;

status = SeCreateClientSecurity(
Data->Thread,
&ClientSecurityQos,
FALSE,
&ClientContext
);

// Apply impersonation
status = SeImpersonateClientEx(
&ClientContext,
NULL
);

// trigger FltCreateFile

I don’t really know what i am doing wrong.

Other solution is to open a new session (from System) with the network
in order to get the privileges, but i didn’t find documentation about
how to login from a file system filter.

I would appreciate any help to solve this problem.

Thanks.
Fran

Alex_Carp · April 22, 2010, 11:50am

Are you sure you’re in a system context ? Usually preCreate for a file is called in the context of the process opening that file. So you should be in the context of the process trying to open f1.txt. (please note that i said SHOULD… a create might be pended so the reliable way to impersonate the original context is by using Parameters.Create.SecurityContext from the IO_STACK_LOCATION or the _FLT_IO_PARAMETER_BLOCK)…

Also, are you sure that the create for f1.txt would be successful ? Perhaps it would fail in the same way and the application knows how to handle it ?

A minifilter doing things in preCreate cannot assume that the user’s request would succeed and it must fail the user’s create if something goes wrong…

Thanks,
Alex.

OSR_Community_User · April 23, 2010, 3:58am

Hi,

I’m so sorry i post in ntdev list. I’m going to focus in ntfsd.

How could i check if the pre-create is in the process or system context?

If i disable the creation of the f2.txt network file in the
pre-create, the creation of f1.txt finish successfully. I first log in
the network bication before i perform the create, so the process
context stores the security information needed to access the secured
object, f1.txt.
Is it somehow related that f2.txt does not exist in the network location?

I try to perform an impersonation using _FLT_IO_PARAMETER_BLOCK and
FltCreateFile returned the same error: STATUS_LOGON_FAILURE.

The new code for the impersonation is the following:

ClientSecurityQos.Length = sizeof(ClientSecurityQos);
ClientSecurityQos.ImpersonationLevel = SecurityDelegation;
ClientSecurityQos.ContextTrackingMode = SECURITY_STATIC_TRACKING;
ClientSecurityQos.EffectiveOnly = TRUE;

// 1. Initialize the Object Security Descriptor
status = SeCreateClientSecurityFromSubjectContext(

&Data->Iopb->Parameters.Create.SecurityContext->AccessState->SubjectSecurityContext,
&ClientSecurityQos,
FALSE,
&ClientContext
);

// 2. Apply impersonation
status = SeImpersonateClientEx(
&ClientContext,
NULL
);

And i also complete new object attributes with:

objectAttributes.SecurityQualityOfService =
Data->Iopb->Parameters.Create.SecurityContext->SecurityQos;

with no effect.

Thank you.
Fran

2010/4/22 :
> Are you sure you’re in a system context ? Usually preCreate for a file is called in the context of the process opening that file. So you should be in the context of the process trying to open f1.txt. (please note that i said SHOULD… a create might be pended so the reliable way to impersonate the original context is by using Parameters.Create.SecurityContext from the IO_STACK_LOCATION or the _FLT_IO_PARAMETER_BLOCK)…
>
> Also, are you sure that the create for f1.txt would be successful ? Perhaps it would fail in the same way and the application knows how to handle it ?
>
> A minifilter doing things in preCreate cannot assume that the user’s request would succeed and it must fail the user’s create if something goes wrong…
>
> Thanks,
> Alex.
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

Alex_Carp · April 23, 2010, 11:53am

Hi Frank,

You shouldn’t really need to check (unless you want to do that for debugging
purposes ? - FltGetRequestorProcessId()) and you should be fine just using
the security context always (I think). I have some concerns about the
impersonation part :

not sure about setting objectAttributes. SecurityQualityOfService
directly , I think all that is needed for objectAttributes is to pass in the
security context from the SecurityContext… it is in there somewhere; also,
).
SecurityDelegation might be a bit much, maybe SecurityImpersonation is
enough ?

However, it generally is considered bad form for a filter to change the
context in IRP_MJ_CREATE. I think it can happen (i haven’t tried it but one
could potentially pend an IRP_MJ_CREATE and continue on a different
thread…) but it’s probably a bug in the other filter. MSDN states that
“IRP_MJ_CREATE requests arrive in the context of the thread and the process
that opened or created the file. A driver can record per-caller information,
if required.” (“Handling IRPs: What Every Driver Writer Needs to Know”,
currently at http://msdn.microsoft.com/en-us/library/ms810023.aspx). So you
should be in the caller context.

I’m not sure why you get the STATUS_LOGON_FAILURE, have you tried wireshark
to look at what happens over the wire ? Also, have you tried both with
f2.txt present and without it? If f2.txt exists but your create still fails,
try to change the name of the file in the user’s request (for debugging
purposes only, of course) from f1.txt to f2.txt and let it continue… see
what happens then ?

I’m sorry but I haven’t seen this before so I’m just suggesting different
random things that I would do in order to debug the issue :).

Thanks,
Alex.

OSR_Community_User · April 26, 2010, 3:54am

Hi,

thank you for your help, it made me think that it could be a code bug
and it was.
After fixing the bug i checked that the pre-create had access to the
network resource.

Thank you for the help
Fran

2010/4/23 Alex Carp :
> Hi Frank,
>
> You shouldn’t really need to check (unless you want to do that for debugging
> purposes ? - FltGetRequestorProcessId()) and you should be fine just using
> the security context always (I think). I have some concerns about the
> impersonation part :
> 1. not sure about setting objectAttributes. SecurityQualityOfService
> directly , I think all that is needed for objectAttributes is to pass in the
> security context from the SecurityContext… it is in there somewhere; also,
> ).
> 2. SecurityDelegation might be a bit much, maybe SecurityImpersonation is
> enough ?
>
> However, it generally is considered bad form for a filter to change the
> context in IRP_MJ_CREATE. I think it can happen (i haven’t tried it but one
> could potentially pend an IRP_MJ_CREATE and continue on a different
> thread…) but it’s probably a bug in the other filter. MSDN states that
> “IRP_MJ_CREATE requests arrive in the context of the thread and the process
> that opened or created the file. A driver can record per-caller information,
> if required.” (“Handling IRPs: What Every Driver Writer Needs to Know”,
> currently at http://msdn.microsoft.com/en-us/library/ms810023.aspx). So you
> should be in the caller context.
>
> I’m not sure why you get the STATUS_LOGON_FAILURE, have you tried wireshark
> to look at what happens over the wire ? Also, have you tried both with
> f2.txt present and without it? If f2.txt exists but your create still fails,
> try to change the name of the file in the user’s request (for debugging
> purposes only, of course) from f1.txt to f2.txt and let it continue… see
> what happens then ?
>
> I’m sorry but I haven’t seen this before so I’m just suggesting different
> random things that I would do in order to debug the issue :).
>
> Thanks,
> Alex.
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule of debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>