Running Non Admin

re: Running Non Admin

Wallym — Wed, 22 Sep 2004 17:47:00 GMT

How would I debug another Windows Service? I think that I still have to run as admin. Would I not have a problem with a service that I wrote as well as debugging ASP.NET code running in IIS? I seek guidance.

Wally

re: Running Non Admin

Larry Osterman — Wed, 22 Sep 2004 17:51:00 GMT

To debug a running process, you need the SeDebug privilege. And that means that you're effectively an admin. Instead of being a true admin, you could go with Power User, but it's trivial for a power user to elevate their privilege to admin.

My solution, like that of many other developers, is to have a separate machine for test purposes - I'm an admin on that test machine, but a limited user on my day-to-day machine (but I don't debug on that machine). I also don't do anything other than test on the test machine. I regularly pave over the test machine, and I don't allow any sensitive data to be kept on the test machine - it's a machine whose contents I don't care about.

re: Running Non Admin

Robert Hurlbut — Wed, 22 Sep 2004 18:06:00 GMT

A nice solution to the problem (i.e. two machines). But, do you also test as a limited user, depending on the test? I have been running as a non administrator for awhile, but I also test on other test systems as non administrator until I hit the final wall when I have to move up to administrator level.

Also, Wally, there is a specific way to debug ASP.NET pages as a non administrator (set the user for the ASP.NET process to a limited user -- it can be encrypted as well rather than listed in open text in machine.config). The good news for ASP.NET is that you will be able to debug as a limited user in ASP.NET 2.0. Good to see this is catching on and tools are being changed accordingly.

re: Running Non Admin

Larry Osterman — Wed, 22 Sep 2004 18:12:00 GMT

Robert, I don't test as a limited user, unless there's a specific test case that fails when running as a limited user. The reason I don't test as a limited user is simply that I need to debug the audio service. And that service runs as LocalSystem (currently, we're trying to understand if we can change that). So at a minimum, I need the debug privilege.

Our test team DOES run all the tests as a limited user, and their test results matrix knows which tests should fail in that case and which should not (for instance the tests that stop the windows audio service fail when running as a limited user).

re: Running Non Admin

Jerry Pisk — Wed, 22 Sep 2004 18:13:00 GMT

How would I get notified about Windows Update updates if I was not running as an admin? As a developer I really don't feel like allowing windows to reboot my box whenever it feels like, there are quite a few nights when I am up working at 3 AM. And even some when I'm still up at 6 AM. And some when I'm already up at 7 AM. So picking a fixed time is just not an option. But the Windows Update (and Automatic Update) teams just assumed that as a regular user you don't need to know about available updates. Would it kill them to popup a balloon telling me there are updates available (the detection run as a LOCAL SERVICE anyways) and either prompt me for admin credentials to install the updates or just sit in the tray, remindimg me to login as an admin and install the updates?

re: Running Non Admin

Robert Hurlbut — Wed, 22 Sep 2004 18:15:00 GMT

Thanks for the update. That makes sense -- only using the least privilege you absolutely need (in this case, debug privilege).

Re: Running Non Admin

kprobst@gmail.com — Wed, 22 Sep 2004 18:27:00 GMT

As of Windows 2000 (IIRC) some of the MMC plugins did not work when invoked via "Run as...", which would be the rough equivalent of running [su] under Linux or BSD. I don't know if that's the case in 2003. The thing is to make it difficult to screw up or modify the state of the system significantly. In this regard, I think Linux is very good, though their implementation(s) mostly suck. There needs to be a way to go from admin context and back, with some visual clue that affects windows under the admin context, for example. Also, Microsoft has to push OEMs (to ship boxes configured this way) and software vendors (to fix their apps so that they don't assume admin rights). As long as Dell and Gateway keep shipping XP Pro with a default admin account enabled by default not much will change. I suppose making every copy of Windows 98 disappear into a black hole would work as well.

re: Running Non Admin

Michael Geary — Wed, 22 Sep 2004 18:30:00 GMT

It's funny, I open the Date and Time control panel quite often, but never to change the time. (I've used SocketWatch for years.) I open the panel to see the time down to the second, or to see the date when the usual tooltip isn't working (it happens). It's fairly amazing that someone would lock a limited user out of this useful display panel. What were they thinking?

re: Running Non Admin

Larry Osterman — Wed, 22 Sep 2004 18:32:00 GMT

Michael, that's why I posted that example :)

It's a case of UI design sillyness - the UI designers never considered that their control panel applet would ever be used for something OTHER than to set the time on the machine, so they didn't code it that way.

re: Running Non Admin

Stephen Veiss — Wed, 22 Sep 2004 18:35:00 GMT

I'm hoping that once the new billing system for AC is in place, that stumbling block to running as a normal user will be removed. I'm not holding my hopes too high though, as AC modifies its data files during both the monthly updates and during play.

