Fixing profile permissions in Windows XP Home

If you log onto Windows XP Home under an account with Administrator privileges and try to access the files in the profile of another account, you will get an Access Denied error. This is because of how the permissions are set up on the directory tree. In one recent example, I found that the Owner of the directory tree couldn't be displayed, and that the Account that used that profile and the SYSTEM account had Full Control, whereas no other account had any control.

What I would like the permissions to be is for the profile user to be the owner, but for the Administrators group to have Full control. You can't do this (at least, not easily) using the security tab interface in Windows XP Home (either through the Security tab hack for XP Home, or through logging in in Safe Mode) nor through CACLS, XP's built-in command line tool for file permissions.

Instead, I used SetACL, a great tool that I have been using more and more lately. It took me a while to figure out how to accomplish what I wanted, but eventually I came up with the following method of changing the permissions for the whole tree:

1. Change the owner of the profile directory to the Administrators group.
2. Give the Administrators group Full control, and enable permissions propagation for the entire tree.
3. Reset the owner to the account holder.

The syntax of SetACL can be pretty obscure, so here is an example batch file to do the above. The account affected is the Owner account.

setacl.exe -on "C:\Documents and Settings\Owner" -ot file -actn setowner -ownr n:Administrators -rec cont_obj

setacl.exe - -on "C:\Documents and Settings\Owner" -ot file -actn ace -ace "n:Administrators;p:full" -actn rstchldrn -rst dacl

setacl.exe -on "C:\Documents and Settings\Owner" -ot file -actn setowner -ownr n:Owner -rec cont_obj

The above lines wrap, so note that each line starts with setacl.exe.

RunAsAdmin: Living with Limited User Account

The Problem

Most users of Windows XP run as local Administrators all the time. Everyone knows this is not the best way to work from a security standpoint After all, most nasty stuff (viruses, worms, spyaware) gets onto a computer because of either email or malicious web sites, and these nasties can only get installed on the system if you read your email or browse web sites as an Administrator. People know this, but they still run as an Admin because running as an unprivileged user is inconvenient. If you do run as a User and you need to do something as an Administrator, you either have to use runas from a command prompt, or log out/switch users to a privileged account. Kind of a pain. Also, this means that you are making changes under a different account - you can't access your network resources, and changes that affect the profile are touching the profile of the Administrator account, not the profile of your "regular" account.

Solutions

There are basically two approaches to solve this problem. One is to run as an Administrator and to selectively drop down to a regular User for "risky" actions (like web browsing). This is the solution offered by the program DropMyRights. The solution I prefer is to run as a regular user all the time, and then selectively elevate your current account privileges whenever you need to run as an Administrator. Aaron Margosis discusses a tool to do this in his MakeMeAdmin blog post. MakeMeAdmin takes your current account, adds it to the Administrators group, opens a DOS prompt under this elevated account, then removes your account from the Administrators group. Thus, you run your normal account as an Administrator, but only in the context of that DOS prompt.

His solution is good, but it still leaves you with only a DOS command (unless you choose to run each Explorer window in a separate process, which I found can chew up memory). Also, I didn't like the way the batch file prompted me for passwords twice. I wanted a graphical window to enter both passwords at once, and then have it take me to graphical environment in which I was a member of the Administrator's group.

I solved this problem by extending Aaron's concept with an AutoIt script. The script prompts me for the name of an Administrator account, the password of that account, and the password of my current account. It then searches for something to run. It can run a batch file named <scriptname>.bat or <scriptname>.cmd, where <scriptname>is the file name of the RunAsAdmin executable, minus the extension. This allows you to use it to run any program that requires Administrator access.

Alternatively, RunAsAdmin can run the A43.exe executable. A43 is a file management utility. I first learned about this program through the excellent BartPE boot disk, which uses it as an Explorer substitute.

Click the image below to see the effect of running RunAsAdmin with A43 on your computing environment.

The Script and how to use it

You can download the compiled executable from here:

RunAsAdmin.zip

Move the file RunAsAdmin.exe into a folder. If you want to use RunAsAdmin with A43, download A43 and extract it into the same directory as RunAsAdmin, so that the file A43.exe is in the same folder as RunAsAdmin.exe. Otherwise, you can create a batch file called RunAsAdmin.bat in the same folder and RunAsAdmin will run that. If you rename RunAsAdmin, you must rename the batch file to match its new name except for the .bat extension.

