[262] in winnt
Re: Securing the WinNT root.
daemon@ATHENA.MIT.EDU (Tom Fitzgerald)
Mon Nov 16 15:28:17 1998
To: Don Nelson <dnelson@psfc.mit.edu>
Cc: ntpartners@MIT.EDU
In-Reply-To: Your message of "Thu, 12 Nov 1998 13:08:57 EST."
<9811121810.AA07724@MIT.EDU>
Date: Mon, 16 Nov 1998 15:27:20 EST
From: Tom Fitzgerald <tfitz@MIT.EDU>
> I am looking for a tool or a set of rules to use to create or modify
> "permissions" on the folders and files under the WinNT root for the purpose
> of preventing members of a specified group from accidentally or
> deliberately creating or modifying files (and from installing apps).
I'm curious what other people are doing with this too. I've got a long
cacls script that locks down things to a large extent, using the
recommendations from Frisch's "Essential Windows NT System Administration"
and my own experiments. (It should actually use xcacls instead, since
cacls can't deal with some of the miscellaneous filesystem objects created
by IE 4.0.)
> When NT is installed in an existing NTFS partition, a complex set of
> permissions is defined for every folder and file under the WinNT tree. The
> permissions vary from folder to folder and from file to file.
.... but the permissions are still far more lax than necessary. Microsoft
assumes that normal users will still be installing software under their
own logins, so lots of system directories are still writable by world.
> The implication is that it is neither safe nor wise to make a sweeping
> declaration of restricted access for a group across all folders and/or
> files under the WinNT tree. Preventing the creation or modification of
> files under the WinNT tree must cause some apps to fail.
It does. Internet explorer in particular really wants to write to WINNT
subdirectories. Or if you lock things down too much then specific
features like help or printing don't work in any applications.
I've actually had more problems with application directories than with NT
itself. An appalling number of programs keep config files in their
application executable directories, and require user write access to the
config files, the application directories, and in some cases even the
application's own executables. It's pretty easy for users to fill up app
directories with data files, or to mess them up in other ways. In fact,
there are very few programs that are well-behaved by Unix standards, and
that don't require user write access to some piece of their
installation tree.
