X

DropMyRights part 3: Living with it

Living with the DropMyRights program.

Michael Horowitz

Michael Horowitz wrote his first computer program in 1973 and has been a computer nerd ever since. He spent more than 20 years working in an IBM mainframe (MVS) environment. He has worked in the research and development group of a large Wall Street financial company, and has been a technical writer for a mainframe software company.

He teaches a large range of self-developed classes, the underlying theme being Defensive Computing. Michael is an independent computer consultant, working with small businesses and the self-employed. He can be heard weekly on The Personal Computer Show on WBAI.

Disclosure.

Michael Horowitz
7 min read

The first posting of this three part series on DropMyRights explained what the program is and why, I think, everyone running Windows XP should use it. The second part covered the somewhat unusual procedure for installing and configuring DropMyRights. This final posting describes using Windows XP after DropMyRights has been installed, and responds to some reader comments.

Although I have only discussed using DropMyRights with Windows XP, it also works with Windows Server 2003. It does not work with Windows 2000. On a technical level, it should work with Windows Vista and Windows Server 2008, however there isn't the need for it there because, by default, users are not administrators (that is, they don't run in unrestricted mode).

OOBE


The first thing you will notice (OOBE = Out of Box Experience) when using DropMyRights to run an application in restricted mode is that a black command window appears for literally a second. This brief black window is the DropMyRights program. As shown in Part 2, you first run DropMyRights and then it, in turn, runs the target application. The black window is your assurance that DropMyRights is on the job.

But how can you tell if an application is really running in restricted mode?

With a Web browser, try to save a local copy of a Web page (File -> Save As in IE 6 and IE 7 or File -> Save Page As in Firefox v2). No matter what, you should be able to save the page into the My Documents folder. The real test comes when you try to save the page into a system folder such as C:\Windows or the root directory of the C disk. An unrestricted Web browser can save files into system folders, a restricted one cannot.

The excellent and free Process Explorer program from Microsoft can be used to check if any program is running in restricted mode or not. Double click on the process, go to the Security tab and look at the Privileges in the bottom half of the window. If there is a single privilege called SeChangeNotifyPrivilege with flags of "Default Enabled" then the process is running in restricted mode. If many privileges are listed (even though most are disabled) then the process is unrestricted. Michael Howard offered a more detailed and technical explanation of this in his January 2005 article "Browsing the Web and Reading E-mail Safely as an Administrator, Part 2."

Restrictions are inherited


If a restricted application spawns another application, the new one also runs in restricted mode.

