|
Posted by Jesper on December 26, 2006, 12:25 pm
Please log in for more thread options
First: No, there is no good security reason to do ANYTHING on a blanket basis
to the ACLs on the built-in binaries. Not only would doing so put your system
into an unsupported (and unsupportable) state, there is no way to undo your
changes without flattening the box and rebuilding it. Changed a specific ACL
on one or a few files is fine, but changing the ACL on the directories is
not. See KB 885409 for more details.
Second: the behavior is probably to be expected. I can't seem to repro it at
a glance, but I am running Vista as a non-admin, so things are probably
different there. If a user runs the EXE the system could very well try to
request a few extra access rights, to see if it has them. Those would
generate your audit errors.
Third: what specific threat are you trying to mitigate? What risk do you
think is unacceptable using the built-in ACLs?
"Will" wrote:
> I'm noticing that a very large number of EXE and DLL files in c:\windows of
> both Windows XP and Windows 2003 require the executor to have "Write
> Attributes" permission against the file. Without that permission the EXE
> still operates, but you get a security audit assuming you are tracking
> failures on Write Attributes.
>
> When you are trying to secure a drive by having common users only have Read
> & Execute access to most of the drive, the sheer number of log messages can
> get distracting. Is there a good security reason to not enable common
> users to have Write Attributes permissions against c:\windows and its
> children that inherit the auditing settings?
>
> --
> Will
>
>
>
| 
XML Sitemap