次の方法で共有

HOWTO: Run as normal user (non-admin) on Windows

  • [アーティクル]

Sometimes, I wonder and worry about the vast majority of Windows users that run with administrative privileges. Most of them probably do this blindly because it is the default auto-login for Windows XP and do not know any better. This tells a lot about the power of having secure defaults...

However, such unnecessary privilege comes at a great price: spyware / malware / virus / trojan / worm freely misuse such privileges to infect and proliferate. And in knee-jerk response, a whole security industry dedicated to corraling these miscreants spring up and some even enter the Microsoft product line and Windows Update.

But, no one seems to be tackling the fundament security problem:

  • Users running with more privileges than necessary
  • Social Engineering and poor computing habits

As I had discussed earlier, the effective computer system security is simply the weakest link amongst Software, Configuration, and Policy. Simply focusing on using Software to compensate for a lack of secure computing practices (Policy) does not improve security. I mean, we can come up with perfectly written Software with no bugs nor security vulnerabilities and Configure the system securely yet functionally, but if the user runs as administrator because "things work better" or blindly follow instructions to get themselves rooted, all the effort is for nothing. This is why I think that such actions do wonders for PR and user perspection (and sometimes, changing perceptions is "the goal"), but it really does not raise the bar.

I do not know about you, but I like making real progress, not perceived progress. So, I am going to show one approach that I use to not run as administrator to safely compute on Windows - both at home and work.

I mean, I really hate personal security software from McAfee, Symnatec, etc because they assume how you want to work (so many people fail to install IIS on Windows XP due to these software packages "breaking" IIS in subtle ways to prevent installation/functionality), and they do not do much more than common sense... so I consider them unnecessary bloatware that gets in my way. Yes, I do not run security software on all of my machines; no virus scan, no email scanner, nada. I just run as normal User with Windows Firewall sealing off all ports and common sense against social engineering. :-)

Securing the Computing Environment

No, I am not going to wait for Windows Vista, LUA, and various other security advancements to help run as non-administrator and secure my computing environment... not when I can do it all right now from Windows 2000 on up.

What I do is basically:

  1. Run as the normal User, with no privileges changes from the default
  2. Run a special "root" console window (that is a different color) as a user with administrative privilege
  3. Leave the Firewall on and do my job as the normal User, and on the special occassions where I need elevated privileges, I launch commands out of the special "root" console window

That is it. It is functionally similar to how LUA will work in Windows Vista, except with GUI dialog boxes instead of console commands. And this is how I create the desktop shortcut to launch my special "root" console window (I actually just copy the same shortcut on all my machines to %ALLUSERSPROFILE%\Desktop):

  1. Right Click on the desktop and create a shortcut
  2. Paste in the following as target for the shortcut (in my case, I rename the Administrator to "root"):
    %windir% \system32\runas.exe /u:%COMPUTERNAME%\root "cmd /T:3E /k @title root && start /min %windir%\system32\taskmgr.exe"
  3. Choose your shortcut title - I use "root"
  4. Change the icon to something obvious. I use the icon in SHELL32.dll that contains a key with two people.
  5. I change the screen buffer size to 50 Width and 2 Height - so that the shortcut just shows a small window containing:
    Enter the password for %COMPUTERNAME%\root:
  6. I also change the shortcut's text and background color to Yellow on Cyan so that it matches the color scheme of the root console window - just so that the window is very obviously different than the white on black of normal console windows.

Now, what are some of the "inconveniences" that I incur by doing this? Well:

  • I lose the ability to install/uninstall programs as myself. But, I just run "appwiz.cpl" or the program's setup EXE from the root console window and things usually work. If they do not, I consider it a product bug.
  • I lose the ability to run Windows Update for patches. This is something that I cannot do from the root console window, so I have to login as an administrator and let Windows Update client run every six months or so. Yes, I do this infrequently because I run my computers securely, and I only login once every six months or so, so this is no bother.
  • I cannot kill any process that I want. But, that is what the TASKMGR.EXE run as root (from my shortcut), or TASKKILL.EXE in the root console window is for.
  • I cannot Remote Desktop into that machine by default. On Windows XP and later, I just add my User to "Remote Desktop Users" group. On Windows 2000, I have to use the root console window to launch MMC with the "Terminal Services Configuration" snapin, select Properties on the RDP-TCP connection, and add my user to the "Permissions" tab of that connect (Windows XP and later pre-create and populate the "Remote Desktop Users" group into this Permissions list).
  • I cannot configure networking or Windows Firewall. But, NETSH.EXE on Windows XP/Windows Server 2003 works wonders inside a root console window.
  • I lose the ability to change the system date/time. But, I just use the DATE or TIME commands in the root console window as necessary.
  • I can no longer start/stop services. Well, that is what NET START, NET STOP, and SC QUERY commands in the root console window are for...
  • I cannot change file ACLs to grant myself privileges. But CACLS does that nicely from the root console window.