Once you have it set up, just run the RunAsAdmin.exe program. It will prompt you for the name of an account that is already a member of the Administrators group. (If you click the check box, it will store this account name in the registry so that you don't have to enter it the next time). It will also prompt you for the password of the administrator account, and your current account's password. Once you click OK, it will add your account to the Administrators group, run either the batch file or A43, and then remove you account from the Administrators group.

One other thing to note is that if you use this method for making changes to your system, you should make the Administrators group the Owner of new files that you create while you are an Administrator. Otherwise, malware could affect changes you made while your privileges were elevated. See Aaron's discussion of this issue in this blog post.

The ZIP archive above also contains the source code for the script, so you can edit it to your needs. You'll need AutoIt to run or compile it. The script as written requires a splash screen, so I also included the one that I used.

Final Thoughts

Since my first version of this script, I have been running for months as a regular user on several of my production boxes. I don't find it very inconvenient. After a while I have learned to run RunAsAdmin once and then to leave it open for when I want to run Admin tasks. I also use it to run a program that refuses to run as anything other than as an Administrator, and that requires network access.

I have found using the script to be a minor inconvenience compared to the risks of running as an Administrator. I say this as someone who has not seen a virus on his system in years and who has never had a problem with spyware. However, I don't doubt that someday, someone would eventually come up with a way to trip me up if I continued to run as an Administrator. That's why I want to run as a regular user - I just think that this is a better way to run.

HP Security Mess

I got pulled into an issue at work. Seems that one of my clients is moving to HP hardware, and they ran into a security issue [hp.com] with the software that is driven by the special keys on the laptop.

Here is the gist of the security issue [securityfocus.com]. The HP Info Center basically puts a shell around an Internet Explorer instance, which calls javascript that creates some ActiveX objects in the page. The ActiveX objects launch HP control panels stored on the machine. The DLL (HPInfoDLL.DLL) that contains the ActiveX object is the source of the security problem.

So what is HP's solution? A security update. Pretty straightforward, right?

Well, not so much. The updater that they supply doesn't check that the original file - or even the HP Info Center software - is installed on the system before installing the update. And if the software is installed, it doesn't do any version checking on the DLL. It just writes right over whatever version of the DLL is on the computer.

You might think that this last is a problem, right? What if another security issue is found? Well, here is why it isn't a problem. The updated DLL - doesn't do anything. Well, OK, maybe it does something. But it sure doesn't create the ActiveX objects that the original did. Consequently, when the HP Info Center is run, instead of showing icons to launch DLLs, users see an Internet Explorer Script error. See it here.

When the desktop manager for my client saw this, and I explained that it was the documented behavior of the update, he flipped out. And I can understand why. With the update installed, when users press a key on the laptop, what they will see is an error. They'll think the software is broken. And what do users do when they have a problem on their computers? Yes! they call the Helpdesk! He was envisioning having to explain to dozens or hundreds of users that the error they were seeing wasn't really an error.

Here is how I fixed the problem. I poked around, and found the Javascript that was driving the vulnerability. It is contained in a file called HPInfoCenter.js. I then found the file that was calling this JavaScript file. It is called HPInfoContent.html. I looked in the latter file, and found that it was calling the JavaScript in the <body> onload event. So, I just removed the onload reference to the JavaScript file. Then I edited the HTML of the HPInfoContent.html file to basically tell users that the Info Center doesn't do anything and that they should look for the HP controls in the Control Panel. Voila! No more script error!

The real question, though, is why HP felt compelled to create such an application. Why not just create a folder with shortcuts to the control panels? Wouldn't this accomplish the same thing?

Not as cool, I guess. Plus, if they had done this, I wouldn't have had the chance to be clever over this!

Sorry that this post is kind of complaining, but I do enjoy finding clever solutions to such problems.

The real problem with Vista

So I've been trying out my company's preview ("beta" - in quotes, because, it isn't really beta except in the sense that the deployment method is beta) version of Vista and Office 2007. I've had it running for a while, and I am getting a sense of why people dislike Vista. It isn't just that I had to go all over the place to find out why it wouldn't work with the NT4 test domain that the machine sits in (Lan Manager vs NTLM2) or that UAC is a pain.

As an aside, UAC (User Account Control) is a pain, but not because I dislike clicking pop-ups that ask if I know what I am doing. I find this an acceptable annoyance for security's sake. No, I dislike it because it breaks almost all of my scripts. I didn't realize how much I rely on scripts until they started failing with no error messages. I can't use AutoIt to drive Internet Explorer on my Vista machine (yet). I haven't figured out how to debug VBScript scripts on Vista (yet) - it took me a while to glom onto the fact that it was probably UAC that was causing it to fail.

What bugs me about UAC is all the ways that it blocks actions with no error messages. I understand that the reason for this is probably because Microsoft wants to avoid a denial-of -service type attack with a never ending stream of UAC messages - but come on, some indication of why things are failing would help.

No, the Real Problem with Vista that I have seen so far is that it looks like stuff was changed in the GUI just for the heck of it. Just because they could. And it looks like the decisions of what to change were made by poll - the asked a group of people "which of these changes do you like the most?" and then they went with the one that 55% of the people said they wanted. It certainly doesn't look like someone with a grand plan sat down and made consistent decisions about what to change.

For example: when you go to save a file (in Notepad, or Internet Explorer), you don't get the usual Browse window that we have been seeing for the last 15 years. No, you get a minimalist couple of lines that list paths. You have to click a button to get the file browser window. This is progress?

You can't drag copy files to a command prompt and have the path show up on the command line.

Folder icons have changed. Folder icons changed from Windows 98 to 200 to XP - they got prettier, they got cooler. But they basically stayed the same. Now the folder icons have turned sideways (so, if it was a real folder, the papers would fall out), and, in the Classic theme at least, they are blue instead of yellow. Blue? Why? Folder icons may seem like a minor gripe, but I noticed that in Regedit, I can no longer tell which is an open folder, and which is closed, so when I lost my place in a long list of registry keys, I couldn't tell where I was by looking at the icons.

Explorer is ... weird. Even in small icon view, the column headings show like it is Detailed view. Very strange.

And all the paths have changed, some in weird ways. Why has Microsoft, after over a decade of promoting spaces in critical path names, finally gotten religion about no spaces in common directory names? Is it really possible that after all this time, some developer still can't figure out how to use double quotes in path names? Why, in AppData, do I have Roaming and Local? Is it because Microsoft finally realized that dumping all kinds of critical stuff in Local Settings in Windows XP (like Outlook files) and then ignoring those files when the profile was backed up or migrated was a Bad Idea? Or was it just because they developers could?

Well, enough bellyaching for now. It really does look like someone said that Vista had to be Different, and that is why these changes were made.