|
Posted by Roger Abell [MVP] on January 6, 2007, 2:31 am
Please log in for more thread options >> Against base of Users being local user accounts (complete save admins)
>> one may add external principals as is needed for the machine's purpose.
>> The machine itself and domain membership itself, neither impose a
>> required external/foreign membership in the machine's Users group.
>> Ability to access with enterprise purposes can impose memberships
>> in Users, as this does DA in Admins. But, to nail it once more, none
>> are necessary so build from a normalized Users base per spec of box
>> is really all that posting was indicating.
>>
>> You can probably guess that AU usage and drift from first generation
>> NT architect intent is something of a pet to me.
>
> Not sure if it is right or not, but here is what we have been using on non
> domain controllers:
>
I am not so sure there is a right or wrong, but as you indicate, there
are ways to cause problems just as there are ways to allow undesired
accesses by not making alterations.
> 1) At the root of each volume:
>
> Full Control to Administrators and SYSTEM
> Read and Execute Only (NO Create/Modify/Write access at all) to Users.
> We
> do NOT remove Read Permission for Users.
> DENY ALL to Guests, Anonymous Users, and a local group we create
> specifically for the purpose of controlling denials locally
>
I am NOT a fan of using Deny in DACLs, not at all.
The semantics of Deny ACEs works out to be problematic
(explicit grant overriding inherited deny).
What you have done is reasonable, but undefined as I do not
know what is the complete membership of your Users group.
If Users is controlled, then the deny ACEs you use can be
made unnecessary. That is a big part of my prior message.
If Authenticated Users is removed from Users, you do not
need to deny it, and it also causes change to local and network
login user right grant.
If Interactive is removed from Users then Guests are not longer
members of Users when used for local login (unless you add
them explicitly to Users), and they are not Users when doing
a network login.
If Users has these removed, no accounts other than local accounts
are Users except those that you add (hence you do not need the
deny ACEs for specify domain groups).
I used to use some local groups defined specifically to ACL
storage (and I still do some for user rights) with deny to those
local groups on more sensitive storage. This allows such as
adding a domain user account or group to deny in reaction to
breaking "situations", provided connections are flushed to force
a relogin (if possible).
However, that was before the 4 part inherit/explicit semantics,
when it was simply all denies before all grants. I have since
abandoned use of this for storage.
> We remove everything else, which means remove Authenticated Users, remove
> Everyone and remove CREATOR OWNER.
>
Sensible.
I like to define what the intended Users of a machine are, and so
similarly have not use for grants to AU and Everyone.
Creator Owner is useful, situationally; I like its default usage in XP
for example.
> 2) We allow inheritance to all second level folders including Documents &
> Settings and Program Files and Windows. Allow inheritance to System32.
I am not sure what "allow inheritance" in intended to mean.
> We remove any objects that are not in the inheritance lists from the root.
>
I now really feel like a dunce. What did that mean? That you remove any
ACEs that are not inherited ?? Not everywhere surely?
> We never force these settings on subobjects, for fear of accidentally
OK - that clears up the "I am not sure what " above.
So you do not cause a reset of permissions, and so leave inheritance
blocking in effect where it was set in the default, and you only altered
what is inherited from the partition root.
> removing explicit access to LocalService, NetworkService, or ASPNET that
> might exist on specific elements in the subtree.
>
> 3) We remove inheritance from c:\windows\repair and
> c:\windows\system32\config since we don't want ordinary users to get
> copies
> of the SAM.
>
How are they going to get a copy of the SAM?
They in the default have no grants to the files in system32\config
The same folds for %windir%\repair unless they are Power Users
> Now my main concerns in the above are:
>
> 1) I have no clue what these special service accounts LocalService and
> NetworkService need access to. So far they seem to survive okay under
> the
I am not sure that a general statement can be made, since these are
intended for use by third-party services as well as one from MS.
> rules above, and I pray (since I don't have documentation :) ) that
> Microsoft gave explicit access to files and folders that those two users
> must have access to explicitly. I hope we are not denying access to
doubtful, and I hope not (that is, not explicitly to the accounts)
> something they need access to. Probably we are, but so far not fatal for
> our usage.
>
Much, very, very much depends on how Users is defined.
If left at defaults it is including those service accounts.
> 2) I don't fully understand the implications of removing CREATOR OWNER.
> At very least, it makes it harder to understand what the ACL is doing.
> Removing so far has not created a serious problem.
>
Creator Owner does not grant anything to any account for the object
in whose ACL is it used. It defines a grant that will exist on a future
(not yet existing) object that will be created within the containing
object on which it is used in an ACL.
For it to be useful, account must have separate grant allowing creation
of object that will then get the grant specified in the Creator Owner
grant (notice how a grant to creator owner automatically gets scoped
to subfolders and files?).
Use of Creator Owner allows new objects to have higher permissions
given on them to their creator than they would otherwise inherit from
the container. Look at the special grant to Users on C: in XP, which
enables creation, and then look at the ACL on something created under
C: and notice what it would be without the grant directly to the account
that created (which same resulted from the Creator Owner grant on the
container).
> 3) There are tons of bizarre random permissions on files and folders under
> c:\winnt. Many of these have foreign SIDs that someone failed to clean
> up
winnt ??
So you are looking at something old ?? upgraded OS ??
> when they released code, which doesn't encourage me very much that there
> is
"they" ?? what they?
I have never seen raw sids in ACLs of a fresh OS install.
> a security conscious design on any of it. I don't dare replace the ACLs
> globally as I'm pretty sure I would start breaking a lot of functionality.
Good precaution. But, at this point I do not know what you are looking at.
security setup.inf does document lots of files that get explicitly ACL'd and
you no doubt have noticed that much of system32 is not ACL'd via
inheritance.
> The few changes we are making above are easy to replace if we learn more
> in
> the future and yet they still have a big impact on stability and security
> of
> the file system.
>
From what I have heard here, most if not all of it could be accomplished
by just taking explicit control over Users membership.
Roger
| 
XML Sitemap