WINDOWS XP - Running Windows Under Non-Admin Accounts
Everyone knows that one of the most important principles of network security is least privilege: grant ordinary users only those rights and permissions they need to get their work done and no more. For example, if ordinary users don’t need access to sensitive data stored in the Accounting share, don’t give them any permissions on that share, either through shared folder permissions on the share itself or NTFS permissions on the folder underlying the share.
Least privilege is more than a security principle, it’s also a lifesaver as far as the day-to-day job of administrators is concerned. Reason is, users are curious creatures and tend to push the envelope of what company policies allow and forbid them to do. Give a user local administrator privileges on their computer and they’re likely to try all sorts of things like installing additional software, changing configuration settings, and even poking around the registry to see if they can “tune” their machine to make it run better. From an administrator’s point of view however, this can be disastrous since the wrong tweak might break some application or even render their machine unusable. The user then cries for help and as an administrator you pretty much have two choices: wipe their machine and re-image it from your standard desktop image or spend useless hours trying to troubleshoot their problem. The second choice is usually a waste of time unless, contrary to company policy, the user has been saving important files on their machine instead of on the network. And the first choice is almost like spitting in the wind—you re-image the user’s machine and he just goes and fools around with it again.
Group Policy is one way of locking down what a user can and cannot do on their computers and using their credentials. But what if company policies (or culture or politics or on the job realities) mean that your users need to have the ability to install their own software and configure settings on their machines? If this is the case, you have two choices: give your users local admin privileges, or don’t. Since the first option causes the troubles I’ve described above, let’s explore the feasibility of the second option.
The Pain of Running As Non-Admin
If you choose not to make a user’s domain account a member of the local Administrators group on their machine, the user is likely to complain loudly for a number of reasons including the following:
When they try and install software on their machine, the install will usually fail with an error of some sort.
When they try to adjust the Date and Time in Control Panel, they get a dialog box saying they don’t have sufficient privileges to do so.
When they try and configure Power Options in Control Panel, they can change the setting in the GUI but when they click OK to apply changes they get an Access Denied message.
When they want to share a folder on their machine so another user can access their files, they can’t because there is no Share tab on the properties sheet for the folder they want to share.
Working around the last three complaints is fairly straightforward (I’ll show you how in a moment), but the problem of not being able to install software is a complex issue for several reasons. First, most software (including many of Microsoft’s own applications) requires local administrator privileges in order to install under any version of Microsoft Windows. On the face of it, this requirement is due to the fact that applications need to write to special areas of the file system and registry. But that’s not the real reason applications need admin privileges to install—the real reason is that developers are generally too lazy to bother creating Setup or Windows Installer packages that will work under non-admin privileges. This is because doing so involves going through a number of hoops as a developer, and that means extra work (which most developers want to avoid). But it also means developing these apps while running under non-admin privileges yourself, and again that involves lots of bother so most developers don’t bother—it’s much easier to develop an application if you are logged on as Administrator, so most apps are de facto designed to run under admin privileges as well.
Installing Software As Non-Admin
So how do you install software when you don’t have admin privileges on a machine? The tedious way is to log off, log on as Administrator, install your software, log off, log on again with your ordinary user account, and then start using the software as an ordinary user. The fancier way of course is to use the secondary logon feature (the Runas.exe command) of Windows 2000 and later. With .exe files (and .msc files or consoles) you can right-click on the icon and select “Run as…” and then specify local admin credentials for installing the program. Unfortunately the “Run as…” option doesn’t appear when you right-click on .msi files, but the workaround here is to use Runas to open a command prompt (cmd.exe) window using admin credentials and then run the .msi file to install the app.
Unfortunately, some programs after they’ve been installed with admin privileges using Runas still don’t work properly when you try and run them as an ordinary user. This is because when you use Runas to install something, any per-user settings that the install routine creates are written to the user profile for the local Administrator account instead of to the user profile of the currently logged-on ordinary user account. And of course that causes problems when you try and run the installed program later as an ordinary user. Once again, the developer who wrote the program could have worked around this issue, but why bother when everyone runs Windows as Administrator anyway?
I’ve experienced this kind of thing myself several times with both third-party Win32 apps and also .NET Framework applications, and it’s frustrating. For example, I recently wanted to take an e-learning course in ASP.NET application development from Microsoft. Unfortunately for some reason I couldn’t download the course (a .NET app itself) when logged on using my domain user account, so I opened an instance of Internet Explorer using local admin creds and successfully downloaded the course. But when I tried to run the course locally on my machine, it wouldn’t run when I was logged on as ordinary user. So I tried using Runas to run the course under admin privileges and it still wouldn’t run. In the end I had to log off, log on as Administrator, download the course, and run it while logged on as Administrator in order to get it to work. Frustrating! Maybe if I investigated the problem further I might have discovered why it didn’t work the first time, but that just illustrates in the first place why most people run Windows under admin privileges all the time—if you aren’t running as admin, you can waste a whole lot of time trying to make things work.
The Least Privilege Red Herring
Furthermore—and this is something that’s only recently started being considered by security experts—it may be that this whole least privilege issue is something of a red herring in the first place. Sure, if you’re logged on as Administrator and you browse the web and come across some nasty site and download a virus, that virus gains control of your system using your own credentials i.e. administrator. And if you were an ordinary user and browsed that same site, the virus would only have limited access (the level of privileges of a domain user) on your system so the potential damage would be mitigated. But actually it’s more complex than this. After all, if the malware you download is a worm that exploits a weakness in a Windows service, then it really doesn’t matter what account you’re currently logged on as.
Furthermore, the smartest black hat hackers out there are already busy trying to figure out new ways to create malicious code that can own your system even if your logon privileges are minimal. Because of this, the upcoming and highly-touted Least-privilege User Account (LUA) feature of Longhorn (now Windows Vista) that will do away with the deprecated Power Users group and enable LUA-compatible apps to be installed and run using ordinary user credentials is really no panacea for the security issues surrounding the use of least privileges. You can bet your bottom dollar that the bad guys out there will find some way of circumventing LUA or even leveraging it to their advantage, opening up a whole new kettle of worms.
So while least privilege is still a good idea, it’s certainly not the be-all or end-all of network security. In other words, you still have to think defense-in-depth and consider least privilege (or LUA) as simply one more obstacle in the way of hackers owning your system.
Some Non-Admin Workarounds
Going back to our list of things ordinary users complain about, let’s look at some workarounds. Say you’re logged on as an ordinary user and want to share a folder on your system. If you open Windows Explorer (explorer.exe) and right-click on the folder, there’s no Sharing tab so you can’t do it. And Runas doesn’t work with explorer.exe because Explorer is already running as your shell, so you’re out of luck there as well. Fortunately there’s a workaround: use Runas to start Internet Explorer (iexplore.exe) instead of Windows Explorer (explorer.exe). Then once IE is open, type C:\ into the address bar and click the Folders button on the toolbar and suddenly it looks like you’re in Windows Explorer. Now navigate to the folder you want to share and right-click it and select Sharing and Security and you’re on your way.
And while we’re at it, note that the folder tree in IE displays a Control Panel node. Select this node and in the right-hand pane you see all the Control Panel applets. Try using Date and Time to change your system time—it works! Since IE is running under admin creds, all the apps you access in it including Control Panel applets also run with admin credentials. Same goes for Power Options, Network Connections, System, and other applets that have reduced functionality when run as non-admin.
There’s an even easier way however (the IE method works but is a bit messy since iexplore.exe is not in the system path) and that’s to do the following:
Log off and then log on as Administrator.
Open Windows Explorer
Select Tools, then Folder Options, then View, and select the checkbox labeled “Launch folder windows in a separate process”
Close Windows Explorer and log off.
Now when you log on again as an ordinary user, you can right-click on explorer.exe (or its shortcut), select “Run as…”, specify the local Administrator account credentials, and Windows Explorer now opens running with admin privileges.
Conclusion
Running Windows as non-admin is challenging, and while there are some security benefits to doing so, the hoops you have to jump through to make things work can be daunting. Furthermore, these security benefits are not as great as many security people tout them to be, and it won’t be long until the bad guys figure out ways to install serious malware on Windows even when users are running as non-admins. Follow @aleemxp
No comments:
Post a Comment