For example, if you are running a restricted instance of an e-mail program and click on a link in an e-mail message to open a new copy of the default Web browser, the browser runs in restricted mode. However, if an unrestricted instance of the default browser was already running, it remains in unrestricted mode when displaying the page from the link in an e-mail message. (Of course, if you are using DropMyRights, then there shouldn't be an unrestricted instance of a Web browser.)

When IE 6 and IE 7 and Firefox v2 are running in restricted mode, any new windows or tabs they open also run in restricted mode. Likewise, should a restricted mode browser launch another application such as Windows Media Player, iTunes or the Adobe Acrobat Reader, they too run in restricted mode.

Java


Java is an interesting case because it has its own security rules, separate and distinct from Windows.

Java applets that run in their normal sandbox run fine within a restricted mode browser. For example, there is an applet at my javatester.org Web site that displays the version of Java being used. I've run it many times from a restricted mode Web browser without a problem.

Java applets that need to violate the Java sandbox have to ask for permission. This is true, for example, of the free Transaction Guard utility from Trend Micro. When run from Firefox, it starts off as a Java applet (from IE it starts as an ActiveX control) that can't run until you approve it. When approved, the Transaction Guard applet downloads, installs and executes a pair of Windows programs, even when run from a restricted instance of Firefox. Process Explorer and Task manager both show that Transaction Guard consists of two processes, tgsvc.exe and tgui.exe.

How is this possible?

Both Transaction Guard programs run out of the same folder
C:\Documents and Settings\userid\Local Settings\Application Data\Trend Micro\HCMS\tsafe\en-US\
(where userid represents the current Windows logon id)

This is a user folder, not a system folder. Every directory under C:\Documents and Settings\userid\ is updatable, even to a restricted Windows user, which is why Transaction Guard can be installed there. You can see this yourself by trying to save a Web page there from a restricted mode browser.

It may seem dangerous that a restricted instance of Firefox was used to install and run two Windows programs, and in some ways it is. These programs can delete or modify anything in the My Documents folder as well as the other sub-folders under C:\Documents and Settings\userid\.

On the other hand, both Transaction Guard processes inherited the restricted mode of the Web browser that spawned them. Thus they can't be fully installed and will not run the next time Windows starts up.

The threat of a program wiping out all the files in the My Documents folder is similar to the threat faced by a restricted user in Linux or the Mac OSX. Restricted users can't corrupt the operating system, but they can corrupt their own files. Backup. Backup. Backup.

Problems


One thing that won't work in restricted mode is Windows Update. Sometimes the error message specifically mentions logging on as an Administrator, but other times, the errors are useless. Still, generating an error message at all puts it ahead of Flash. Installing a new version of Flash just hangs. Likewise, the F-Secure online virus scanner hangs, without producing an error message, when it starts to remove tracking cookies.

DropMyRights can be transparent; thus, if you're like me, you can forget that it's being used. Every now and then I get an error when I try to install software. This happens after downloading a program from a restricted instance of my browser and then having the browser display the folder where the downloaded file was saved. At this point, Windows Explorer is running with the inherited restricted rights of the browser, so it can't install software. No big deal, all that's necessary is starting a new instance of Windows Explorer.

I have read, but not confirmed that:

  • Shockwave sometimes needs to run in unrestricted mode.
    See "Reducing browser privileges" by Mark Squire, October 2005
  • Intuit QuickBooks 2006 needs to run unrestricted
  • Family Tree Maker 2006 needs to run unrestricted
  • Turbo Tax needs to run unrestricted for the auto-update feature

If you can confirm any of this, please leave a comment.

Is DropMyRights the right approach?


Some commenters suggested another approach to solving the same basic problem (running programs in unrestricted mode when they can, and should, be run in restricted mode)--logging on to Windows as a restricted mode user. In theory, this is the right approach, but practically speaking it simply presents the problem from the other side. For a program to run in unrestricted mode, you have to poke a hole in the default restrictions. Think of it as UpMyRights. There are a number of programs that do this, and you can refer to the reader comments for references.

In my opinion, while that may be a more secure approach, the fact is that many/most Windows users already log on as an unrestricted user (Administrator) and thus DropMyRights is the easier solution for them to implement. A techie familiar with DropMyRights can walk up to a Windows XP machine for the first time, copy the program from a thumb drive, and make new shortcuts for the Web browser and e-mail program in literally a minute. DropMyRights offers a lot of protection for very little work.

Logging on as a restricted user may offer more protection, but at a higher cost in terms of time and effort. In April 2006 Brian Krebs, writing in the Washington Post said: "Ever since I wrote a column late last year urging Windows users to reconfigure for limited accounts, hardly a week has gone by when I haven't heard from some reader who's had problems as a limited user." ("Windows Users: Drop Your Rights"). For more about logging on to Windows as a restricted/limited user, see Aaron Margosis' "Non-Admin" WebLog.

Whether the extra protection offered by logging on to Windows as a restricted user justifies the extra effort, depends on the specific situation and will always be a matter of opinion. If a computer is shared by parents and their children, then having the children log on as restricted users is probably worth the time and effort.

Finally, I hope that installing and configuring DropMyRights, unusual though it is, didn't seem too daunting back in Part 2. It may sound worse than it is. But, the price of security always has been and always will be inconvenience.


Update August 26, 2007. I just added a posting on what to do if an Office file doesn't display or work properly when the application is run in restricted mode.

And to respond to some reader comments:

No matter where the DropMyRights.exe file is located, the "Start in:" box of the shortcut properties window should be the folder where the target application (IE, Firefox, etc.) resides. Good question, I should have mentioned this.

Using DropMyRights does effect the speed at which an application starts up but the effect has been trivial in my experience; I'd guess the delay to be under a second, but your mileage may vary.

I haven't tried running auto-started programs with reduced privileges, but I would expect it to work the same as manually started programs. If the auto-started program is started using the Startup folder, then it's controlled by a normal shortcut which can be modified as described in Part 2. However, if the auto-started program is kicked off by a registry entry, then modifying the registry should be possible, but again, I haven't actually done it. Anyone who has, please feel free to leave a comment with your experiences.