Proper terminology & type of filter driver to use...

NTFSD
1

It's oh so much fun trying to sort out the proper terminology to make sure
that I'm using "current best practices & procedures" for developing a filter
driver.

The current IFS docs in the 6000 build of the WDK has a section on File
System Filger Driver Classes & Class GUIDs, where the "FSFilter Security
Enhancer" class is discussed. This appears to be the class that I would
need to assign to my filter driver as its intended purpose is to enhance the
security of NTFS beyond the simple use of DACLs & ACEs.

The book, "Microsoft Windows Internals", 4th edition, discusses on page 706
the "Filesystem Filter Manager", and the advent of support for minifilters
on WinXP SP2 & Win2K3 & newer. That section also refers to file system
filter drivers as "legacy", which I take to mean the ones that are discussed
in the IFS that otherwise lack the moniker "legacy" in front of their names.
In the IFS sections on minifilters, there's no discussion of driver
classes, but there is mention of "altitude" being a value, assigned by
Microsoft, that controls what order minifilters are stacked on top of each
other.

Given the information above, I'm trying to determine which type of filter
driver is more appropriate. It appears that minifilters are, beyond a
doubt, using a newer driver development paradigm/framework/methodology, but
I'm not sure if a minifilter will allow me to implement what I need to
implement.

In a nutshell, I either need to fudge the results of IRP_MJ_QUERY_SECURITY &
IRP_MJ_SET_SECURITY and alter the contents of a DACL, or else I need to be
able to override a failed access-check that's based solely on the DACL and
force it to succeed based on additional security criteria that my filter is
aware of. Altering the contents of the DACL as it is read to insert
additional ACEs in it is one method, with a corresponding part that removes
those additional ACEs from the DACL when it is written back with the "set
security" operation. The other possiblity is to take a failed IRP_MJ_CREATE
[or similar request that results in opening a file for read/write or rename
or delete operations] and either do some impersonation or make an underlying
driver call to force the operation to succeed and return a valid file handle
to the user-mode process that initiated the operation to begin with.

Which type of filter driver is more appropriate? A minifilter or [legacy]
file system filter driver?

TIA,

Chuck

2

“Chuck Chopp” wrote in message news:xxxxx@ntfsd…
>
> Given the information above, I’m trying to determine which type of filter
> driver is more appropriate. It appears that minifilters are, beyond a
> doubt, using a newer driver development paradigm/framework/methodology,
> but I’m not sure if a minifilter will allow me to implement what I need
> to implement.
>
> In a nutshell, I either need to fudge the results of
> IRP_MJ_QUERY_SECURITY & IRP_MJ_SET_SECURITY and alter the contents of a
> DACL, or else I need to be able to override a failed access-check that’s
> based solely on the DACL and force it to succeed based on additional
> security criteria that my filter is aware of. Altering the contents of
> the DACL as it is read to insert additional ACEs in it is one method,
> with a corresponding part that removes those additional ACEs from the
> DACL when it is written back with the “set security” operation. The
> other possiblity is to take a failed IRP_MJ_CREATE [or similar request
> that results in opening a file for read/write or rename or delete
> operations] and either do some impersonation or make an underlying driver
> call to force the operation to succeed and return a valid file handle to
> the user-mode process that initiated the operation to begin with.
>
> Which type of filter driver is more appropriate? A minifilter or
> [legacy] file system filter driver?
>
Chuck,

Assuming you can live with the limitations of mini-filters (namely
that they require Windows 2000 SP4, Windows XP SP2, Windows Server 2003
SP1, Vista or later OS’es) use a mini-filter. Mini-filters will be easier
to work with and can easily do what you ask.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

3

If you want to be able to unload it, which certainly would be nice
during development, a minifilter is the way to go. That being said,
this is not really my thing, and there may be more important reasons why
this is or is not the way to go.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chuck Chopp
Sent: Tuesday, August 28, 2007 12:30
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Proper terminology & type of filter driver to use...

It's oh so much fun trying to sort out the proper terminology to make
sure
that I'm using "current best practices & procedures" for developing a
filter
driver.

The current IFS docs in the 6000 build of the WDK has a section on File
System Filger Driver Classes & Class GUIDs, where the "FSFilter Security

Enhancer" class is discussed. This appears to be the class that I would

need to assign to my filter driver as its intended purpose is to enhance
the
security of NTFS beyond the simple use of DACLs & ACEs.

The book, "Microsoft Windows Internals", 4th edition, discusses on page
706
the "Filesystem Filter Manager", and the advent of support for
minifilters
on WinXP SP2 & Win2K3 & newer. That section also refers to file system
filter drivers as "legacy", which I take to mean the ones that are
discussed
in the IFS that otherwise lack the moniker "legacy" in front of their
names.
In the IFS sections on minifilters, there's no discussion of driver
classes, but there is mention of "altitude" being a value, assigned by
Microsoft, that controls what order minifilters are stacked on top of
each
other.

