May 27, 2004
Longhorn: Adopting a least privilege stance for users
Recently I was talking with Robert Scoble about Longhorn and I brought to his attention some thoughts I had on least privilege for users in Longhorn. He suggested that I post to Channel 9, which I did. Didn't go over well. No one wanted to talk about it.
Today Alan posted a link to what I thought was a ridiculous comment that the disadvantage of running Windows is how infected you get. I am paraphrasing here, as the actual comment was something like "Friends shouldn't let friends run Windows" with a screenshot of Ad-Aware showing a huge number of infections. This is of course ludicrious, as you CAN run Windows securely. Using the same tool I can show my system is free from any crud, and I would bet I am more exposed to hostile code than the original poster ever is.
But it does get back to part of the conversation Alan and I had, which gets back to my comment to Robert about Longhorn. Normal people don't typically run Windows securely. And we need to change that.
When I posted to Channel 9, I basically had a question for the Longhorn crew that relates to user accounts. I am fully in support of the aspect that we should take a stance of least privilege, and run as a normal user whenever we can. Actually, I have been preaching this for a long time (especially for developers as noted in my CodeProject article on developing with least privilege a year ago), and welcomed the approach taken in XP, hold that to some personal gripes on failures in the way runas works. (Which I have blogged about enough here and here)
In Longhorn I would have thought things would be different. Yet over the weekend during a fresh install of Longhorn I came across something that surprised me. Why is it after a fresh install, while logged on as "Administrator" do we feel compelled to make the first user in the system a member of the Administrator group as well? You have no choice.. you MUST make the first normal user an admin. In a client-based desktop, do we REALLY need to have a second "Administrator" account? If we apply the Pareto Principle (80/20 rule) here, in environments where there may only be one user, they will be FORCED to be an Admin, and chances are they will run with those privileges unaltered. In other words, they will be forced to higher privileges than they need right off the first install, and chances are will not make a second account to log in as. Why? Because they haven't been trained otherwise. They won't know any better. And that exposes the computing environment to more risk than is needed.
Might I suggest we rethink this? Why not use secure defaults and make ANY user being added be set to a limited user by default? When we use runas it defaults to "Adminstrator" anyways, so we have the right exposure to elevate privileges when we need to. I can't quite understand what the reasoning is to have another account.
In unix environments we don't have "root" and then "userroot" and then "user". Why do we feel compelled to do this on Windows?
The reality is, until we get people to run as normal users by default, we will continue to see desktops infected through these common attack vectors. Ad-Aware will continue to barf huge numbers of infections until we make it extremely difficult for suspect code and data to even attach to systems that your mom and dad use. It is possible to fix, I just can't understand WHY its not being done.
Posted by SilverStr at May 27, 2004 01:18 PM
Will respond properly after work :) But quickly now...
Well, first of all the original posting was obviously (to me anyway) tongue in cheek / humorous. Secondly as I put in my email I *have* seen systems that were almost as bad as this, hit this link and check the first and last result (as of now anyway) to see. Maybe the original example was pretty extreme, but not outside the scope of possibility.
Also, there is already a nice GUI system that does what you are talking about with having a user account and only use the admin account when needed, which is OS/X. You don't use the admin account and when you need admin privs you use use a nicely integrated sudo system (just like that which has been used under redhat, mandrake, etc for ages now). I think that the mentality of users on both osx and winxp are the same (ie: "normal" people) and the osx system works far better and users use it "properly" (AFAIK). My thoughts? The way that multiple users are implemented under windows is flawed, and somehow I doubt that it'll be fixed properly in longhorn. You can use windows securely, but it's set up so badly that noone bothers to.
But will post full response later :)
Yes it was tounge in cheek. But there is the same undertone from everyone in the industry. Erroneously believing some OS is superior to another. Any commercial retail OS can be made more secure than its defaults. Even Mac OSX is not immune to problems.
I agree with you that the the implementation of users on Windows is flawed. That was the whole point of this post! But I have to disagree with you that because windows is set up so badly noone bothers to make it secure. I believe its because people don't know any better. Typically 80% of the users use 20% of the features of any sort of software. Thats what the Pareto Principle is about. The trick is to make the operating system more secure by default, disabling/removing functionality not used by most users reducing the attack surface of the platform. In this case, removing an unneccessary admin account can go a long way. By forcing them to act as a normal user, and then cleaning up the way to elevate privileges (ie: To make it easier to make changes to the system, add software etc), you get the best of both worlds.
I can't comment much on the user experience of OSX. I have had limited expose to basically your Apple machines. I will say it was an enjoyable experience, but I didn't try to do any administrative tasks. I think relying on Apple to solve the problem is far fetched... to many people will continue to reside on Windows. As such, we need to change the thinking there. Which again was the purpose of my post.
I'm sure that the undertone in the industry is there for a well deserved reason though.
As far as people not setting it up securely, that was my point :) Whether it is because no one bothers or because no one knows, people still use the defaults, which leads to insecure, spyware/adware/virus ridden systems.
I wasn't pointing to apple to clean up the problem but as an example of a well designed way of doing user/system interaction with admin privilages. Next time you're over I'll show you the admin side of things in a bit more depth.
Not only is the user implementation on Windows flawed, the permission and capabilities implementation is as well. Or rather, the presentation thereof. I have yet to understand how permissions can be set. No, I'm not experienced with Windows administration, but I know my Unixoid systems well and I believe the Windows way could be made much, much easier. If I don't understand it with my experience, how should a user who is not interested in the inner workings understand it? Why should they see a need to do anything about it?
I'm not saying any given OS is better than others (though I have my own experience-biased opinion) but offering user interfaces that make it easier to secure a system should be mandatory. Like you said: the user implementation should always be least priviledge based. And as Arcterex said, this is one thing OS X does exceptional.
Hmm, sounds like you need to read Keith Brown's article on Longhorn. See Longhorn Developer Center at MSDN, "Security in Longhorn: Focus on Least Privilege". Seems they are thinking exactly along the lines you discuss above...
A corresponding issue to this is programs. I am am a network admin of 10 users on Windows XP all of my users are limited users. So I have taken the step to restrict users access. The problem starts when installing new software. Insert CD and I expect to see the run as dialog, so that I can enter the Admin password and install the software. However, I don't always see the dialog. Some CDs start the install program without asking. Other times I see the dialog and enter the password. The autorun program loads running with Admin privileges. But it isn't the install program. So I launch the install program from the autorun program, but it doesn't run with admin privileges or show the run as dialog. Here we have run into a problem. It is sometimes difficult to install programs as Admin without logging out and logging in as Admin. That is a problem. It is sometimes easier just to give users admin access than to have to deal with the hassle. This is an annoyance but not a large problem. The bigger problem is poorly designed software. I have recently installed to pieces of software (with Admin privileges) that would not work if the user was a limited user. The first is PaperPort. I installed PaperPort by using the run as. It was installed with local admin privileges. But I did not run PaperPort once as Admin. Why should I? I didn't install it for admin to use. I installed it for the user. Well, if I run it as a limited user, PaperPort does not scan for installed programs and update its send bar, thereby severly limiting its functionality. You are also unable to add items manually to the send bar as a limited user. This is a problem. My choices are to log in as Admin and spend hours I don't have setting it up or give the user Admin privileges. The other program was a Job Description software. I installed with local admin rights (had to log in as Admin because I never saw the run as). I even started the program as Admin to make sure it was working. Log out and have user log in. Program won't work. Error claims database needs write access. Check access rights on folder and database. Write access is enable. Call support. User must be local admin to run program. Now what? I don't want to give user local admin rights. This type of thing must be fixed before we start forcing users to be limited users. How can we force user to be limited when basic software requires admin rights to run. I understand that this is poor programming on the software developers, but I run into this fairly often. People want their computers to work. They might not mind having to type and admin password to change major settings or even to install software, but having to run software as admin is extremely annoying even if the run as was improved to make it easier to run a program with admin privileges. I don't have time to make sure each peice of software runs properly as limited user. Nor should I have to. If I need admin rights to install, I am fine with that. But I should never need admin rights to run a program or change its basic settings. This is a major roadblock to forcing users to be limited users.
Permissions on Windows are actually more fine grained than on Unix environments. chmod and chgrp are nice, but I have always found that if you are using NTFS, Windows has a MUCH nicer permission structure.
The problem is most people don't know about it. In XP Pro, you need to actually SHOW the "Security" tab. To do so, you must open Windows Explorer, go to Tools, Folder Options, View and uncheck Use Simple File Sharing. Then you can right click on an object (file/directory etc), select Properties, and then the Security tab. In there, you can apply indidivual access rights by people or groups. The ACL for NTFS is superior in its fine grained access control, but it IS much more complex then Unix environments.
Its really a tradeoff. If you want simple access control that works well, Unix environments are much easier to manage. But if you all of a sudden want to apply 3 different users with 3 different sets of perms, on 3 different times of day in 3 different groups, you need to use something like what Windows has to offer.
Keith wrote an excellent article about some of this. But the focus was more on new applications and making it much easier to install software and manage it from a PA (Protected Administrator) sort of thing. It was also surrounded around the idea of using application manifests, which is only useful if you are using managed code. If you are running as a full admin, and are not in a secure sandbox, its a moot point.
I quite enjoyed Keith's article, and found that he touched on the idea of users running with least privilege, but didn't address a simple solution from the first point of installation on how to manage the system in the midst of existing software that will not yet be "Playing nice" with Longhorn. Right now, off the first install you MUST create the first user as an Administrator... and you really shouldn't NEED to.
If anyone is interested in reading Keith's article, you can find it here.
Microsoft is very aware of the problem of applications not playing nice in a least privilege environment. Its a problem with developers of applications who don't know any better and developer as admins themselves. They never see the impact if permissions are constrained when using LUA (Least-Privilege User Accounts).
To battle this, Microsoft has taken some steps to make this easier to manage. In the next version of Visual Studio (Whidbey) you will be able use included tools like PermCalc that evaluates an assembly and determines via heuristics the permissions it needs to run. There are even rumours that Visual Studio will be able to inform/warn you if you try to use an API that require elevated privileges past what the application permission set has been configured to. Oh ya, that reminds me... Whidbey will also allow you to choose the permission set you'd like enforced when you run your application. Using technology like their "Secure Execution Environment" you can limit the impact of risk against your codebase, allowing fine grained control over application confinement strategies.
Longhorn will also be introducing AIM, which is the Application Impact Management tool. It is a tool of last resort that will catch applications that needs more permissions than currently available, and gives the application its own virtualized view of the resource it's attempting to change, using a copy-on-write strategy. The app will think it has perms where it needs it, but actually doesn't. This is kind of a fail safe mechanism for installing apps, but should not be relied on.
Quite frankly, if a developer just wrote his code and installer as a normal user, he could significantly reduce the problems when deploying under LUA. Microsoft realizes this and has been providing various free webcasts on writing secure code which includes topics such as this.
It will take time. For apps to play nice in LUA, users of said software must DEMAND that it works correctly. Otherwise, we won't get very far until Longhorn.
"The problem is most people don't know about it. In XP Pro, you need to actually SHOW the "Security" tab. To do so, you must open Windows Explorer, go to Tools, Folder Options, View and uncheck Use Simple File Sharing."
That method is only needed for a default Workgroup XP install, basically Home and XP Pro not a member of a domain. When you join a domain, the security Tab is turned 'on' so to speak. I didn't realize this on my home system for quite some time until I had to look it up (I hate looking it up, it should have been clear like "ENABLE SECURITY TAB" not "Use Simple File Sharing").
Anyways I've recently redone my home computer which is not part of a domain. I started from SCRATCH as a limited user. Before I was running Admin only with every account and I was literally infected with spyware daily. I had a quarantine of over 2000 entries in ad-aware and that list grew daily.
Now? I have 0. I've not had 1 install itself in the 3 weeks it's been fresh and I've been going to the same sites I was before. I run entirely as a limited user and my computer is thanking me for it by actually running faster. I've loaded the same apps and everything. I guess part of that is due to the fresh install but most of it is due to the fact that it's not so bogged down with it's 'allow everything to do what it wants with the OS' approach.
To be honest, I think Least Priveledge security should be in every OS by default. It's a necessity in this day and age when everyone and their mom is writing trojans, viruses, backdoors, spyware etc (some even funded by companies but I won't go there)
I too have a gripe with the whole Admin + Admin User + Normal user that I HAVE to have. If I was part of a domain I could eliminate that one Admin user I HAD to create during the initial setup, but I'm not. I probably could do it now but I'm not about to take that chance since I just got it working like I want it.
Limited users can be a chore, especially when the install program doesn't pop up the runas dialog. If it's windows installer based, like demoshield, installshield, etc then it will use a runas dialog. Office also pops up the dialog but there have been cases where I've seen an EXE that simply will not allow me to hold left shift, right click, and choose runas. I would have to use the runas command-line and I hated doing it.
Also to make it work right, you usually need to run it as the administrator account to create the necessary files. Since a limited user cannot create files in a directory by default, you either have to tweak security or use a admin user to make those files. This can be a problem though when programs aren't made for different users and sometimes running them as Admin will do nothing for the limited account. I hate that but that's their coding problem, not mine. Hopefully Microsoft will work to lightly or eventually slap these programmers into submission. I'm tired of having to run their program as a security risk because they won't take the time to program securely. That's just plain ignorant.
It's good to know that at least a couple of people at Microsoft are working to making this a default rather than an option. It may be tedious but there'll be ways we can make the experience easier for everyone, even the illiterate computer user who only understands how to turn on the machine and use Word.
I forgot to mention one of my biggest runas gripes.
I like using Explorer.exe to set priveledges. Try using the command line runas /user:Administrator Explorer.exe.
Nothing happens. I'm sure something happens somewhere but I don't see Explorer.
Now you can run cmd.exe and it'll pop up a command shell with Administrator priveledges but I like the GUI. I don't want to have to switch users just so that I can make a small change to a directory or a file that only an administrator can access.
If you want the GUI you just need to make sure you execute the proper wrapper, which is actually iexplore.exe and not explorer.exe (its a neat way to get around your gripe... the same one I had a few years ago).
From the cmd line you can enter:
runas /user:Administrator "%SYSTEMDRIVE%\Program Files\Internet Explorer\iexplore.exe -new c:"
Or you can make a shortcut to do it. Simply create a shortcut to iexplore.exe and use the "Run with different Credentials" checkbox as you would any other way. In the target enter:
"%SYSTEMDRIVE%\Program Files\Internet Explorer\iexplore.exe -new c:"
You will have it pop up at the main drive C:, and you can now go to town doing all your administrative file tasks like copying, changing perms etc through the explorer interface. You can even do all your contorl panel admin stuff this way by clicking on "My Computer" and then "Control Panel" on the right side pane. Its kinda works like how OSX does its sudo, just in an obscured kinda way.
Try getting your kids' games to run as limited user. Not fun...
Fortunately, they've discovered that web games generally don't require admin rights, so they don't worry about the games they can't play on their account. :-)
thanks for the explanation. I knew that Windows had fine-grained controls. However, actually changing them is complicated. Those are my main gripes with the process.
Btw, all modern Unices have filesystems with ACLs (okay, with the exception of OS X possibly :-). However, I find them cumbersome to use and errorprone. I don't deny that they're useful :-)
just a quick comment: we have implemented something similar to PA (long before we have actually learned about it ..) and we are giving it away for free to home users (hence my positing).
Our solution runs on Windows 2000/XP/2003 .. comments are welcome.
You can grab NeoExec at http://www.neovalens.com