It's good to see that things are getting easier to run as a limited user - I've not made the switch myself yet, but the machines I set up for other people are setup with limited user accounts. I'm probably going to give it a shot next reinstall.

re: Running Non Admin

Larry Osterman — Wed, 22 Sep 2004 18:37:00 GMT

Stephen, Ibn assured me that they're going to fix that problem with the new billing system. It remains to see if they can successfully execute on that promise, but...

I suspect they've not yet considered what happens when a monthly patch happens.

re: Running Non Admin

Skywing — Wed, 22 Sep 2004 19:09:00 GMT

After I gave myself SeShutdownPrivilege (I want to be able to hibernate my laptop), I find running as non-admin not that difficult. (Actually, there's a obscure interesting quirk with Windows's support for hibernate that I noticed as a result of this: if the logged on user has SeShutdownPrivilege, then you can tell the computer to hibernate by hitting the hibernate hotkey even if the user has locked the console with lock workstation. This is a bit weird because you can't shutdown without unlocking, but you can still hibernate.)

It seems you have better luck than me with games; must every game I've played requires that I give myself write to it's directory (in %ProgramFiles%).

Definitely agree with you on the Date & Time control; not being able to open that has bugged me quite a lot :)

What I usually end up doing is keeping a cmd running as admin sitting around in case I have to mess with a control panel applet or debug a service -- works nicely.

re: Running Non Admin

Wallym — Wed, 22 Sep 2004 19:21:00 GMT

Thanks for the suggestions. yeah, I realize the problem goes away with .NET 2.0. I'll look into them.

Wally

re: Running Non Admin

Mike Dimmick — Wed, 22 Sep 2004 19:22:00 GMT

Some bits of Computer Management are guilty - see for example Device Manager:

"You do not have sufficient security privileges to uninstall devices or to change device properties or device drivers. Please contact your site administrator, or logout and log in again as an administrator and try again."

Once you've OKed this box you find you can view quite a lot of options, and particularly see if a given device is actually present. You can modify serial port settings, if required (and if any!)

My biggest annoyance is the lack of Run As on Control Panel applets. Partly this is because some of them should be MMC snapins, IMO - Control Panel is now something of a mixture between user profile tools and system administration tools (aka what the heck are Windows Firewall and Security Center doing in Control Panel anyway?)

The trick as always is to come up with a way for things to happen without continually prompting for an administrative password. I always heard that Windows' "single-sign-on" was intended to prevent users from becoming anaesthetised to typing in their passwords - we want to consider carefully how we ask for an administrator password*, some way that can't be easily spoofed, and not do it so often that users follow the 'Install ActiveX Control' path, simply clicking to get rid of irritating prompts. [* - of course I mean 'the password to an account with the appropriate privileges', not necessarily the password for LOCAL\Administrator or even necessarily a member of BUILTIN\Administrators]

Finally, MS needs to consider the difference between limited users on a domain, where there's a full-time administrator (very rarely asking for admin passwords), and limited users on their own home computers, where they really are the administrator, just choosing not to run with elevated privileges. Ideally even the full-time administrative staff should run without privileges until they're required. It's what I do at work (though I should set up separate administrative domain accounts and stop using DOMAIN\Administrator).

Picky mode: Larry, have you got an auto-correct from 'principle' to 'principal'? "Principal of least privilege" should be "principle of least privilege", etc.

re: Running Non Admin

Rob — Wed, 22 Sep 2004 20:22:00 GMT

I'm really surprised to hear that Larry is *only* just starting to run as a limited user, especially after his post some time ago rebutting a supposed security vulnerability in XP SP2 caused by the user running as Administrator.
How can he expect the public to run as a limited user when even the people that know about security don't?

And yes, plenty of stuff apps sucks when running as a limited user or started using the runas command (InstallShield is one).

re: Running Non Admin

Larry Osterman — Wed, 22 Sep 2004 20:42:00 GMT

Rob,
I actually wrote the post close to a month ago, and had been running as a non admin for about a month before that.

Having said that, yeah, I should have been a non admin before that, mea culpa :)

Hibernate vs. Shutdown

Tim Farley — Wed, 22 Sep 2004 22:48:00 GMT

The hibernate versus shutdown thing isn't that odd. When you come out of a hibernate, the desktop is always locked. So the only thing hibernate can do is prevent an already started program from continuing to run.

But consider: if you can touch the hibernate button, then you have physical access to the machine. So you could cut the power to it anyway and achieve the same thing.

re: Running Non Admin

Jeremy Brayton — Wed, 22 Sep 2004 23:19:00 GMT

Quote:
But maybe I wanted to use the date&time control panel as a shortcut to the calendar? I know of a bunch of users that call action of double clicking on the time in the taskbar as invoking the “cool windows calendar”

