How Do We Avoid Auditing Failed SYNCHRONIZE File Access?

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.

"Will" wrote in message

> 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
>
>
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

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


"Roger Abell [MVP]" wrote in message

> 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.
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

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

"Will" wrote in message

> 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
>
>
> "Roger Abell [MVP]" wrote in message
>
>> 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.
>
>
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

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


"Roger Abell [MVP]" wrote in message

> 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).
>
> "Will" wrote in message
>
> > 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
> >
> >
> > "Roger Abell [MVP]" wrote in message
> >
> >> 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.
> >
> >
>
>
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

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
Microsoft MVP (Windows Server : Security)

"Will" wrote in message

> 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
>
>
> "Roger Abell [MVP]" wrote in message
>
>> 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).
>>
>> "Will" wrote in message
>>
>> > 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
>> >
>> >
>> > "Roger Abell [MVP]" wrote in message
>> >
>> >> 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.
>> >
>> >
>>
>>
>
>
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

"Roger Abell [MVP]" wrote in message

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

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
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

Will:

I *strongly* recommend that you do not alter the permissions on the files &
folders in System32.

Our default ACLs have been thoroughly tested for app compat AND for
security. I understand that you don't like the fact that we set explicit
protected ACLs on many of these files rather than use inheritance, but
changing the model is either likely to leave you broken (changed default
file system ACLs is one of our top 20 support call generators for Windows
Server) or less secure.

Also understand that ISVs test their software on systems with default ACLs.

In any case changing the defaults is unsupported by Microsoft- if you change
the ACLs, and run into a support problem and call Microsoft Support, they'll
troubleshoot until they determine that the issue might be related to the
changed ACLs, at which time you'll have to put the original ACLs back before
they'll continue to support you. If the problem goes away at that point
then the case is resolved.

Having spent 5 years on the phones taking security calls about Windows, I
can tell you that the problems related to changing ACLs are subtle and
nasty. Apps break in weird ways and you usually don't get a nice clean
error message telling you "operation failed because of insufficient
permission on object X"- it's usually an error message that either has no
seeming relationship with access control, or a silent failure, or, in the
best case, "access denied", which still doesn't tell you what was being
accessed and who accessed it.

Best regards,
Eric



"Roger Abell [MVP]" wrote in message

>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
> Microsoft MVP (Windows Server : Security)
>
> "Will" wrote in message
>
>> 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
>>
>>
>> "Roger Abell [MVP]" wrote in message
>>
>>> 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).
>>>
>>> "Will" wrote in message
>>>
>>> > 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
>>> >
>>> >
>>> > "Roger Abell [MVP]" wrote in message
>>> >
>>> >> 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.
>>> >
>>> >
>>>
>>>
>>
>>
>
>
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access? 

"Eric Fitzgerald [MSFT]" wrote in message

> Having spent 5 years on the phones taking security calls about Windows, I
> can tell you that the problems related to changing ACLs are subtle and
> nasty.

Believe me I know it. But one gets the feeling at times that Microsoft
didn't design those ACLs for files in the System Root with any kind of
security in mind, but simply with a lowest common denominator that allowed
all of the different teams' code to work at all. It's frustrating to me to
give Everyone read or write access to any object in the OS when I know the
computer won't be accessed remotely except by a domain controller and RDP
logins, and the number of users who need to login is a small number of well
defined users. Rather than creating a clean security model that utilizes
local groups in the ACL to create a lowest possible exposure, Everyone or
Authenticated Users becomes a very crude catch all to get anyone or anything
that might need access to the file system or Registry to get access.

I do have a respect for how complex a thing like Windows is. I do realize
it is a small miracle to get an OS released at all that just works. I'm
just disappointed that there doesn't seem to be any support there for the
motivated admin who wants to spend the extra time to harden things on select
machines. If you change defaults on files in the System Root, as you say,
you are on your own. That's support for hardening in cheap kind of way.
It's not reasonable to believe that any individual (or any company) is
really going to figure out all the possible uses and security needs of every
system service, application, etc that has needs to access system32 or the
registry. If Microsoft can't support it, you are in a pretty lonely place.

If you have RestrictAnonymous=2, then you at least don't have exposure from
Everyone in the ACLs from to hackers using null connections, but
occasionally someone might do something catastrophic to group policy, which
removes the RestrictAnonymous setting for a few days. And you certainly do
have risk from every person inside your network who can authenticate any
userid to a domain controller and then use that to start poking around the
box looking for exploits.

And then there is the nightmare case of trying to recover a box that is
already hacked. In such cases the hacker usually has modified the files in
system32, often in ways where you don't see any ACL on the file object at
all. Unless you do a blanket overwrite of permissions for all files in
the system root subtree, you are likely never going to eradicate such a
situation. I know you are thinking "reinstall and just start over from
scratch" but somehow that doesn't leave me feeling more secure, it just
postpones the next similar event. What I struggle with is that until I
really understand the file ACLs in system root I'm really just blind to what
my real exposures are. I can't control what I don't understand.

I can share with you that we have had great success securing System Root on
*standalone* Windows 2000 servers, where users never need to login, with the
following ACL:

Anonymous Logon: Deny
Guests: Deny
<ReservedLocalGroupName>: Deny

Administrators: Full Control
SYSTEM: Full Control

That's pretty simple, and for Windows 2000 which runs every service as
SYSTEM seems to not create too many conflicts if you apply it to the entire
System Root. As long as you only run one key application on each server,
you can usually use auditing to see if there is some other permission you
need there.

Something similar for machines where users have a limited number of
applications to run has also worked very well, giving users Read access to
the System subtree and denying them access to the folders that have the SAM
or copies of the SAM.

Windows 2003 is still a mystery to me. You have these new user contexts
for Local Service and Network Service, and God only knows what resources
those need access to. You can certainly give them modify access to
everything, but then you are probably undoing a large part of the reason
they were created in the first place (to reduce the security exposure of
some critical services like RPC, which run as Network Service). If you go
the other extreme and give those services readonly access to the System Root
subtree, then probably they don't have modify access to some resources there
and you will get the strange failures that you are alluding to.

In 95% of all cases, I do use the default permissions (albeit reluctantly),
and just hide the server behind a firewall to minimize the footprint it
exposes. I don't let RPC through a firewall unless it is an application
where I have no choice about that (e.g., a domain controller). The 5% of
the cases where I want to secure things further are cases where its Windows
2000 running a dedicated application with no direct user logins, or a
machine that has been compromised.

Okay, so yes I'm a masochist.


> Apps break in weird ways and you usually don't get a nice clean
> error message telling you "operation failed because of insufficient
> permission on object X"- it's usually an error message that either has no
> seeming relationship with access control, or a silent failure, or, in the
> best case, "access denied", which still doesn't tell you what was being
> accessed and who accessed it.

What if you audit all of the files in the System Root? You won't even see
the attempt to read or write a file by a service?

--
Will
 >> Stay informed about: How Do We Avoid Auditing Failed SYNCHRONIZE File Access?