Creating UNC directories in kernel-mode

NTFSD
1

I’m trying to create a directory from kernel-mode on a UNC path. The
situation is that my system service impersonates a logged-on user, and
then makes an IOCTL call into my driver, which tries to create the
directory using ZwCreateFile.

The problem is I always get STATUS_ACCESS_DENIED when doing so. First I
assumed it was a problem with the impersonation, so I inserted some test
code into the service right before the IOCTL to attempt to create the
directory using the Win32 API CreateDirectory. Well, this worked. This
led me to believe that somehow I was passing the wrong parameters to
ZwCreateFile.

I went ahead and reverse-engineered CreateDirectory, and all it was
doing was a simple ZwCreateFile just like my driver. I pulled out the
EXACT values for all arguments (flags, attributes, whatnot) and
duplicated these in my driver. Surely it must work now. (Note that it
works fine for non-UNC paths).

Nope, still STATUS_ACCESS_DENIED. Apparently the system is treating the
request differently in a non-trivial way (i.e. not simply as an
indicator that memory addresses should be verified differently, etc.)
simply because the create was initiated from user-mode, not kernel-mode.

Why? I though the thread token carries over the user-mode/kernel-mode
barrier. I’m about to dissect the IRPs being generated for differences,
and compare the security context of the threads, but it seems
counterintuitive to say the least.

  • Nicholas Ryan
2

What I did was to have the service to login using an account that has
the required permissions to access the share. In my driver, I created a
system thread in the process context of the service; see process
parameter in PsCreateSystemThread().

When I needed to do file operations on the share, I did them in my
thread. Since this thread is in the context of the service and the
service has the proper credentials, there are no problems in opening
files on the share.

I have done this and it works. This is much less confusing than trying
to do impersonation. The nice thing about this method is that you can
give permission to the service that the user does not have. Your driver
can then access the share and present information from the share to the
user; but the user can not access the share directly without your
driver.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Thursday, October 17, 2002 11:20 AM
To: File Systems Developers
Subject: [ntfsd] Creating UNC directories in kernel-mode

I’m trying to create a directory from kernel-mode on a UNC path. The
situation is that my system service impersonates a logged-on user, and
then makes an IOCTL call into my driver, which tries to create the
directory using ZwCreateFile.

The problem is I always get STATUS_ACCESS_DENIED when doing so. First I
assumed it was a problem with the impersonation, so I inserted some test
code into the service right before the IOCTL to attempt to create the
directory using the Win32 API CreateDirectory. Well, this worked. This
led me to believe that somehow I was passing the wrong parameters to
ZwCreateFile.

I went ahead and reverse-engineered CreateDirectory, and all it was
doing was a simple ZwCreateFile just like my driver. I pulled out the
EXACT values for all arguments (flags, attributes, whatnot) and
duplicated these in my driver. Surely it must work now. (Note that it
works fine for non-UNC paths).

Nope, still STATUS_ACCESS_DENIED. Apparently the system is treating the
request differently in a non-trivial way (i.e. not simply as an
indicator that memory addresses should be verified differently, etc.)
simply because the create was initiated from user-mode, not kernel-mode.

Why? I though the thread token carries over the user-mode/kernel-mode
barrier. I’m about to dissect the IRPs being generated for differences,
and compare the security context of the threads, but it seems
counterintuitive to say the least.

  • Nicholas Ryan

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

3

Unfortuntely my service must function in multi-user environments (like
Terminal Services) so I must run as LocalSystem. But you’re right that
impersonation is a big mess under Windows. Consider this, for example:
if a user’s app calls into my service via my COM interface, and I
impersonate him using CoImpersonateClient, then my service can see his
mapped network drives in the context of that thread. However, if I
create a token using LogonUser (with LOGON32_LOGON_INTERACTIVE) and
impersonate with ImpersonateLoggedOnUser in a service-created thread,
the drives are not visible. Madness.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Thursday, October 17, 2002 11:29 AM
To: File Systems Developers
Subject: [ntfsd] RE: Creating UNC directories in kernel-mode

What I did was to have the service to login using an account
that has the required permissions to access the share. In my
driver, I created a system thread in the process context of
the service; see process parameter in PsCreateSystemThread().

When I needed to do file operations on the share, I did them
in my thread. Since this thread is in the context of the
service and the service has the proper credentials, there are
no problems in opening files on the share.