Given the information above, I'm trying to determine which type of
filter
driver is more appropriate. It appears that minifilters are, beyond a
doubt, using a newer driver development paradigm/framework/methodology,
but
I'm not sure if a minifilter will allow me to implement what I need to
implement.

In a nutshell, I either need to fudge the results of
IRP_MJ_QUERY_SECURITY &
IRP_MJ_SET_SECURITY and alter the contents of a DACL, or else I need to
be
able to override a failed access-check that's based solely on the DACL
and
force it to succeed based on additional security criteria that my filter
is
aware of. Altering the contents of the DACL as it is read to insert
additional ACEs in it is one method, with a corresponding part that
removes
those additional ACEs from the DACL when it is written back with the
"set
security" operation. The other possiblity is to take a failed
IRP_MJ_CREATE
[or similar request that results in opening a file for read/write or
rename
or delete operations] and either do some impersonation or make an
underlying
driver call to force the operation to succeed and return a valid file
handle
to the user-mode process that initiated the operation to begin with.

Which type of filter driver is more appropriate? A minifilter or
[legacy]
file system filter driver?

TIA,

Chuck

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:

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

4

Don Burn wrote:

Chuck,

Assuming you can live with the limitations of mini-filters (namely
that they require Windows 2000 SP4, Windows XP SP2, Windows Server 2003
SP1, Vista or later OS'es) use a mini-filter. Mini-filters will be easier
to work with and can easily do what you ask.

Don,

Thanks for the quick response. Yes, those Windows version & SP level
restrictions are not an issue for me at all, in terms of the platforms on
which I need to have the driver running.

I'll focuse the remainder of my efforts on wrapping my head around the
minifilter model and the driver samples.

Chuck

5

“Martin O’Brien” wrote in message
news:xxxxx@ntfsd…
If you want to be able to unload it, which certainly would be nice
during development, a minifilter is the way to go. That being said,
this is not really my thing, and there may be more important reasons why
this is or is not the way to go.

Martin and Chuck,

Having now done a few of the mini-filters, I can say for what Chuck
wants to do they are the right model. There are a number of problems with
the mini-filter model, but for simple filtering they are great. Some of
the problems I see are:

1. No easy way to generate a number of file system requests from the
mini-filter. Some of this is improving, but the fact that many of the
improvements are Vista only does not help.

2. No easy way to redirect a file request. In a regular filter it is
fairly easy to send the IRP elsewhere, or use the IRP with a different file
object. The mini-filter model makes these impossible, and one has to
create a new request (see comment 1) to do that type of filtering.

3. No access to the IRP. Sorry but there are times that is what is
wanted (especially given 1 and 2) and there is no such model.

4. No secondary file object support or equivalent. One common
request on this forum is how to manage the cache directly. Secondary file
objects can do this (I suspect there are other ways). I have implemented
this in a mini-filter and it was a lot of code in a number of places. This
is the type of thing that mini-filters should do.

I am sure other folks could add to this list, but those are a few of
the problems I see in mini-filters. Again, Chuck what you describe does
not hit these so definitely use a mini-filter it is easy for those cases.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

6

Thanks, Don.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, August 28, 2007 12:58
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Proper terminology & type of filter driver to use…

“Martin O’Brien” wrote in message
news:xxxxx@ntfsd…
If you want to be able to unload it, which certainly would be nice
during development, a minifilter is the way to go. That being said,
this is not really my thing, and there may be more important reasons why
this is or is not the way to go.

Martin and Chuck,

Having now done a few of the mini-filters, I can say for what Chuck
wants to do they are the right model. There are a number of problems
with
the mini-filter model, but for simple filtering they are great. Some of

the problems I see are:

1. No easy way to generate a number of file system requests from
the
mini-filter. Some of this is improving, but the fact that many of the
improvements are Vista only does not help.

2. No easy way to redirect a file request. In a regular filter it
is
fairly easy to send the IRP elsewhere, or use the IRP with a different
file
object. The mini-filter model makes these impossible, and one has to
create a new request (see comment 1) to do that type of filtering.

3. No access to the IRP. Sorry but there are times that is what is

wanted (especially given 1 and 2) and there is no such model.

4. No secondary file object support or equivalent. One common
request on this forum is how to manage the cache directly. Secondary
file
objects can do this (I suspect there are other ways). I have
implemented
this in a mini-filter and it was a lot of code in a number of places.
This
is the type of thing that mini-filters should do.

I am sure other folks could add to this list, but those are a few of

the problems I see in mini-filters. Again, Chuck what you describe does

not hit these so definitely use a mini-filter it is easy for those
cases.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

7

Don Burn wrote:

Martin and Chuck,

Having now done a few of the mini-filters, I can say for what Chuck
wants to do they are the right model. There are a number of problems with
the mini-filter model, but for simple filtering they are great. Some of
the problems I see are:

  1. No easy way to generate a number of file system requests from the
    mini-filter. Some of this is improving, but the fact that many of the
    improvements are Vista only does not help.

  2. No easy way to redirect a file request. In a regular filter it is
    fairly easy to send the IRP elsewhere, or use the IRP with a different file
    object. The mini-filter model makes these impossible, and one has to
    create a new request (see comment 1) to do that type of filtering.

  3. No access to the IRP. Sorry but there are times that is what is
    wanted (especially given 1 and 2) and there is no such model.

  4. No secondary file object support or equivalent. One common
    request on this forum is how to manage the cache directly. Secondary file
    objects can do this (I suspect there are other ways). I have implemented
    this in a mini-filter and it was a lot of code in a number of places. This
    is the type of thing that mini-filters should do.

I am sure other folks could add to this list, but those are a few of
the problems I see in mini-filters. Again, Chuck what you describe does
not hit these so definitely use a mini-filter it is easy for those cases.

Don,

Thanks again for posting that additional information on where minifilters
have shortcomings.

I think that I'll be able to avoid the problems listed above, but that's
something that I'll have to verify as I dig a bit deeper into what my
minifilter will actually be doing in terms of performing some "on-the-fly"
alterations of a DACL as it iis read from or written to a file, or, in the
alternative implementation, to overriding the results of an access check and
forcing an IRP_MJ_CREATE operation to succeed based on additional security
information beyond what the normal DACL will allow.

Regardless of how it's achieved, once the file handle is returned to the
user-mode process, with the desired access flags set in the handle, all
future access via the handle only result in access checks being with the
access mask that's stored in the handle, rather than going out and testing
against the DACL stored with the file in the file system.

A few things that I'm thinking about give me some slight cause for concern
since I'm not entirely certiain how they'll get handled in code. Things
like access a file via File ID or GUID, for example, come to mind as being
of concern. Also, if I go with the method of altering the DACL on "on the
fly", so to speak, then I need to make sure that the part of the base NTFS
file system driver that does access checks upon handling an IRP_MJ_CREATE
call will actually result in the IRP_MJ_QUERY_SECURITY calls passing thru
the minifilter stack rather than be handled exclusively in an internal
manner within the NTFS file system driver. The code paths to be executed
and the layers of minifilters, file system filters and file system drivers
thru which and I/O request can travel becomes convoluted, so it's difficult
to know up front if the minifilter design I have in mind can be implemented
successfully.

Chuck

8

Chuck,

First I agree that a minifilter is the way to go for your purposes.

However:

[quote]
Also, if I go with the method of altering the DACL on “on the fly”, so to
speak, then I need to make sure that the part of the base NTFS file system
driver that does access checks upon handling an IRP_MJ_CREATE call will
actually result in the IRP_MJ_QUERY_SECURITY calls passing thru the
minifilter stack rather than be handled exclusively in an internal manner
within the NTFS file system driver.


The file system does not query itself for the ACL. It already has it.
Changing the result of the query security call will not affect the access
check. If you want to affect the access check, you must actually set the
ACL to what you want.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chuck Chopp
Sent: Tuesday, August 28, 2007 11:41 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Proper terminology & type of filter driver to use…

Don Burn wrote:

> Martin and Chuck,
>
> Having now done a few of the mini-filters, I can say for what
> Chuck wants to do they are the right model. There are a number of
> problems with the mini-filter model, but for simple filtering they are
> great. Some of the problems I see are:
>
> 1. No easy way to generate a number of file system requests from
> the mini-filter. Some of this is improving, but the fact that many of
> the improvements are Vista only does not help.
>
> 2. No easy way to redirect a file request. In a regular filter
> it is fairly easy to send the IRP elsewhere, or use the IRP with a
> different file object. The mini-filter model makes these impossible,
> and one has to create a new request (see comment 1) to do that type of
filtering.
>
> 3. No access to the IRP. Sorry but there are times that is what
> is wanted (especially given 1 and 2) and there is no such model.
>
> 4. No secondary file object support or equivalent. One common
> request on this forum is how to manage the cache directly. Secondary
> file objects can do this (I suspect there are other ways). I have
> implemented this in a mini-filter and it was a lot of code in a number
> of places. This is the type of thing that mini-filters should do.
>
> I am sure other folks could add to this list, but those are a few
> of the problems I see in mini-filters. Again, Chuck what you describe
> does not hit these so definitely use a mini-filter it is easy for those
cases.

Don,

Thanks again for posting that additional information on where minifilters
have shortcomings.

I think that I’ll be able to avoid the problems listed above, but that’s
something that I’ll have to verify as I dig a bit deeper into what my
minifilter will actually be doing in terms of performing some “on-the-fly”
alterations of a DACL as it iis read from or written to a file, or, in the
alternative implementation, to overriding the results of an access check and
forcing an IRP_MJ_CREATE operation to succeed based on additional security
information beyond what the normal DACL will allow.

Regardless of how it’s achieved, once the file handle is returned to the
user-mode process, with the desired access flags set in the handle, all
future access via the handle only result in access checks being with the
access mask that’s stored in the handle, rather than going out and testing
against the DACL stored with the file in the file system.

A few things that I’m thinking about give me some slight cause for concern
since I’m not entirely certiain how they’ll get handled in code. Things
like access a file via File ID or GUID, for example, come to mind as being
of concern. Also, if I go with the method of altering the DACL on “on the
fly”, so to speak, then I need to make sure that the part of the base NTFS
file system driver that does access checks upon handling an IRP_MJ_CREATE
call will actually result in the IRP_MJ_QUERY_SECURITY calls passing thru
the minifilter stack rather than be handled exclusively in an internal
manner within the NTFS file system driver. The code paths to be executed
and the layers of minifilters, file system filters and file system drivers
thru which and I/O request can travel becomes convoluted, so it’s difficult
to know up front if the minifilter design I have in mind can be implemented
successfully.

Chuck
–

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

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

9

Dan Kyler wrote:

Chuck,

First I agree that a minifilter is the way to go for your purposes.

However:

[quote]
Also, if I go with the method of altering the DACL on “on the fly”, so to
speak, then I need to make sure that the part of the base NTFS file system
driver that does access checks upon handling an IRP_MJ_CREATE call will
actually result in the IRP_MJ_QUERY_SECURITY calls passing thru the
minifilter stack rather than be handled exclusively in an internal manner
within the NTFS file system driver.

>
> The file system does not query itself for the ACL. It already has it.
> Changing the result of the query security call will not affect the access
> check. If you want to affect the access check, you must actually set the
> ACL to what you want.
>
> - Dan.

It was my understanding that the I/O Manager makes a call to the file system
using IRP_MJ_QUERY_SECURITY in order to get the SD to make the comparisons
for the access-check. If that’s not the case, then I may need to go with
the alternative idea where the driver computes a set of effective rights
based on other criteria besides the DACL and then forces the IRP_MJ_CREATE
call to be successful.

Part of the problem that I’m working around is the non-dynamic nature of
access-tokens. When a user logs on, their access-token is created and is
static thereafter. If they are granted membership in a group, or have their
membership in a group revoked, their access-token does not reflect these
changes. The application that I’m porting comes from a NetWare & eDirectory
environment where such changes are dynamic & take effect immediately [within
directory service replication & synchronization tolerances]. One way to
deal with this is to introduce additional criteria on which effective access
rights may be computed, and then to enforce that at the file system level.
One key requirement is that if this application is disabled, or fails in
anyway, or if the driver is removed, then NTFS security defaults back to
it’s normal behavior and none of the enhanced security features will be
present. That means that simply inserting additional ACEs into the DACL
that is stored persistently in the file system is not allowed, since the
access that those ACEs may allow is time-limited based on many other
criteria outside the realm of regular NTFS security capabilities. Having
such an ACE present in a persistent manner would violate the design
requirements for this application.

Looking at the docs for FltCreateFileEx(), the following is of interest:

> Any FileHandle that is obtained from FltCreateFileEx must eventually be released by calling FltClose. In addition, any returned FileObject pointer must be dereferenced when it is no longer needed by calling ObDereferenceObject.
>
> Driver routines that do not run in the system process context must set the OBJ_KERNEL_HANDLE attribute for the ObjectAttributes parameter of FltCreateFileEx. Setting this attribute restricts the use of the handle that is returned by FltCreateFileEx to processes running in kernel mode. Otherwise, the handle can be accessed by the process in whose context the driver is running.

Based on that information, it would appear that a minifilter could open a
file on behalf of the user-mode thread that initiated the I/O operation, and
return the handle to that thread. The point that’s being called out is that
an improperly coded call to FltCreateFileEx() could result in a user
obtaining access to an open file handle with a level of access that’s higher
than was the DACL on the file would have permitted. It is exactly this
mechanism that my minifilter would need to make use of in order to
selectively allow specific levels of access to specific users based on
criteria other than the contents of the DACL.

Any further advice, caveats or dead-on-accurate shots that will “sink my
battleship” are welcome! :wink:

Chuck
–

10

“Chuck Chopp” wrote in message news:xxxxx@ntfsd…

> Looking at the docs for FltCreateFileEx(), the following is of interest:
>
>> Any FileHandle that is obtained from FltCreateFileEx must eventually be
>> released by calling FltClose. In addition, any returned FileObject
>> pointer must be dereferenced when it is no longer needed by calling
>> ObDereferenceObject. Driver routines that do not run in the system
>> process context must set the OBJ_KERNEL_HANDLE attribute for the
>> ObjectAttributes parameter of FltCreateFileEx. Setting this attribute
>> restricts the use of the handle that is returned by FltCreateFileEx to
>> processes running in kernel mode. Otherwise, the handle can be accessed
>> by the process in whose context the driver is running.
>
> Based on that information, it would appear that a minifilter could open a
> file on behalf of the user-mode thread that initiated the I/O operation,
> and return the handle to that thread. The point that’s being called out
> is that an improperly coded call to FltCreateFileEx() could result in a
> user obtaining access to an open file handle with a level of access
> that’s higher than was the DACL on the file would have permitted. It is
> exactly this mechanism that my minifilter would need to make use of in
> order to selectively allow specific levels of access to specific users
> based on criteria other than the contents of the DACL.
>

Chuck,

The problem with the above approach is that you then have to manage
every call for the user, since FltCreateFileEx() will create a new
FILE_OBJECT not the one the user will reference. This will mean all the
problems with mini-filters I mentioned do come and bite you.

One possible approach, is to have the create temporarily set the
security, before allowing the actual create request is allowed to proceed,
then on the post operation remove the security changes. This still
requires some complexity to make sure everything is put back the way it
came, and will have a performance impact since Windows does a lot of
creates, but it keeps things relatively simple.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

11

Chuck,

Don indicated the inherent problems with using FltCreateFileEx and
substituting the file object.

I agree with you that temporarily changing the ACL introduces too many
opportunities for unauthorized access. My approach would be to have a
persistent ACL on the files you are interested in, which grants access to a
special group. When you get a create that you want to allow, substitute an
access token that has that group for the original. Note that the access
token you are interested in is not the process’s token, it is buried in the
IRP_MJ_CREATE parameters.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chuck Chopp
Sent: Wednesday, August 29, 2007 6:53 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Proper terminology & type of filter driver to use…

Dan Kyler wrote:

Chuck,

First I agree that a minifilter is the way to go for your purposes.

However:

[quote]
Also, if I go with the method of altering the DACL on “on the fly”, so
to speak, then I need to make sure that the part of the base NTFS file
system driver that does access checks upon handling an IRP_MJ_CREATE
call will actually result in the IRP_MJ_QUERY_SECURITY calls passing
thru the minifilter stack rather than be handled exclusively in an
internal manner within the NTFS file system driver.

>
> The file system does not query itself for the ACL. It already has it.
> Changing the result of the query security call will not affect the
> access check. If you want to affect the access check, you must
> actually set the ACL to what you want.
>
> - Dan.

It was my understanding that the I/O Manager makes a call to the file system
using IRP_MJ_QUERY_SECURITY in order to get the SD to make the comparisons
for the access-check. If that’s not the case, then I may need to go with
the alternative idea where the driver computes a set of effective rights
based on other criteria besides the DACL and then forces the IRP_MJ_CREATE
call to be successful.

Part of the problem that I’m working around is the non-dynamic nature of
access-tokens. When a user logs on, their access-token is created and is
static thereafter. If they are granted membership in a group, or have their
membership in a group revoked, their access-token does not reflect these
changes. The application that I’m porting comes from a NetWare & eDirectory
environment where such changes are dynamic & take effect immediately [within
directory service replication & synchronization tolerances]. One way to
deal with this is to introduce additional criteria on which effective access
rights may be computed, and then to enforce that at the file system level.
One key requirement is that if this application is disabled, or fails in
anyway, or if the driver is removed, then NTFS security defaults back to
it’s normal behavior and none of the enhanced security features will be
present. That means that simply inserting additional ACEs into the DACL
that is stored persistently in the file system is not allowed, since the
access that those ACEs may allow is time-limited based on many other
criteria outside the realm of regular NTFS security capabilities. Having
such an ACE present in a persistent manner would violate the design
requirements for this application.

Looking at the docs for FltCreateFileEx(), the following is of interest:

> Any FileHandle that is obtained from FltCreateFileEx must eventually be
released by calling FltClose. In addition, any returned FileObject pointer
must be dereferenced when it is no longer needed by calling
ObDereferenceObject.
>
> Driver routines that do not run in the system process context must set the
OBJ_KERNEL_HANDLE attribute for the ObjectAttributes parameter of
FltCreateFileEx. Setting this attribute restricts the use of the handle that
is returned by FltCreateFileEx to processes running in kernel mode.
Otherwise, the handle can be accessed by the process in whose context the
driver is running.

Based on that information, it would appear that a minifilter could open a
file on behalf of the user-mode thread that initiated the I/O operation, and
return the handle to that thread. The point that’s being called out is that
an improperly coded call to FltCreateFileEx() could result in a user
obtaining access to an open file handle with a level of access that’s higher
than was the DACL on the file would have permitted. It is exactly this
mechanism that my minifilter would need to make use of in order to
selectively allow specific levels of access to specific users based on
criteria other than the contents of the DACL.

Any further advice, caveats or dead-on-accurate shots that will “sink my
battleship” are welcome! :wink:

Chuck
–

—
NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

12

> It was my understanding that the I/O Manager makes a call to the file system

using IRP_MJ_QUERY_SECURITY in order to get the SD to make the
comparisons
for the access-check.

It does not. IRP_MJ_QUERY_SECURITY is only for users who want to see or edit
the ACLs, used to populate the dialog.

NTFS uses its own internal form of ACL to run SeAccessCheck, and it is NTFS who
runs SeAccessCheck on files and directories and not the IO manager (it does
this only for devices opened path-lessly).

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

13

Don Burn wrote:

“Chuck Chopp” wrote in message news:xxxxx@ntfsd…
>
>
>>Looking at the docs for FltCreateFileEx(), the following is of interest:
>>
>>
>>>Any FileHandle that is obtained from FltCreateFileEx must eventually be
>>>released by calling FltClose. In addition, any returned FileObject
>>>pointer must be dereferenced when it is no longer needed by calling
>>>ObDereferenceObject. Driver routines that do not run in the system
>>>process context must set the OBJ_KERNEL_HANDLE attribute for the
>>>ObjectAttributes parameter of FltCreateFileEx. Setting this attribute
>>>restricts the use of the handle that is returned by FltCreateFileEx to
>>>processes running in kernel mode. Otherwise, the handle can be accessed
>>>by the process in whose context the driver is running.
>>
>>Based on that information, it would appear that a minifilter could open a
>>file on behalf of the user-mode thread that initiated the I/O operation,
>>and return the handle to that thread. The point that’s being called out
>>is that an improperly coded call to FltCreateFileEx() could result in a
>>user obtaining access to an open file handle with a level of access
>>that’s higher than was the DACL on the file would have permitted. It is
>>exactly this mechanism that my minifilter would need to make use of in
>>order to selectively allow specific levels of access to specific users
>>based on criteria other than the contents of the DACL.
>>
>
>
> Chuck,
>
> The problem with the above approach is that you then have to manage
> every call for the user, since FltCreateFileEx() will create a new
> FILE_OBJECT not the one the user will reference. This will mean all the
> problems with mini-filters I mentioned do come and bite you.
>
> One possible approach, is to have the create temporarily set the
> security, before allowing the actual create request is allowed to proceed,
> then on the post operation remove the security changes. This still
> requires some complexity to make sure everything is put back the way it
> came, and will have a performance impact since Windows does a lot of
> creates, but it keeps things relatively simple.

I can see possibly altering the DACL on-disk, as you recommend, in the pre &
post callbacks. I understand that Windows does a lot of create file
operations, too. One thing I didn’t mention before, the portion of the file
system that needs to have this enhanced security could be defined as
“sparse”, in that it’s not every single folder & file on a NTFS volume, it
could be just a small percentage of the folders & files. One design goal
would be to only have the minifilter step in & take action if it determines
that a create file operation is being performed at a location in the file
system that does need the enhanced security. Hopefully, this would minimize
the performance impact.

If the limitations of minifilters are an impediment, though, to getting this
implemented, then a [legacy] file system filter driver may be necessary.
There’s a very specific discussion on the usage of ZwCreateFile() and
IoCreateFile() where a filter driver is performing a proxy operation on
behalf of a user. Even if FltCreateFileEx() is incapable of opening the
same file object that the user would be accessing, either ZwCreateFile() or
IoCreateFile() will allow me to provide the desired successful override on a
file create operation according security criteria outside of what’s in the
SD. Am I not properly understanding the behavior of these two functions in
that respect?

Chuck
–

14

“Chuck Chopp” wrote in message news:xxxxx@ntfsd…
>
> If the limitations of minifilters are an impediment, though, to getting
> this implemented, then a [legacy] file system filter driver may be
> necessary. There’s a very specific discussion on the usage of
> ZwCreateFile() and IoCreateFile() where a filter driver is performing a
> proxy operation on behalf of a user. Even if FltCreateFileEx() is
> incapable of opening the same file object that the user would be
> accessing, either ZwCreateFile() or IoCreateFile() will allow me to
> provide the desired successful override on a file create operation
> according security criteria outside of what’s in the SD. Am I not
> properly understanding the behavior of these two functions in that
> respect?
>
Chuck,

All of the functions mentioned become IoCreateFile in the end, and all
create another file object. This means you have to do everything yourself,
i.e. support every operation a file system is capable of and handle the
case where you did the IoCreateFile or where you did not and let the OS do
it.

This is not a small project to go that way.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

15

Dan Kyler wrote:

Don indicated the inherent problems with using FltCreateFileEx and
substituting the file object.

I agree with you that temporarily changing the ACL introduces too many
opportunities for unauthorized access. My approach would be to have a
persistent ACL on the files you are interested in, which grants access to a
special group. When you get a create that you want to allow, substitute an
access token that has that group for the original. Note that the access
token you are interested in is not the process’s token, it is buried in the
IRP_MJ_CREATE parameters.

Dan,

Thanks for that tip. That might be a much more feasible way of making this
work. I could readily create an access-token to be used as a proxy provided
that I can substitute it in place of the one that’s in the IRP. Actually,
I’d be having to analyze the access-token in the IRP, anyway, to determine
the SID of the user who initiated the create request so that I can determine
if the user is supposed to have the enhanced security features applied to
their create request.

Of course, if I’m directly accessing the IRP, and possibly modifying it,
then I’m stuck with using a file system filter driver and not a file system
minifilter since the minifilters are limited to having no access to the IRP
itself [based on Don’s earlier explanation of minifilter limitations].

What impact does this modification of the access-token in the IRP have in
terms of the process for which the file handle is created? I would expect
that the access-token in the IRP is only used for computing effective rights
in the access-check, and the current thread, whether it has an impersonation
access-token, or if it’s running under the process’ primary access-token,
will determine who’s handle table the file handle gets placed in after the
file is successfully opened. Is this correct?

16

Filter manager provides all the parameters. You don’t need the actual Irp.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Chuck Chopp
Sent: Wednesday, August 29, 2007 8:29 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Proper terminology & type of filter driver to use…

Dan Kyler wrote:

Don indicated the inherent problems with using FltCreateFileEx and
substituting the file object.

I agree with you that temporarily changing the ACL introduces too many
opportunities for unauthorized access. My approach would be to have a
persistent ACL on the files you are interested in, which grants access
to a special group. When you get a create that you want to allow,
substitute an access token that has that group for the original. Note
that the access token you are interested in is not the process’s
token, it is buried in the IRP_MJ_CREATE parameters.

Dan,

Thanks for that tip. That might be a much more feasible way of making this
work. I could readily create an access-token to be used as a proxy provided
that I can substitute it in place of the one that’s in the IRP. Actually,
I’d be having to analyze the access-token in the IRP, anyway, to determine
the SID of the user who initiated the create request so that I can determine
if the user is supposed to have the enhanced security features applied to
their create request.

Of course, if I’m directly accessing the IRP, and possibly modifying it,
then I’m stuck with using a file system filter driver and not a file system
minifilter since the minifilters are limited to having no access to the IRP
itself [based on Don’s earlier explanation of minifilter limitations].

What impact does this modification of the access-token in the IRP have in
terms of the process for which the file handle is created? I would expect
that the access-token in the IRP is only used for computing effective rights
in the access-check, and the current thread, whether it has an impersonation
access-token, or if it’s running under the process’ primary access-token,
will determine who’s handle table the file handle gets placed in after the
file is successfully opened. Is this correct?

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

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

17

Dan Kyler wrote:

Filter manager provides all the parameters. You don’t need the actual Irp.

OK, as long as I can alter the parameters to change the access-token
associated with the create file request, and still have the file handle be
placed into the requesting process’ handle table, I’ll be a happy camper :slight_smile:

18

Chuck,

If you want NTFS to skip ACL checking you may change “RequestorMode” field in
the IRP to “KernelMode”. NTFS does not enforce security for kernel mode
components unless the component explicilty requsted checking ACL by setting
IO_FORCE_ACCESS_CHECK flag. Thus changing requestor mode and cleaning
IO_FORCE_ACCESS_CHECK will let you to skip ACL check.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Chopp
Sent: Wednesday, August 29, 2007 7:29 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Proper terminology & type of filter driver to use…

Dan Kyler wrote:

Don indicated the inherent problems with using FltCreateFileEx and
substituting the file object.

I agree with you that temporarily changing the ACL introduces too many
opportunities for unauthorized access. My approach would be to have a
persistent ACL on the files you are interested in, which grants access to a
special group. When you get a create that you want to allow, substitute an
access token that has that group for the original. Note that the access
token you are interested in is not the process’s token, it is buried in the
IRP_MJ_CREATE parameters.

Dan,

Thanks for that tip. That might be a much more feasible way of making this
work. I could readily create an access-token to be used as a proxy provided
that I can substitute it in place of the one that’s in the IRP. Actually,
I’d be having to analyze the access-token in the IRP, anyway, to determine
the SID of the user who initiated the create request so that I can determine
if the user is supposed to have the enhanced security features applied to
their create request.

Of course, if I’m directly accessing the IRP, and possibly modifying it,
then I’m stuck with using a file system filter driver and not a file system
minifilter since the minifilters are limited to having no access to the IRP
itself [based on Don’s earlier explanation of minifilter limitations].

What impact does this modification of the access-token in the IRP have in
terms of the process for which the file handle is created? I would expect
that the access-token in the IRP is only used for computing effective rights
in the access-check, and the current thread, whether it has an impersonation
access-token, or if it’s running under the process’ primary access-token,
will determine who’s handle table the file handle gets placed in after the
file is successfully opened. Is this correct?

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

19

Chuck,

Alexei has good idea here. This could work for you, and would be quite
simple. The RequestorMode is part of the FLT_CALLBACK_DATA, so I assume
(would need to experimentally verify) that it can be modified in PreCreate.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Wednesday, August 29, 2007 11:33 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Proper terminology & type of filter driver to use…

Chuck,

If you want NTFS to skip ACL checking you may change “RequestorMode” field
in the IRP to “KernelMode”. NTFS does not enforce security for kernel mode
components unless the component explicilty requsted checking ACL by setting
IO_FORCE_ACCESS_CHECK flag. Thus changing requestor mode and cleaning
IO_FORCE_ACCESS_CHECK will let you to skip ACL check.

Alexei.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Chuck Chopp
Sent: Wednesday, August 29, 2007 7:29 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Proper terminology & type of filter driver to use…

Dan Kyler wrote:

Don indicated the inherent problems with using FltCreateFileEx and
substituting the file object.

I agree with you that temporarily changing the ACL introduces too many
opportunities for unauthorized access. My approach would be to have a
persistent ACL on the files you are interested in, which grants access
to a special group. When you get a create that you want to allow,
substitute an access token that has that group for the original. Note
that the access token you are interested in is not the process’s
token, it is buried in the IRP_MJ_CREATE parameters.

Dan,

Thanks for that tip. That might be a much more feasible way of making this
work. I could readily create an access-token to be used as a proxy provided
that I can substitute it in place of the one that’s in the IRP. Actually,
I’d be having to analyze the access-token in the IRP, anyway, to determine
the SID of the user who initiated the create request so that I can determine
if the user is supposed to have the enhanced security features applied to
their create request.

Of course, if I’m directly accessing the IRP, and possibly modifying it,
then I’m stuck with using a file system filter driver and not a file system
minifilter since the minifilters are limited to having no access to the IRP
itself [based on Don’s earlier explanation of minifilter limitations].

What impact does this modification of the access-token in the IRP have in
terms of the process for which the file handle is created? I would expect
that the access-token in the IRP is only used for computing effective rights
in the access-check, and the current thread, whether it has an impersonation
access-token, or if it’s running under the process’ primary access-token,
will determine who’s handle table the file handle gets placed in after the
file is successfully opened. Is this correct?

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

20

I'll take that and run with it {grin} and see what I can do with it. I just
finished getting my build environment & debug environment setup, now it's
time to build a sample minifilter, do some experimental debugging, and then
start fiddling with the requestor mode in a few selected cases to see if it
proves out the theory.

Thanks again for the assistance.

Chuck

Dan Kyler wrote:

Chuck,

Alexei has good idea here. This could work for you, and would be quite
simple. The RequestorMode is part of the FLT_CALLBACK_DATA, so I assume
(would need to experimentally verify) that it can be modified in PreCreate.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alexei Jelvis
Sent: Wednesday, August 29, 2007 11:33 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Proper terminology & type of filter driver to use...

Chuck,

If you want NTFS to skip ACL checking you may change "RequestorMode" field
in the IRP to "KernelMode". NTFS does not enforce security for kernel mode
components unless the component explicilty requsted checking ACL by setting
IO_FORCE_ACCESS_CHECK flag. Thus changing requestor mode and cleaning
IO_FORCE_ACCESS_CHECK will let you to skip ACL check.

Alexei.