Running as Admin - Don't!

I’ve written about the problems of running your machine day-to-day as Administrator, and tips for making development as a non-Admin easier on a number of occasions. As a brief reminder, there are many viruses and other malware that would never have spread as widely as they did if the infected user had not been running as admin. Additionally, developers who run as admin when they develop and test software can inflict errors on those who use their software while running with lower privileges. And unfortunately, the ad-hoc “fix” for such problems often ends up being for that user to run with elevated privileges.

This week, I had the opportunity to address a question on this topic to Steve Ballmer at the MVP Summit in Seattle. I’ve noticed, to my dismay, that many Microsoft presenters continue to run as Administrator in their demos, with no discussion of what the security implications of that choice are. So I asked Mr. Ballmer how those of us who speak to Microsoft customers about security can credibly argue for not running as Admin when many Microsoft presenters are running their demos with elevated privileges. I’m pleased to report that he took the issue seriously, but if things are going to change on this issue, it’s also going to take help from you.

If you attend a Microsoft presentation, and the presenter is clearly running their demos as Administrator, ask them about it. Ask them why they’re doing it, and ask them to discuss the security implications of that choice. I’m certainly hopeful that Steve Ballmer will address the issue from the top, but it can’t hurt to have Microsoft’s customers and developers in the community asking the right questions as well.

The good news is that tool support for developing as non-admin is getting better. One example is that in Visual Studio 2005, it will no longer be necessary to have admin rights to debug ASP.NET applications (because Visual Studio 2005 will ship with its own web server that works only from the local machine). The more improvements like this in tools and OS support for running as a non-admin, the fewer excuses there will be for working with higher privileges than necessary. Combine that with presenters leading by example, and perhaps we can make a dent in this issue.

 

