Customizable security in NTFS? Needs to be extensible & dynamic

Discussion in 'Windows Vista Drivers' started by Chuck Chopp, Jul 17, 2007.

  1. Chuck Chopp

    Chuck Chopp Guest

    I'm very familiar with the Win32 Security API functions for managing NTFS
    permissions. However, I've come up with a need to have a more dynamic way
    of updating the effective access rights to a folder or file on-the-fly.
    Since a user's access-token is generated at logon time, adding the user to
    new security groups doesn't alter the effective security until the logout
    and logon again. I also don't want to alter the existing DACL because there
    may already be other ACEs with the user's SID in them that provide some
    level of access, but the set of rules to be applied for determining allowed
    & denied access levels may change frequently and modifying ACEs that may be
    in heritable could impose an overhead on the system that's not acceptable in
    terms of resources spent propagating inheritable ACEs.

    I'm looking into file system filter drivers in an attempt to determine if
    there's a way that a filter driver layered on top of NTFS would allow me to
    implement this more sophisticated type of security. It would appear that in
    Win2K3 R2, the file filtering and directory quota features are implemented
    as filter drivers rather than being integrated directly into NTFS itself, so
    I'm thinking that I'm on the right track here. However, it wouldn't hurt to
    get some confirmation from somebody with experience at writing or supporting
    the development of file system filter drivers.

    Am I heading in the right direction? Or, do I need to look at "hooking" the
    API functions that determine effective rights?


    TIA,

    Chuck
    --
    Chuck Chopp

    ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

    RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
    103 Autumn Hill Road 864 801 2774 fax
    Greer, SC 29651

    Do not send me unsolicited commercial email.
     
    Chuck Chopp, Jul 17, 2007
    #1
    1. Advertisements

  2. Your approach seems convoluted. What your ultimate problem? Not the problem
    how to change file permissions on the fly, but the problem behind it?
     
    Alexander Grigoriev, Jul 18, 2007
    #2
    1. Advertisements

  3. Chuck Chopp

    Chuck Chopp Guest

    OK, the problem definition was buried in the description...

    In a nutshell, access-tokens are static... once one is created, any changes
    to a user's group membership in AD don't take effect until the user logs out
    & logs on again. Thus, making a user a member of a group and adding ACEs
    for that group to the DACL of a folder does not result in immediate access
    to the folder for the user.

    I'm porting an application from a Novell eDir / NetWare environment over to
    an AD / Windows environment. With eDir & NetWare, a different
    implementation is used when computing effective access rights. Making a
    user a member of a group results in the user becoming "security equivalent"
    to the group. eDir implements security equivalence in a very broad way,
    veyr generic, such that *every* object in the eDir tree can be a security
    principal, and "trustee assignments" [the equivalent of adding ACEs to a
    DACL on NTFS] can be assigned dynamically in the file system on an NSS or
    TFS volume. When effective access rights are calculated, full traversal
    from the root of the volume, as well as summation of all security
    equivalences, are both performed. This allows for changes in security
    equivalence to have an immediate impact on effective access rights w/o
    requiring the user to logout & logon again.

    I know, this is the exact opposite of how the NT platform does things with
    AD and NTFS... I'm intimately familiar familiar with how the Win32 Security
    API functions work, and I've been doing software development using them
    since the mid 1990's. I'm well aware of how ACL inheritance *really* works
    as of Win2K, and any change to an inheritable ACE requires a cascading
    operation where the ACE is applied to the DACL of every descendent that
    doesn't have a protected DACL. So, in the case of NTFS, effective rights
    are determined by reading only the DACL of the folder/file being accessed,
    and comparing that against all the security-enabled SIDs in the user's
    access-token. This may or may not result in a performance improvement
    compared to how NetWare performs the same task, since the traversal &
    summation task need not be performed at the time that effective access
    rights need to be calculated, but it can incur a *huge* performance penalty
    if inheritable rights are being modified on a NTFS folder hiercharchy that
    is, well, let's say "massive" in terms of it's depth, breadth and # of files.

    The non-dynamic nature of access tokens makes it very difficult for me to
    port this application. The implicitly dynamic nature of effective rights
    determination on NetWare & NSS / TFS volumes is critical to the proper
    functioning of this application.

    This need has lead me to investigate methods by which I can augment the
    existing NTFS security features with something more dynamic. Let's just
    accept that there are a potentially complex set of rules that exist, based
    on some sort of security policy, that exist somewhere as an object in AD. I
    need to have those rules effectively implemented such that any given user's
    access to a particular folder or file is enabled or disabled based on the
    intersection of those rules with the existing ACEs in the DACL on the folder
    or file in question. I'm not going to go into any more detail about what
    those rules are, or how they are determined or derived, but suffice it to
    say that they exist and I need to find a way to enforce them.

    The mechanisms that come to mind are file system filter drivers and API
    function hooks in the file system. Most certainly, Anti-Virus products make
    use of API function hooking and can certainly deny access to a folder or
    file, but I'm not certain that they can effectively provide additional
    "access allowed" functionality that combines with and/or overrides the DACL
    on a folder or file.

    Is that a clear enough description of the problem that I'm trying to solve?

    Any hints or insights into the proper mechanisms to use would be appreciated.


    TIA,

    Chuck
    --
    Chuck Chopp

    ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

    RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
    103 Autumn Hill Road 864 801 2774 fax
    Greer, SC 29651

    Do not send me unsolicited commercial email.
     
    Chuck Chopp, Jul 18, 2007
    #3
  4. Have a service open files for the user app. A service can combine user's
    token with whatever rules you want, open or not open the file, and duplicate
    a handle back to the app.

     
    Alexander Grigoriev, Jul 18, 2007
    #4
  5. Chuck Chopp

    Chuck Chopp Guest

    It's not quite that simple. This has to work within the realm of normal
    Windows Networking in terms of accessing folders & files via share from a
    client workstation. There's no dedicated client application. It could be
    any program running on the enduser's workstation... an MS Office app,
    Notepad, Adobe, etc... anything at all, really. However, regardless of the
    application, at the time that file access is attempted, I need to be able to
    permit or deny the action based on the presence of policy-based rules and
    their intersection with the existing DACL that's on the specified folder or
    file.

    In effect, beyond the existing explicitly assigned & inherited ACEs that are
    persistently stored in the DACL, what is needed is a set of dynamic ACEs
    that are generated on-the-fly such that they appear 1st in the sorted list
    of ACEs, prior to both the explicitly assigned ACEs and the inherited ACEs.
    This would allow the existing access-check mechanisms to function normally
    w/o alteration.


    --
    Chuck Chopp

    ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

    RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
    103 Autumn Hill Road 864 801 2774 fax
    Greer, SC 29651

    Do not send me unsolicited commercial email.
     
    Chuck Chopp, Jul 18, 2007
    #5
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.