Windows Technical Reference - Windows, security and filesystems permissions

I felt that this needed to be more of a guide rather than a quick technical reference, as there are a number of factors and dependencies on knowledge of certain principles, so I'm going to try and encompass those as well.

First of all, why bother in formatting volumes as NTFS in Windows? The answer is fairly simple: it provides a consistent security model in Windows.  Without it, there are very few safeguards to stop any potential vulnerability becoming a full, system-level compromise.  Even on a machine that I am absolutely sure will never be used for multiple users or the running of services, I will always use an NTFS filesystem (though mainly for extra reliability).  There is an argument that Windows performs better on FAT16/32 filesystems, but I doubt the performance advantage (if any nowadays) is worth the cost in extra filesystem reliability that NTFS has to offer, as well as the extra layer of security.   I have also run some basic benchmarks and found no difference in performance (sometimes one filesystem turns out slightly faster, sometimes the other).

But I'm the only physical user of my machine, and I log in as admin anyway!

Not a particularly advisable thing to do, even though I do the same myself, as well as running IIS some of the time.  It doesn't help when say for example the occasional game requires admin privs for some bizarre reason, but this is the fix that Windows users find themselves in.  Do as I say, not as I do! :-P  In the workplace I run all user-type apps as a standard user, and log in as admin when I need to.  In testing virus scanners once, it saved me from having to clean up after a virus was executed, as the permissions denied the virus any write access to the operating system.

Okay, getting to the point of this article now

So now you have installed an Windows NTx box with all volumes formatted [or converted to] NTFS, how should you go about setting up the permissions?

First of all, a few cautionary notes: System volume permissions on NT4 by default, even after all service packs have been applied, are atrocious.  They allow a very simple means of privilege elevation through the replacement of trojaned system files. Windows 2000 and XP's aren't quite so bad by default, but are worth tightening, especially if they're to be used on say an IIS webserver.  But for filesystems permissions there are not "one size fits all", secure solutions, so everyone has to go "the long way round" and actually learn what privileges are required for the different operations they're going to be needing the machine to perform, and also how to investigate this requirement for operations they haven't learnt this for.

System volume permissions

Marginally, the most important volume to get the permissions right.  It contains the vast majority of the files, that if one of "those damn hackers"* were to write over them with their own, trojaned versions, would give you a really bad day.  It's fair to say that the Administrators group and the SYSTEM user should have full access to the entire volume.  After that, it depends on the function of the machine.  It apparently is a little redundant to set SYSTEM user privs as the system is supposed to have full privileges across all volumes anyway, but as the SYSTEM (or any admin user) could easily obtain full privileges across any volume, it seems a bit pointless not to allow them to.

Multi-user, variable privs, standalone workstations: 99% of the time, users with an average knowledge of Windows do NOT need admin privs, nor do they need extensive extra FS permissions.  However, they do need some extra permissions here and there to ensure that as far as they're concerned, everything runs smoothly, and they have access to only what they truly need to.

On a workstation with multiple users set up, I would typically start off with the following privs:

Then I would create the users.  When they first log on, the system handles creating their profile directory for them with full privs (on only their profile directory and no other permissions alterations).  This gives the user enough privs to write to their profile (which by default includes their 'My Documents' directory).  All recently-updated, multi-user aware applications like say MS Office 2000 are designed to work properly under this permissions model.  Older applications require far more careful testing, like for example in Word 97 with a normal user, the spelling function does not work, and requires a registry tweak before it will work.

Servers and stuff

IIS requires significant amounts of access to the system volume, unsurprisingly.  It installs into C:\WINNT\SYSTEM32\INETSRV, but throws a lot of files into the system32 directory.  It also installs the http error files into C:\WINNT\Help\iisHelp\common, and all the files it uses need to allow at least the IUSR account have read/execute access to them, and if you use ASP, and/or extra users to define access to say 'admin' areas of websites (http auth access), then those users need access to all of those files as well.  Irritating, I know, though the model can be made a little simpler through my tweaks for moving the Inetpub folder off the system volume.  Still, in the end it makes sense to set up the following permissions on C drive (and then revoke permissions for certain folders elsewhere):

I did once perform full tests of what files were required to have IUSR read/execute access, but the list is about 100 files long at least, across the entire system volume.

Why don't I just give you my scripts

(For installing system volume permissions) Because then you wouldn't learn the where's, how's and why's yourself, and chances are you'd come complaining to me that you had toasted something my script(s) weren't designed to handle!

Sorry, that's the way the cookie crumbles.

Troubleshooting permissions

When testing applications, it is a good idea to set up more security auditing, such as full object access auditing, which is an invaluable troubleshooting tool.  Also, 'filemon' and 'regmon' are utilities for monitoring file and registry access, which are downloadable from sysinternals.com.

Footnotes

* - "those damn hackers": a [intentionally comical] phrase of mine after listening to an Irish relation bang on about "those damn hackers" and how society would be better off without them.  Needless to say, he's not a computer expert :-)

[Constructive] Windows AdminCentral feedback should go to mike dash wac at mikeymike dot org dot uk, please.  Non-constructive feedback should stay in that head of yours :-)

Modified: 20/07/2006, Mike Coppins.
Tested on: WinNT4, Win2k, WinXP.
www.mikeymike.org.uk

mikeymike.org.uk