How Do We Avoid Auditing Failed SYNCHRONIZE File Access?

Discussion in 'Windows Vista Security' started by Will, Jul 4, 2006.

  1. Will

    Will Guest

    After turning on auditing of files in Windows 2003 and Windows XP, I have
    quickly learned that nearly all program execution in Windows involve certain
    kinds of file access that are not granted to a user with read/executive
    priviletges. These accesses generate audit events. The most offensive
    privileges required are:

    read attribute
    read extended attribute
    write attribute
    write extended attribute
    synchronize

    Luckily, I can turn off security auditing on read and write of attributes.
    Is there a way to turn off security audting of a failure to get the
    synchronize privilege? My security logs are occasionally full of these
    security failure events, and it is driving me crazy having to wade through
    noise.

    If this is something they addressed in Vista / Longhorn I would like to know
    about that as well.
     
    Will, Jul 4, 2006
    #1
    1. Advertisements

  2. Will,

    I am wondering whether you have some storage that originally existed in
    Windows 2000 or earlier ? or was ACLed as part of an install using an
    installer written back in that era ??

    Starting with XP Synchronize was no longer shown as a separate bit one
    could specify (or not) in an ACE definition using the NTFS security dialog.
    Instead, it was just always granted behind the scenes. So, in essence, the
    failures you are seeing for Sync are actually errors in how the storage is
    ACLed.


    The result of this however is, as you have found, that the bit is now also
    not separately available for specifciation in you audit SACL definitions.

    Perhaps you could approach this issue by correcting the areas where there
    are failures triggered for the grant of Synchronize. XCacls.vbs lets one
    get at that (the E in a detailed permissions spec).
    http://support.microsoft.com/default.aspx?scid=KB;EN-US;825751
    XCacls.vbs does not let one get at the SACL, just the DACL however.
    However, if you are into scripting, then it is only a small modification
    to follow the example of xcacls.vbs but altering the SACL instead.
    Alternative, SetAcl can alter SACLs and can be used in fine detail.
    http://setacl.sourceforge.net/
    A further alternative would be to use a security template to set the
    SACL after editing the SDDL to remove the DACL part.
     
    Roger Abell [MVP], Jul 4, 2006
    #2
    1. Advertisements

  3. Will

    Will Guest

    I think you are onto something here. At least some of the systems I am
    seeing the Synchronize audit messages on were new installs on a file system
    that was once used for Windows 2000 and has legacy folders still installed.

    I will start reading about SACLs, but do you have any syntax document for
    SetACL? I downloaded it and the command line help is beyond awful. The
    syntax is among the obscurest and least obvious of any utility I have ever
    used. That one needs to go to the UNIX hall of fame. I looked on the
    SourceForge page for documentation and found only an article written by the
    author, useful for concepts only not syntax of SetACL.

    Does any third party make a high quality GUI based security permissions
    editor that shows all of the DACL / SACL attributes that can be set,
    including Synchronize? I'm willing to pay for something, particularly if
    it has the ability to build templates that can be applied via command line
    tools, so I can partly automate correcting this on multiple machines.

    If your theory is right, then we should remove Synchronize from the DACL?
    It won't matter if Synchronize is in the SACL? I'm a bit confused really,
    because if we include Synchronize in the DACL, then shouldn't it be ignored
    since it is automatically granted anyway? And if we include Synchronize in
    the SACL, it shouldn't really matter since the privilege is always granted
    as well?

    --
    Will


     
    Will, Jul 5, 2006
    #3
  4. Fully agreed, and I can offer no help beyond what you have likely already
    turned up at SourceForge and via Google.
    You really should look into scripting, or use of the new system management
    security namespace introduced with .Net Framework version 2. Xcacls.vbs
    grabs the DACL object, but the SACL object is available and handled 100%
    similarly to what xcacls.vbs does with the DACL.
    I guess your issue (for reACLing or adjusting the existing DACLs) depends
    on how extensive that legacy storage - where by extensive I do not so much
    mean size of the store but variability in its ACLing, amount of points
    establishing
    new inheritances, etc.. Again, xcacls.vbs could be used to just make sure
    that
    Synch is allowed without mod of what is there now, including the inheritance
    structure.
    No. Synchronize should be granted with the other DACL grants. Its not
    being so done too often was likely one of the reasons behind the GUI
    change with Whistler era Windows.
    I am not sure I see what you are getting at.
    Event reporting of permissions failures merely states how things are
    compared to what is being requested. It does not venture into what
    ought to be.
    Were everything ACL'd with XP or later, then audit that includes Synch
    should not be throwing access failures as Synch would have been granted.
    When something attempts access to a secured resourse it states the
    accesses that it is requesting. These are either all filled, or there is a
    shortfall, and if there is a shortfall and the object is being audited for
    failures by the principal making the request, then an audit record is cut.
    If Synch was correctly granted then it would not trigger these. But,
    keep in mind that the ACL bits can be used other than on NTFS objects,
    so saying "why bother with Synch" anymore overlooks other uses.
     
    Roger Abell [MVP], Jul 5, 2006
    #4
  5. Will

    Will Guest

    I'm setting the DACL on the root and inheriting the DACL to c:\windows and
    c:\windows\system32. To my surprise, every program inside of
    c:\windows\system32 has been stripped of its DACL inheritance and given its
    own ACL, and the inheritance rule I am setting for system32 is not being
    picked up by the files in system32 that do not inherit. This may be
    contributing to the symptoms I'm seeing (still trying to figure it out).

    Is there any particular reason for Windows giving every file in SYSTEM32 its
    own DACL that is not inherited? I certainly don't want to overwrite
    thousands of files' and dozens of folders' DACLs when some of those probably
    really do need different settings. Nor do I want to have to pick apart
    1000 file DACLs and think about whether they could inherit or not.
     
    Will, Jul 5, 2006
    #5
  6. If you check "setup security.inf" you will see it has an extensive
    filesystem
    section, resulting in what you are describing. We have asked MS before
    why they are not leveraging inheritance and instead setting explicit perms
    on each file. I never really have heard a statement that to my way of
    thinking explains it, let alone argues in favor of it. In Wistler beta
    times
    some of us tried to get this changed in order to enable more direct and
    simple NTFS perms oversight and management, but no go.
     
    Roger Abell [MVP], Jul 5, 2006
    #6
  7. Will

    Will Guest

    Well, this is chaos. Complete and utter chaos.

    Sprinkle in two weeks of hard work to investigate the NTFS permissions under
    system32. Add three pinches of pure guesswork to decide if any arbitrary
    file must inherit or not. Add six or so problem tickets with Microsoft to
    debug the problems we are going to create by doing any of this work.

    That's my recipe for what it will take to get this under control on just one
    computer.

    How can I force just the files in the system32 folder to start inheriting,
    without touching the folders in system32 and without touching files and
    subfolders under those?
     
    Will, Jul 5, 2006
    #7
  8. Too funny, or perhaps too pessimistic (?)

    I believe you can accomplish what you outline by use of the
    Security Configuration and Analysis mmc snapin and a custom
    template. To make the template, create a new template and
    in the filesystem section add the root directory that you want
    to be the inheritance root and define what should be the perms
    inherited, and (this is first key part) on the way ok'ing out check
    the radio button to
    configure and then . . . replace existing
    Now, for each subfolder that should not be affected, nor have
    its contained files/subfolders affected, at that subfolder and
    just pass over the permissions (does not matter) and then
    (second key part) select the radio for Do not allow perms to
    be replaced.
    So, you need to add the one spec that will apply to the new
    inheritance point and the files within, and then you need to
    add one "do not allow" for each subfolder. The result is that
    when used this sets that folder and its files and does not touch
    any subfolders or their files.
    In case you have not used the Security Templates snapin,
    right click on your new template and Save. Then, with the
    Sec Config and Analysis tool open database, providing any
    name for a new working database if needed, then right click
    and import template, nav'ing to the newly saved and be sure
    to check to clear the database. Then right click and analyze,
    perhaps look around to make sure it looks like it will do what
    and only what you think is in the template, then right click and
    configure (which uses what is in the database, hence the import
    of first clearing during import and then analyzing to load template
    result to database).
     
    Roger Abell [MVP], Jul 6, 2006
    #8
  9. Will

    Will Guest

    It's not the syntax of how to use a template that is hard work. It's the
    understanding of what protections to use on each file that is the nightmare.

    Is there any command line or GUI tool that would automate the creation of a
    template? I am thinking we will dedicate one computer of each type as a
    reference computer, and then take snapshots of just permissions on its file
    system to use on other machines.

    Alternately, do you know of a backup package that has clear and separate
    options for backing up DACL and SACL for each file system object, and - this
    is key - has a restore option that allows you to restore either or both DACL
    / SACL and *not* restore the file data itself.
     
    Will, Jul 6, 2006
    #9
  10. I must have misunderstood your requirement
    <quote>
    How can I force just the files in the system32 folder to start inheriting,
    without touching the folders in system32 and without touching files and
    subfolders under those?
    </quote>
    To me this said, "I want to set inheritable permissions at system32, but
    I do not what this to alter any subfolder in system32 or files/subfolders
    of those unaltered subfolders of system32".
    From this I understood that you also wanted files in system32 to
    inherit from system32, but evidently you also want to leave the
    existing explicity permissions on those files but only add inheritance
    from system32.
    If the filesystem is XP or newer then I believe that you only need to
    have a script pass over the files only in system32 setting the
    Inheritance Requested flag in the DACL (and/or SACL) of each.
    I would have to examine more closely, by test cases, however whether
    indeed that SD flag is in and of itself sufficient to cause the change.

    I am not aware of either a good tool for autogeneration of a template,
    nor one that can accomplish what you specify in a restore. Template
    generation itself is not too hard except for the determination of what
    truely is and is not inherited if the code must handle all cases for the
    origin history of the storage being examined. Template generation is
    only a matter of reading the SD (security descriptor) and converting
    the ACLs to SDDL syntax and then spitting out a template text line;
    the tough part is determining what lines do not need to be emitted.
     
    Roger Abell [MVP], Jul 6, 2006
    #10
  11. Will

    Will Guest

    I hate to be dense, but clearly I am not getting something.

    I went to both a Windows NT and Windows 2000 system. Nothing in either the
    DACL or SACL of either system says "SYNCHRONIZE"

    If my file system is a legacy Windows 2000 or earlier file system, by
    default would it have granted Synchronize access or not? And how does
    that change in Windows XP and later?
     
    Will, Jul 14, 2006
    #11
    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.