12 Comments

  • You can also look at it this way: it's my system, why can't I do on it what I want? AND why are intrusive programs not ran in a sandbox?



    Especially the second issue is way more important than saying 'don't run as administrator'. Because the way some applications are ran in IE/with IE, make it possible to hack a system by running code under administrator privileges. By saying 'don't run as administrator' you are trying to solve the symptoms, why you should solve the cause: insecure ways of running logic that is pulled from an outside source.

  • "You can also look at it this way: it's my system, why can't I do on it what I want? AND why are intrusive programs not ran in a sandbox?"



    For the first part, because you are connected to a network, and your actions impact others. If you are running as admin, and get infected by a virus that requires admin privileges to propagate, you cause problems for others. If you want to disconnect your machine from the Internet, and never connect it again, be my guest and do whatever you want.



    For the second part, you aren't demonstrating a very good grasp of how software operates in Windows. If we could convince malware authors to only write in managed code, then sandboxing would be a breeze. But given the way unmanaged code operates in Windows, it would be impractical to sandbox all code without breaking a very large number of programs, if it could be done at all.



    And neither of those addresses the other problem with running as admin...if you're developing software as admin, you may end up with software that will not run correctly for normal users. When users run into problems with your software, the most likely way that they'll work around it is to run as admin themselves, thus perpetuating the problem.



    "Especially the second issue is way more important than saying 'don't run as administrator'. Because the way some applications are ran in IE/with IE, make it possible to hack a system by running code under administrator privileges."



    This is *not* just an IE issue. This applies to email attachments, ActiveX controls, and spyware that you may inadvertently install, thinking it's something useful.



    "By saying 'don't run as administrator' you are trying to solve the symptoms, why you should solve the cause: insecure ways of running logic that is pulled from an outside source."



    I'd love to hear what your magic solution is Frans. I haven't heard anything from you that remotely approaches an actual solution, nor have I heard any justification for why you *need* to run as an administrator, other than that you feel like it and you don't like being told what to do. You're certainly entitled to your opinion, but your attitude is fairly selfish given that your determination to do what you want may well impact others.

  • "For the first part, because you are connected to a network, and your actions impact others. If you are running as admin, and get infected by a virus that requires admin privileges to propagate, you cause problems for others. If you want to disconnect your machine from the Internet, and never connect it again, be my guest and do whatever you want. "

    But how am I going to get infected with a virus if all external content is sandboxed? That's what I'm trying to say: if you CAN'T get a virus, you will also not propagate it further. Like the virusscans on outgoing mail. That's nonsense since you don't have a virus present, so you can't send one along too.



    All programs on my machine are running with local content and are started locally. All programs coming from an external source are thus or opened in a browser or via an email. If these sources are sandboxed, they will never be able to have any effect on my local machine nor on the health of the network.



    But because that's not the case, we have to fall back to 'don't run as administrator'-kind of behaviour.



    You know, not running as administrator is not helping you one bit. This is because the windows shell contains a race condition via gui elements of applications running under another user with higher privileges. In other words: as long as you can start a program on a machine with an open shell (and you are working on the machine, aren't you? ;)) the program you start will be able to evelate its access rights. So you have to effectively lock down your complete machine. If you don't believe me, search on bugtrack why it is dangerous to have a gui in a service running as system. You locked down your virusscanner service with gui, didn't you? That's why it is silly to tell everybody not to run as administrator, because it is not safer. Furthermore, it will give you problems in all kinds of areas with applications, f.e. visual studio.



    For whom are you locking the machine down? You're the one working on the machine. The more you lock down the box, the more you will loose time working around the lockdowns.



    What DOES help more is paying attention you will not open up the box to external software or software which opens the box for you: virusscan attachments, strip off any attachments which are executable, be aware of what you install on your machine and if you are unsure, do not install the software.



    On which level do you run your software now, if I may ask? Power user? I hope not, as that's also pretty powerful. A normal user then? How much time do you loose in your 8 hour/day development time? I tried, I lost a lot, it was so darn annoying I put some thinking in it to avoid intrusion AND be able to run the software on MY machine how I want to.



    Agreed, when your main task is typing texts in word, you don't need to have admin privileges. Developing software is another thing.



    "I'd love to hear what your magic solution is Frans. I haven't heard anything from you that remotely approaches an actual solution, nor have I heard any justification for why you *need* to run as an administrator, other than that you feel like it and you don't like being told what to do. You're certainly entitled to your opinion, but your attitude is fairly selfish given that your determination to do what you want may well impact others. "

    I'm selfish? I'm realistic and you're not. You also close your eyes for the real reasons why you think you have to run stuff as a non-admin user. I'd be happy to switch to a normal user, if I could do what I want to do on my machine and I'd be really safe. Because of certain shell leaks I'm not, so why bother? Better keep the doors closed, and I mean: all doors. Do you keep your doors locked when you're at home? Why not?



    I'm in general against 'solving the consequences'-policies, because it will never solve the real cause. If everybody tells eachother "Do not run as administrator", it looks like the problem is solved, but it is not: what you can do is what an intruder can do and probably more due to some sideeffects in the windows gui and services.



    And that while it is so unnecessary as the windows core security system is so well designed, much better than Unix' system for example (security descriptors per object). The problem is however that the shell is developed too sloppy, a lot of win32 applications are not developed with security in mind.



    On Linux and Unix for example, applications do not ask for an 's' bit, simply because no user has that access. So running as non-root (or no 'euid'==0) is not a problem. There are also no problems with leaks to processes which do run with real-uid == 0.



    It's that last fact which makes it easier to run as non-root or your applications without the 's' bit set.



    To sum it up: I'm all ears for a solution for stopping intrusive code. But running as non-administrator is not the solution, that's solving one of the many consequences of having code which allows intrusion. I mean, the main application which you'll use to get access to the outside world (and thus connecting that outside world to your box!) is IE. IE can access any element in your machine and often has to. Ever wondered why? Why is all that necessary when you simply want to visit a website. If IE and Outlook/Express were properly sandboxed it wouldn't be such a problem and if the windows system setup wouldn't have been setup for openness, everybody would have been running as normal user for years already.



    I hope with vs.net 2005 and OTHER applications' next versions (software development as a normal user with accessing / setting up databases, IIS websites, vs.net projects etc. is a pain, really it is) we all can move away from being an administrator or poweruser. Today however it's better to keep your eyes open and think 3 times before you install something or use stuff like IE. (that hole of last week: I read a document in .chm format and it can access my machine... why? THAT's the problem so THAT should be fixed.).

  • Have you even read the doc on the link I posted? It will teach you that running software under normal user privileges is not helping you.



    The problem is that any software you run can hurt your system in one way or the other. A process can still send a virus on your behalf via Outlook via automation, if you have outlook open.



    I.o.w.: running as a normal user gives you a false sense of security that is not there.



    btw, running as normal user to avoid misery requires excessive policy definitions as well. Otherwise, a mailicious CHM file can still harm you in a very bad way.



    I don't know any Linux users who run as root. Suse 9.x doesn't even allow you to login as root. I do know however that every Windows XP home user runs as administrator.

  • "Suse 9.x doesn't even allow you to login as root"

    I of course meant: Suse 9.x' XWindows system..

  • "Have you even read the doc on the link I posted? It will teach you that running software under normal user privileges is not helping you."



    Yes, I read it. And it teaches me nothing of the sort. What it *may* teach me is that there are more steps I need to take to ensure that I'm not vulnerable to this particular class of vulnerability, that is, ensuring that I'm not running interactive services using LocalSystem. As it happens, this is also a fairly standard recommendation relating to least privilege.



    Here's the difference I see between me and you, Frans. You see the problem described by Chris Paget, throw up your hands and say "can't be fixed, so I might as well run as Admin". I say "do everything I can to reduce privileges, and reduce attack surface, and if there's something I can't fix, at least I've made it somewhat harder to exploit my system."



    "I.o.w.: running as a normal user gives you a false sense of security that is not there."



    I disagree. Just because it is *possible* to elevate privileges in the way you describe does not alter the fact that running as a non-admin eliminates a whole class of malware that do not use the techniques you describe. So running as a non-admin doesn't solve *all* security exposure...so what? Security is not all or nothing, it's incremental.



    Again, as far as I can see, all you're doing is throwing up your hands and giving up. I don't disagree with you that ideally, code would be sandboxed, but that's not the case today, and it's not likely to be the case for unmanaged code in the near future. So if there are problems with privilege elevation vulnerabilities, then the solution is not to just say "screw it" and run as admin. The solution is to address those vulnerabilities.



    "I don't know any Linux users who run as root. Suse 9.x doesn't even allow you to login as root. I do know however that every Windows XP home user runs as administrator."



    And that would be one reason why I neither run XP home, nor do I recommend that anyone who cares about security run it.

  • I am a VC++ developer by profession, using Visual Studio 6.0 extensively for my work. Reading all these advices about the hazards of working after logging in as an Admin User, I removed the Local Admin privileges for my domain account. But the immediate outcome of my deed was that my domain account failed to access the VSS repositories from then onwards. The working order was restored only after restoring the Local admin privileges back.



    Thank you.

  • Senthil,



    I'm virtually certain that there has to be a better way to access your VSS repository than to run as a local admin. Do you administer the VSS database yourself, or is it a central DB run by someone else? If the latter, you should work with them to get your domain account set up properly to access VSS.

  • Sooo long...the post...so long. I think that if you don't run as admin your posts should be truncated to 225 characters.



  • The major drawback for me is that you can't override Windows Explorer operations. Good luck changing Control Panel setting as non-admin.

  • Mikhail writes:



    "Good luck changing Control Panel setting as non-admin."



    Easy. Just open a command prompt with admin credentials using runas, then type c:\program files\internet explorer\iexplore.exe. Now you have an IE window running as Admin. Change the address to C:\, click the Folders button in the toolbar, and VOILA!, you now have an Explorer replacement running with admin credentials, and you can change ACLs, use Control Panel applets requiring elevated privileges, etc.



    An alternate technique is to select Tools | Folder Options in Windows Explorer, click the View tab, and then check the Checkbox labeled "Launch folder windows in a separate process", and click Apply. Now, you *can* use runas to run Windows Explorer with different credentials.



  • Frans - I think your arguments and length of your posts are both very silly - in spite of you obviously knowing some technology fairly well. (Duthie - good job with the rebuttals - but don't let Frans give you carpal tunnel.)



    The point is for everyone to try harder to make multi-level Access Control work as intended - and to move away from habits and attitudes which decrease overall security - AND apply pressure to MS and Software Developers to do the same.



    Frans, your attitude is a perfect example of 1 half of the problem.



    AtomicPunk

Comments have been disabled for this content.