How Do We Avoid Auditing Failed SYNCHRONIZE File Access?

  • Thread starter Thread starter Will
  • Start date Start date
W

Will

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,

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.
 
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


Roger Abell said:
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.
Click to expand...
 
Will said:
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.
Click to expand...

Fully agreed, and I can offer no help beyond what you have likely already
turned up at SourceForge and via Google.
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.
Click to expand...

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.
If your theory is right, then we should remove Synchronize from the DACL?
It won't matter if Synchronize is in the SACL?
Click to expand...
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'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?
Click to expand...
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.
 
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.
 
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.
 
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?
 
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).
 
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.
 
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 said:
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.
Click to expand...

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?
 
Back
Top