YES! Finally someone in MS has acknowledged the most annoying part of running as a limited user. My solution? Desktop Sidebar. It has a calendar and a clock I can simply look at. Oooh pretty.

The biggest hotkey I know for limited users? Left shift. This is extremely useful in the control panel when right clicking on things like Add/Remove programs. It's the only way to bring up the Run As... shortcut on some contextmenus

I also keep a shortcut to "runas iexplore -new C:" (removed full path for shortness). This allows me to run Explorer as Administrator so that I can change certain things like Security permissions for those weird games and other applications not programmed with the thought of multiple users in mind (circa '95). For those I simply give the Users group Write and Modify permissions of the directory only. Problem solved. I know it's kind of a security risk but the applications I have to change are almost useless to begin with.

The only way to fix it completely is for developers to write software with multiple users in mind. Even if the intent is for only one user on the system to use it, you can still get away from designing software using this approach. I have some applications that I NEVER have to tweak in this way: RSSBandit is one, SharpDevelop is another. If I don't have to touch security settings for your application I consider it a good thing.

The sad truth is I bet we'll see a lot of Longhorn apps still being coded in this pre-2000 "one user, one system" mentality. Even if the system itself will exhibit a limited priveledge mentality, the applications that run on it will lag far behind.

I think we need a list of "non-admin friendly" applications. That way some of us can point and laugh at those developers who insist on developing applications in a Windows 95 mentality. That would also allow those of us running as a non-admin to pick only those applications that will cater to our needs. I normally try to find cheap software but there have been times when I would pay dearly for something that'll work naturally in the environment I've learned to embrace whole-heartedly. I don't login as root on my Linux boxes any more, so I'm not about to run as Administrator.

re: Running Non Admin

Steven Bone — Thu, 23 Sep 2004 01:28:00 GMT

To digress (only slightly) from Larry's excellent post, and respond to Jeremy's "one user - one system"... I recall trying to figure out how to make a nameless media player work on my Uncle's PC with different profiles. For good reason, my uncle didn't want to share a playlist with his son - but that wasn't possible.

To get more on point with Larry's post and comments, make sure when testing software during development to have an XP Pro machine with NTFS to catch issues related to non-admin filesystem permissions.

Everyone's Talking About Least Privilege!

Don Kiely's Technical Blatherings — Thu, 23 Sep 2004 06:08:00 GMT

Everyone's Talking About Least Privilege!

I had more problems after switching

Martin's WebLog — Thu, 23 Sep 2004 09:40:00 GMT

re: Running Non Admin

David A. Mellis — Thu, 23 Sep 2004 10:45:00 GMT

Another convenient thing to have would be a "copy as" or "delete as" command. For some reason, I can't run Windows explorer as a different user, and this makes it more difficult to install programs that don't have setups.

re: Running Non Admin

David A. Mellis — Thu, 23 Sep 2004 10:45:00 GMT

re: Running Non Admin

David A. Mellis — Thu, 23 Sep 2004 10:49:00 GMT

Also, why do I have to be an admin to change my file associations? What if two users of the same computer want to use different web browsers or image editors?

re: Running Non Admin

Serge Wautier — Thu, 23 Sep 2004 11:57:00 GMT

Larry,

> I don't test as a limited user

Isn't testing the whole purpose of developing as non-admin ? OK? I understand that in your specific case, you may need to run as admin to debug. But then, what's the point to bother developing as non-admin ? (I mean from development task point of view, not from a generic computer usage point of view).

> unless there's a specific test case that fails when running as a limited user.

You assume that you know upfront what these cases are. My understanding is that developing as non-admin is useful precisely to minimize the probability that we forget such cases.

Or did I miss something ?

re: Running Non Admin

Ovidiu — Thu, 23 Sep 2004 13:54:00 GMT

I run as a user. I had been running as an admin for a long while, then I switched to running as a user, then switched back to running as an admin because I need to be able to debug web applications, Windows services, I need to be able to install/uninstall things (e.g. message queues) as pre/post build steps, I need to use Server Explorer and so on.

I'm experimenting a different approach now: I run as a user, but I run Visual Studio as an admin, with the user's environment ("runas /noprofile /env /savecred /user:Administrator devenv.exe") whenever I need to do "advanced" stuff. For "regular" stuff (e.g. Windows Forms), VS works ok even as a user. Still investigating what the pros and cons could be (I had a bit of trouble with extension packages in VS, but otherwise thing seem ok so far).

re: Running Non Admin

Larry Osterman — Thu, 23 Sep 2004 14:21:00 GMT

Serge,
No, testing ISN'T the point of developing as non-admin. Developing as non-admin is about ensuring that my machine isn't vulnerable to security holes.

When I'm testing, I'm testing a new functionality I'm adding to the system. For that, I need to be able to attach a debugger to random processes, modify the registry, install new COM components, update service config, etc. In other words, I need to be an admin.

Now, you could say that I'm testing Windows XP when I'm running XP as a non admin, and that's a fair comment. But any testing I'm doing in that configuration is incidental to my development work, and isn't my primary focus.

Living the non-admin lifestyle

Robert Hurlbut's .Net Blog — Thu, 23 Sep 2004 18:45:00 GMT

re: Running Non Admin

Mat Hall — Thu, 23 Sep 2004 16:16:00 GMT

"Isn't testing the whole purpose of developing as non-admin?"

Remember, Larry is lucky enough that the REAL testing of his work is done by someone else. The last time I did any development in a team with dedicated testers, my testing was of the "it compiles, runs, doesn't break the build, and seems to do what I intended it to". I then handed it over to someone else who hammered it to death in completely unexpected ways and handed it back to me...

re: Running Non Admin

Norman Diamond — Fri, 24 Sep 2004 00:44:00 GMT

9/22/2004 10:51 AM Larry Osterman

> To debug a running process, you need the
> SeDebug privilege. And that means that
> you're effectively an admin.

From the point of view of security threats you're effectively an admin, but from the point of view of reducing the damage from accidental human errors you're effectively not an admin. Try taking advantage of it.

> Instead of being a true admin, you could go
> with Power User, but it's trivial for a
> power user to elevate their privilege to
> admin.

Exactly the way it should be. When you need a privilege and decide you want to use it, you take it. There are still two conflicting goals here, so let's consider some options.

With programs, the principle of least privilege is exactly correct. When a program needs a privilege, take the minimum privilege needed, and then revoke that privilege as soon as possible. This takes some extra effort in development but it goes far towards reducing both the damage caused by accidental errors (bugs in programming) and malicious security threats.

With human operations, picking one minimum privilege and guessing wrong (actually needing a different privilege, or an additional one or six of them) is irritating and frustrating. So if a human operator can take extra care while operating as administrator, maybe it is safe enough to temporarily take all privileges and then revoke them as quickly as possible. But I still prefer the VMS philosophy rather than the Unix philosophy on this matter. With Unix you're forced to temporarily take all privileges. With VMS you can choose for yourself whether to temporarily take all or temporarily take minimal (or temporarily take some other subset).

re: Running Non Admin

foxyshadis — Sat, 25 Sep 2004 07:07:00 GMT

There's a fine line between two different annoyances. It's damned annoying to not be able to open up an applet you know has nothing worth securing visibility of, only changes. But it's possibly more annoying to open up an applet, futz around, think 'this is good', hit OK and get a big 'NO AUTHORIZATION' blaring. You just wasted all that time and mental energy and have to log in elsewise and redo it. The power options applet is a perfect example of this - a limited user can't even view the current settings if I remember correctly; a few times I've tried setting them all as I need them only to be kicked out and log in as admin to find them already there fine.

The best is the advanced network connection sheet's method, just disable options that aren't allowed, except that the deisgner has to be conscientious enough to check for privelidge for each option, and do it right. Ah, the pitfalls of UI design.

Geek Notes 2004-09-30

Geek Noise — Thu, 30 Sep 2004 23:40:00 GMT

re: Running Non Admin

Caliban — Sun, 03 Oct 2004 19:12:00 GMT

I feel that running non admin works well when using XP Pro but on XP home it causes more pain as most of the rights are already preset.

For example try to hibernate without being an admin (not easy as you can't give the right, and strangely enough it was still working ok under SP1 but not anymore under SP2 :-( ).

I still prefer to be non-admin but I suspect a lot of home users will not accept this.

Holes are everywhere

Rubber Chicken — Wed, 15 Dec 2004 19:15:00 GMT

This Windows vulnerability shows that even the simplest programs can have issues. It is also a strong argument for not running Windows with Administrative permissions....

re: Not running as Admin....

Sorting It All Out — Wed, 02 Mar 2005 19:26:00 GMT

To Be Or Not To Be (An Administrator)

Nazul's Weblog — Mon, 28 Mar 2005 05:59:00 GMT

En Windows tenemos el síndrome de ejecutar las aplicaciones como Administrator. ¿Podremos quitarnos ese vicio?

Least privileged user access for developers

Nigel Watling — Sat, 30 Jul 2005 00:55:07 GMT

OK, the last entry was a teaser for a blog entry or two on what developers can and IMHO should do regarding...

Larry Osterman s WebLog Running Non Admin | Quick Diets

Larry Osterman s WebLog Running Non Admin | Quick Diets — Wed, 10 Jun 2009 06:05:32 GMT

PingBack from http://quickdietsite.info/story.php?id=9815