I have done this and it works. This is much less confusing
than trying to do impersonation. The nice thing about this
method is that you can give permission to the service that
the user does not have. Your driver can then access the share
and present information from the share to the user; but the
user can not access the share directly without your driver.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Thursday, October 17, 2002 11:20 AM
To: File Systems Developers
Subject: [ntfsd] Creating UNC directories in kernel-mode

I’m trying to create a directory from kernel-mode on a UNC
path. The situation is that my system service impersonates a
logged-on user, and then makes an IOCTL call into my driver,
which tries to create the directory using ZwCreateFile.

The problem is I always get STATUS_ACCESS_DENIED when doing
so. First I assumed it was a problem with the impersonation,
so I inserted some test code into the service right before
the IOCTL to attempt to create the directory using the Win32
API CreateDirectory. Well, this worked. This led me to
believe that somehow I was passing the wrong parameters to
ZwCreateFile.

I went ahead and reverse-engineered CreateDirectory, and all
it was doing was a simple ZwCreateFile just like my driver. I
pulled out the EXACT values for all arguments (flags,
attributes, whatnot) and duplicated these in my driver.
Surely it must work now. (Note that it works fine for non-UNC paths).

Nope, still STATUS_ACCESS_DENIED. Apparently the system is
treating the request differently in a non-trivial way (i.e.
not simply as an indicator that memory addresses should be
verified differently, etc.) simply because the create was
initiated from user-mode, not kernel-mode.

Why? I though the thread token carries over the
user-mode/kernel-mode barrier. I’m about to dissect the IRPs
being generated for differences, and compare the security
context of the threads, but it seems counterintuitive to say
the least.

  • Nicholas Ryan

You are currently subscribed to ntfsd as:
xxxxx@storagecraft.com To unsubscribe send a blank email to
%%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%

4

Why will this hamper you? You can create a special account for the
service and give it the required permissions to access the share. Will
this fail under TS?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Thursday, October 17, 2002 12:25 PM
To: File Systems Developers
Subject: [ntfsd] RE: Creating UNC directories in kernel-mode

Unfortuntely my service must function in multi-user environments (like
Terminal Services) so I must run as LocalSystem. But you’re right that
impersonation is a big mess under Windows. Consider this, for example:
if a user’s app calls into my service via my COM interface, and I
impersonate him using CoImpersonateClient, then my service can see his
mapped network drives in the context of that thread. However, if I
create a token using LogonUser (with LOGON32_LOGON_INTERACTIVE) and
impersonate with ImpersonateLoggedOnUser in a service-created thread,
the drives are not visible. Madness.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Thursday, October 17, 2002 11:29 AM
To: File Systems Developers
Subject: [ntfsd] RE: Creating UNC directories in kernel-mode

What I did was to have the service to login using an account
that has the required permissions to access the share. In my
driver, I created a system thread in the process context of
the service; see process parameter in PsCreateSystemThread().

When I needed to do file operations on the share, I did them
in my thread. Since this thread is in the context of the
service and the service has the proper credentials, there are
no problems in opening files on the share.

I have done this and it works. This is much less confusing
than trying to do impersonation. The nice thing about this
method is that you can give permission to the service that
the user does not have. Your driver can then access the share
and present information from the share to the user; but the
user can not access the share directly without your driver.

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Thursday, October 17, 2002 11:20 AM
To: File Systems Developers
Subject: [ntfsd] Creating UNC directories in kernel-mode

I’m trying to create a directory from kernel-mode on a UNC
path. The situation is that my system service impersonates a
logged-on user, and then makes an IOCTL call into my driver,
which tries to create the directory using ZwCreateFile.

The problem is I always get STATUS_ACCESS_DENIED when doing
so. First I assumed it was a problem with the impersonation,
so I inserted some test code into the service right before
the IOCTL to attempt to create the directory using the Win32
API CreateDirectory. Well, this worked. This led me to
believe that somehow I was passing the wrong parameters to
ZwCreateFile.

I went ahead and reverse-engineered CreateDirectory, and all
it was doing was a simple ZwCreateFile just like my driver. I
pulled out the EXACT values for all arguments (flags,
attributes, whatnot) and duplicated these in my driver.
Surely it must work now. (Note that it works fine for non-UNC paths).

Nope, still STATUS_ACCESS_DENIED. Apparently the system is
treating the request differently in a non-trivial way (i.e.
not simply as an indicator that memory addresses should be
verified differently, etc.) simply because the create was
initiated from user-mode, not kernel-mode.