Overall, I find that the "inconveniences" happen very rarely in my day-to-day activities. You rarely install programs, patch, reconfigure networking, stop/start services, and change system date/time and file ACLs on a daily basis... so it makes sense to not run with administrative privileges

Now, I know that there are cases where you may want to run a program but that program only works when run as administrator... such as games or other older software... but I tend to leave them alone. The way I think about it, until the users revolt with their pocket books, application providers have ZERO incentive to fix/improve their code. So, I do not buy such software and if I do, I bug the heck out of their support staff and complain that their product is insecure because it requires me to run with administrative privileges. Hey, some have listened and changed. :-)

Well, I know that this does not solve all your problems on Windows, but hopefully it can help you solve a good chunk of your security concerns. I am interested in hearing some of your stories regarding this topic...

//David

Comments

  • Anonymous
    November 09, 2005
    Your approach is absolutely correct. This is exactly what I do on our PC at home. All users run with limited priviledges and I use a command prompt via runas (exactly as you do). Your idea about kicking off a taskmgr simultaneously with it is neat though!

    Mike

  • Anonymous
    November 09, 2005
    You are spot-on here for sure. Most security problems would disappear if people did not run as admin. Those that do are ignorant of how it should be done. At least MS is making moves to change this with Vista.

    I was very pleased to see your comments about bad software coders...I wish they all worked the way it's supposed to.

    I have spent 3 years telling this to my (now) 15 year old son and it's hard to tell him he cannot have a game on his PC because it does not run as a normal user. I mostly get around this by giving users write permissions on that game folder.

    Yes, we need more people with these opinions.

  • Anonymous
    November 09, 2005
    The comment has been removed

  • Anonymous
    November 10, 2005
    how do you handle when you have to manage lots of files? i have files scattered around 9 hdd (files like game demo, pictures, funny video, mp3s
    my user account with limited privilege lists them as read only so when i'm done with viewing the video or demo or when they are no longer new how am i supposed to delete them ?!
    if i allow my hdds to be write to normal user and i get a malware/worm that want to delete my files...the security purpose is no longer effective

  • Anonymous
    November 10, 2005
    to delete files where you have readonly privileges with limited accounts i created a shortcut with my program to internet explorer and in the address bar type the location of the files like c: and now you have a windows explorer with root priveledges

  • Anonymous
    November 10, 2005
    An additional inconvenience on XP Home edition is the apparent lack of the ability to grant process debug privileges to a limited user account (secpol.msc is not available on the home edition).

  • Anonymous
    November 10, 2005
    Paul - Your scenario does not sound realistic.
    1. On the one hand, you want your user account to be able to delete such files when they are no longer new.
    2. On the other hand, you want malware/worm that run as your user account to NOT be able to delete such files when they are no longer new.

    These two statements contradict because you want your account to simultaneously be able to delete and not delete a given file.

    Your scenario is still best fit by running as normal, unprivileged user. If the user can download the file and write it somewhere, they obviously have the privileges to null/delete that file. No wide-open privileges are necessary. And if you are worried that malware infects your user account and uses the credentials to delete your files - that is what backups are for.

    //David

  • Anonymous
    November 10, 2005
    gosaca - I have never used XP Home, but I do not see the limitation. Here's my reasoning:

    First, a user should not be running a debugger to begin with.

    Ok, suppose the user needs to be running a debugger. A user can always debug their own processes. You need debug privileges when you are unprivileged and trying to debug other user's processes.

    Ok, suppose the user needs to debug other user's process. If they are soft-core they will use something like Visual Studio .NET, which has a "Debugger Users" group that grants the privilege. You do not need secpol.msc to grant yourself debugging privileges.

    Finally, suppose the user is hard-core. Then the user would not install Visual Studio .NET, and since secpol.msc is not available to grant themselves debug privileges, they can use the freely available Microsoft Debugging Tools from an account with administrative privileges to do the task of debugging another user's processes.

    I think the number of people at each one of my steps decrease exponentially. The set of users that hit your stated "limitation" should know what is going on and account for it.

    //David

  • Anonymous
    November 11, 2005
    David you are incorrect (on XP Home at least), a limited user account can not use VS.NET to debug any process, not even their own.

    Can we agree that this is an "inconvenience" similar to those you list in your post, rather than a limitation - sorry to have used that term.

    Your repsonse is so unnecessarily defensive that it is comical. "A user should not be running a debugger". - LOL








  • Anonymous
    November 12, 2005
    gosaca - Maybe you deem my apparent trivializing of your statement as being defensive - I apologize. I was probably a bit too fast and blunt with the details.

    I hope you agree that when running as non-admin, ability to debug processes is just not in the same ballpark as ability to run Windows Update, install Applications, configure networking, or even changing the system date/time.

    I just happen to give detailed reasons as to how small a user group should actually get affected by your statement, and the correct users in that group should not see it as a limitation... hence I do not see it as a limitation, and certainly not of the same magnitude/scope as the others.

    That is not to say that your issue is not real. The strange thing when talking about Windows is that the trivial 1% user base may contain millions of non-trivial users... and we usually only hear complaints from those minority users. Just to help you set my frame of reference.

    Anyways, I am doubtful that XP Home disallows users to debug their own processes since that is an intrinsic Windows NT feature and without it, technologies like OCA Watson to gather crash data and "Send the report to Microsoft" will not work.

    So, I am hopeful to believe that your problem is somehow isolated, and I will independently check out what is going on with XP Home because what I say definitely applies everywhere else. Your solution is probably in there somewhere; just have to identify what is going on.

    //David

  • Anonymous
    November 14, 2005
    David, this appears to be a VS.NET specific problem; I've verified that WinDbg will attach to processes that have launched with a limited user account, which makes perfect sense given your point regarding Dr. Watson & crash reporting.

    VS.NET on the other hand will not provide a list of processes to attach to, and amazingly will not allow one of its projects to be started with its own debugger - error messages state that one must be an administrator or a member of the Debugger Users group. This appears to be an oversight by the VS.NET developers.

    When using XP home the problem is exacerbated as there is no obvious way to add a limited user to the debugger users group.

    Perhaps this is a good reason to finally take the time to master WinDbg (or even OllyDbg which also works properly).

  • Anonymous
    November 14, 2005
    gosaca - Does the following work when run from an administrator's cmd console:

    NET LOCALGROUP "Debugger Users" LimitedUser /ADD

    This is similar to how I deal with non-administrators not being able to Remote Desktop by default. I have used this many times on XP Pro/WS03 (though I expect it to also work on XP Home).

    //David

  • Anonymous
    November 15, 2005
    David, yes, this works perfectly - many thanks.

  • Anonymous
    November 16, 2005
    gosaca - excellent. It sounds like XP Home should be working just fine for you to debug using Windbg or VS.Net. Everyone's happy. :-)

    I don't know if this is true on XP Home, but on Windows OS you can run "lusrmgr.msc" on the commandline to do the NET USER/NET LOCALGROUP tasks in a GUI.

    //David

  • Anonymous
    November 17, 2005
    The comment has been removed

  • Anonymous
    November 17, 2005
    gosaca - Don't worry. Separate teams own NET.EXE, LUSRMGR snapin, the User/Group dialog, and the underlying Win32 API. But, they are aware of the inconsistencies...

    //David

  • Anonymous
    December 08, 2005
    Great stuff, David. You are exactly right about people surfing the Internet with admin privileges.

    I use 2000 and I still love it. With proper security practices just about any OS can be safe.

  • Anonymous
    February 07, 2006
    You say something about "inconveniences"? Although you made a very good (and true) article, you're not a real Admin guru rightnow. ;-)

    You can use nearly every *.cpl and *.msc from your root console, so you get a GUI for all your task like services (services.msc) or hardware management (sysdm.cpl).
    You can also run iexplore.exe instead of explorer.exe, so you have a GUI for Windows Update, network management, or just copying files or set permission. Just open the "Folders Pane" in IE to get access to all real and virtual folders the "normal" Explorer provides.

    Andreas

  • Anonymous
    February 07, 2006
    Andreas - hehe... I put "inconvenience" in quotes because I'm more hard-core than that. ;-) As proof, I submit the following:

    I mostly skip the UI and go to the commandline. I do run just about all the necessary .cpl and .msc from the root console window when the need arises, though I would just as quickly use commandline equivalents to bypass the GUI.

    For example, instead of appwiz.cpl, I:
    1. wrote a little script tool to allow me to manage ARP
    2. run sysocmgr in Unattend mode to configure settings

    Instead of ncpa.cpl, I run NETSH.EXE

    Instead of desk.cpl, I tweak the Registry keys and call the underlying APIs to refresh.

    Instead of sysdm.cpl, I wrote script tools to:
    - Change computername from the command
    - Modify the environment variables from the commandline
    - use MOBSYNC.EXE, NET.EXE, and SC.EXE to accomplish equivalent tasks...

    Instead of Windows Update in IE, I directly script the WU ActiveXControl to do what I need.

    Etc.

    I admin my system just fine, and I don't need the crutch of a UI... ;-)

    //David

  • Anonymous
    February 14, 2006
    I'm very impressed! ;-)

    I like the GUI because otherwise I could run a Linux server. In my opinion it's really cool that Windows support both ways.

    Cheers,
    Andreas

  • Anonymous
    July 22, 2006
    Create a shortcut for the following and you will get GUI with administrator privilege.

    C:WINDOWSsystem32runas.exe  /u:administrator "C:Program FilesInternet ExplorerIEXPLORE.EXE -new -e file:///C:/Documents%20and%20Settings/Administrator/Desktop"

    Control pane is there in the left pane to do all administration task. For others and most frequently used tool, create a shortcut in Admin's desktop and those are accessible in the right pane.

    Enjoy secure computing!

  • Anonymous
    July 23, 2006
    The comment has been removed

  • Anonymous
    July 27, 2006
    Back in this blog entry, I mused about the nice Audio over RDP feature. It is pretty sweet to have secure,...

  • Anonymous
    August 03, 2006
    An alternative method to browse local files with root privs is to use "runas /user:root EXPLORER.EXE" - as you would initially expect.

    However, for this to work, you have to check the setting 'launch each Explorer window in its own process' (under Explorer.exe Tools / Folder Options / View tab.) This setting needs to be done under the 'root' user, not the regular user.

  • Anonymous
    April 23, 2007
    The comment has been removed

  • Anonymous
    November 21, 2007
    Actually you can run 'net start' as a normal user,  only 'net stop' is disabled.

  • Anonymous
    November 25, 2007
    I have tried to run this command on my console window : runas /user:administrator "date 01-01-07" i have entried the password correctly but i got the error message : RUNAS ERROR: Unable to run - date 01-01-07 87: The parameter is incorrect. Anyone can help ? Thanks !

  • Anonymous
    February 17, 2008
    Guys (& Gals) Is there a way i can use one of the above posted examples to give std users the correct rights to run the Telephone.cpl applet with elevated privilages from a shortcut, that will then allow them to configure one of the options, primarily the ciscoTSP001.tsp, which we need the end user to be able to access as they have to set and change the passwords within this applet to enable it to function properly

  • Anonymous
    October 31, 2008
    Thanks for the post.  I will link to it from http://qvlweb.blogspot.com/.  I think this will be useful at home were I try to keep the family computer account running with reduced rights.

  • Anonymous
    May 24, 2009
    Most people are n00bs and wont understand how to use the Admin console. Perhaps we can help them a bit by creating a IE shortcut for them to run IE as limited User... It should stop several viruses and avoid several re-installs. And free up my time for more pleasant activities :D