I’ve been researching this for a while, and I think that I’m on the right
track. I’m trying to determine if I’ve reached a proper conclusion
regarding the use of a filter driver. Any thoughts on the subject would be
helpful.
I have a project I’m working on where I need to be able to make some dynamic
changes to the DACL [Discretionary ACL] on folders & files on a NTFS volume
based on a set of rules in a “policy”. These changes to the DACL involve
adding some access-allowed ACEs that may supercede some of the existing ACEs
in the DACL, both explicitly applied & inherited. Additionally, these ACEs
need to be able to be kept track of separately from the ones that are placed
in the DACL via the normal GUI admin tools and the Win32 API functions that
are used for managing security. It is vital that these additional ACEs
always be returned when reading the SD [Security Descriptor] and that they
cannot be removed from the DACL via normal means. These enhancements to the
NTFS security need to work for both local access to the volume as well as
network based access that occurs via a file share.
I investigated various types of API function hooking techniques and came to
the conclusion that such methods would not meet the requirements stated above.
Am I on the right track in terms of using a file system filter driver to
intervene in all requests for NTFS security operations involving reading &
writing the DACL?
You are trying to answer the question “how”, but possibly your task needs some different approach.
The weak places of the chosen scheme are that access and alteration of the information and metadata will be possible if your driver is not loaded (for example, other OS is booted or safe-mode is active or the disk is plugged to other computer).
(blatant marketing content removed)
Your toolkit you’re trying to sell has *exactly* the same problem.
-a
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@eldos.org
Sent: Wednesday, August 01, 2007 2:17 PM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] File system filter drivers & NTFS security - Am I on the right track
You are trying to answer the question “how”, but possibly your task needs some different approach.
The weak places of the chosen scheme are that access and alteration of the information and metadata will be possible if your driver is not loaded (for example, other OS is booted or safe-mode is active or the disk is plugged to other computer). I think we can offer some alternative approaches if you describe your needs. Feel free to contact me directly (xxxxx@eldos.com).
With best regards,
Eugene Mayevski
http://www.eldos.com - Security and low-level system components for your applications
NTDEV 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@rocketdivision.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
I’ve got no idea what you’re talking about.
xxxxx@eldos.org wrote:
You are trying to answer the question “how”, but possibly your task needs some different approach.
The weak places of the chosen scheme are that access and alteration of the information and metadata will be possible if your driver is not loaded (for example, other OS is booted or safe-mode is active or the disk is plugged to other computer). I think we can offer some alternative approaches if you describe your needs. Feel free to contact me directly (xxxxx@eldos.com).
Yes, I’m trying to get a definitive answer as to how I can accomplish this
task. I’ve been identifying different methods of accomplishing this task,
and, so far, I’ve ruled out all of the API function hooking mechanisms,
which leaves me with a file system filter driver as one of the few remaining
methods that would be usable.
In terms of the “weak” places you identified, none of them is a valid
concern in this case. The default underlying NTFS security stored in the SD
of each folder & file will remain “as is”. If my filter driver isn’t
loaded, then those security settings, applied using “best practices”, will
have to suffice. Besides, if somebody can compromise the physical security
and remove the disk drive from the server to which it attached, and then
attach it to another computer to interrogate the drive’s contents, then
there’s bigger problems involved than being concerned about whether or not
my driver is loaded. I’m not doing encryption of file contents in my
project; this is not a replacement or add-on to the EFS functionality that
can be enabled for NTFS.
I took a look at your product offerings. None of them suit my needs. I
don’t need to create a new file system of my own. I simply need to extend
the functionality of the existing NTFS on WinXP & newer systems.
As for describing my needs, I did that in my original posting. I don’t need
to explain why I have these needs. I specified what the task was that
needed to be accomplished. What I was looking for was an answer that would
help me to determine if a filter driver was an appropriate way to go in
terms of finding a mechanism & method that would allow me to perform this task.
Further research into the subject has shown that a filter driver is exactly
what I need to be working with, and I’ve ordered the IFS kit from Microsoft.
Why have you ordered the IFS Kit from Microsoft? It is obsolete. It is
included in the WDK for the large sum of $0.00.
–
David J. Craig
Engineer, Sr. Staff Software Systems
Broadcom Corporation
“Chuck Chopp” wrote in message news:xxxxx@ntfsd…
> xxxxx@eldos.org wrote:
>> You are trying to answer the question “how”, but possibly your task needs
>> some different approach. The weak places of the chosen scheme are that
>> access and alteration of the information and metadata will be possible if
>> your driver is not loaded (for example, other OS is booted or safe-mode
>> is active or the disk is plugged to other computer). I think we can offer
>> some alternative approaches if you describe your needs. Feel free to
>> contact me directly (xxxxx@eldos.com).
>
> Yes, I’m trying to get a definitive answer as to how I can accomplish this
> task. I’ve been identifying different methods of accomplishing this task,
> and, so far, I’ve ruled out all of the API function hooking mechanisms,
> which leaves me with a file system filter driver as one of the few
> remaining methods that would be usable.
>
> In terms of the “weak” places you identified, none of them is a valid
> concern in this case. The default underlying NTFS security stored in the
> SD of each folder & file will remain “as is”. If my filter driver isn’t
> loaded, then those security settings, applied using “best practices”, will
> have to suffice. Besides, if somebody can compromise the physical
> security and remove the disk drive from the server to which it attached,
> and then attach it to another computer to interrogate the drive’s
> contents, then there’s bigger problems involved than being concerned about
> whether or not my driver is loaded. I’m not doing encryption of file
> contents in my project; this is not a replacement or add-on to the EFS
> functionality that can be enabled for NTFS.
>
> I took a look at your product offerings. None of them suit my needs. I
> don’t need to create a new file system of my own. I simply need to extend
> the functionality of the existing NTFS on WinXP & newer systems.
>
> As for describing my needs, I did that in my original posting. I don’t
> need to explain why I have these needs. I specified what the task was
> that needed to be accomplished. What I was looking for was an answer that
> would help me to determine if a filter driver was an appropriate way to go
> in terms of finding a mechanism & method that would allow me to perform
> this task.
>
> Further research into the subject has shown that a filter driver is
> exactly what I need to be working with, and I’ve ordered the IFS kit from
> Microsoft.
>
David J. Craig wrote:
Why have you ordered the IFS Kit from Microsoft? It is obsolete. It is
included in the WDK for the large sum of $0.00.
Don’t you just love the Internet? A wealth of information… and it’s
almost impossible at sometimes to figure what’s current and what’s obsolete.
Even the OSR Online web pages that are dedicated to FSD & FSFD resources &
development still mention the IFS as being totally separate from the DDK &
MSDN deliverables, mostly due to a difference in licensing terms. I don’t
recall seeing anything in my most recent MSDN shipments indicating that the
IFS was integrated into it, buf if you’ve got a valid URL that documents
when this occurred, I’ll dig up the appropriate MSDN DVD(s) and look for it.
Even Microsoft’s own web site didn’t say anything about IFS being
obsolete, or that it was included with the existing platform & device
development kits.
Oh well… what would life be like if there weren’t any new surprises, huh?