Why? I though the thread token carries over the
user-mode/kernel-mode barrier. I’m about to dissect the IRPs
being generated for differences, and compare the security
context of the threads, but it seems counterintuitive to say
the least.

  • Nicholas Ryan

You are currently subscribed to ntfsd as:
xxxxx@storagecraft.com To unsubscribe send a blank email to
%%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

5

I need access to arbitrary shares. Basically, if some user Foo logs into
a computer with my service running, my service needs access to all
shares that Foo has access to in Foo’s current session.

  • Nicholas Ryan

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
Sent: Thursday, October 17, 2002 12:36 PM
To: File Systems Developers
Subject: [ntfsd] RE: Creating UNC directories in kernel-mode

Why will this hamper you? You can create a special account
for the service and give it the required permissions to
access the share. Will this fail under TS?

Jamey

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
Sent: Thursday, October 17, 2002 12:25 PM
To: File Systems Developers
Subject: [ntfsd] RE: Creating UNC directories in kernel-mode

Unfortuntely my service must function in multi-user
environments (like Terminal Services) so I must run as
LocalSystem. But you’re right that impersonation is a big
mess under Windows. Consider this, for example: if a user’s
app calls into my service via my COM interface, and I
impersonate him using CoImpersonateClient, then my service
can see his mapped network drives in the context of that
thread. However, if I create a token using LogonUser (with
LOGON32_LOGON_INTERACTIVE) and impersonate with
ImpersonateLoggedOnUser in a service-created thread, the
drives are not visible. Madness.

  • Nicholas Ryan

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jamey Kirby
> Sent: Thursday, October 17, 2002 11:29 AM
> To: File Systems Developers
> Subject: [ntfsd] RE: Creating UNC directories in kernel-mode
>
>
> What I did was to have the service to login using an account
> that has the required permissions to access the share. In my
> driver, I created a system thread in the process context of
> the service; see process parameter in PsCreateSystemThread().
>
> When I needed to do file operations on the share, I did them
> in my thread. Since this thread is in the context of the
> service and the service has the proper credentials, there are
> no problems in opening files on the share.
>
> I have done this and it works. This is much less confusing
> than trying to do impersonation. The nice thing about this
> method is that you can give permission to the service that
> the user does not have. Your driver can then access the share
> and present information from the share to the user; but the
> user can not access the share directly without your driver.
>
> Jamey
>
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Nicholas Ryan
> Sent: Thursday, October 17, 2002 11:20 AM
> To: File Systems Developers
> Subject: [ntfsd] Creating UNC directories in kernel-mode
>
> I’m trying to create a directory from kernel-mode on a UNC
> path. The situation is that my system service impersonates a
> logged-on user, and then makes an IOCTL call into my driver,
> which tries to create the directory using ZwCreateFile.
>
> The problem is I always get STATUS_ACCESS_DENIED when doing
> so. First I assumed it was a problem with the impersonation,
> so I inserted some test code into the service right before
> the IOCTL to attempt to create the directory using the Win32
> API CreateDirectory. Well, this worked. This led me to
> believe that somehow I was passing the wrong parameters to
> ZwCreateFile.
>
> I went ahead and reverse-engineered CreateDirectory, and all
> it was doing was a simple ZwCreateFile just like my driver. I
> pulled out the EXACT values for all arguments (flags,
> attributes, whatnot) and duplicated these in my driver.
> Surely it must work now. (Note that it works fine for
non-UNC paths).
>
> Nope, still STATUS_ACCESS_DENIED. Apparently the system is
> treating the request differently in a non-trivial way (i.e.
> not simply as an indicator that memory addresses should be
> verified differently, etc.) simply because the create was
> initiated from user-mode, not kernel-mode.
>
> Why? I though the thread token carries over the
> user-mode/kernel-mode barrier. I’m about to dissect the IRPs
> being generated for differences, and compare the security
> context of the threads, but it seems counterintuitive to say
> the least.
>
> - Nicholas Ryan
>
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@storagecraft.com To unsubscribe send a blank email to
> %%email.unsub%%
>
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@nryan.com
> To unsubscribe send a blank email to %%email.unsub%%
>

You are currently subscribed to ntfsd as:
xxxxx@storagecraft.com To unsubscribe send a blank email to
%%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@nryan.com
To unsubscribe send a blank email to %%email.unsub%%

6

I’ve seen this work with impersonation in user mode via
ImpersonateLoggedOnUser, with tokens from LogonUser and also from SSPI.
I find it somewhat hard to believe that it can’t work in the kernel.