Low-privileged accounts and non-Windows platforms

Low-privileged accounts and non-Windows platforms

  • Comments 11

Those of you who’ve read my old blog for any length of time know that one of my particular areas of interest is trying to convince people to stop running their machines on a day-to-day basis using Administrator-level accounts, given that this opens them up to greater risk for their machine being exploited by malicious code.

I’m considering an experiment, in which I will set my wife up to use a non-Windows platform as a non-administrative user, and see how she does in using that platform without my intervention, including installing software, configuring simple settings, etc. What I’d love to get from my readers is recommendations on which platforms handle this best, that is, setting a user up to be low-privileged, but allow for easy software installs, etc. The purpose of the experiment is to understand how this process is handled on competitive platforms, so I can better evaluate how we do it on Windows.

I’d also be interested in hearing what your biggest points of pain are when trying to run as a non-Admin in Windows. Some of mine include software that doesn’t run correctly when installed by an admin, but run by a non-admin, and profile information that gets stored in the wrong place. Most of these issues, by the way, can be solved by the very useful MakeMeAdmin utility written by my colleague Aaron Margosis. Of course, I’d love to see this baked into the platform, so that things are simpler and more reliable, but at least the tool’s available.

So the two questions are:

  1. Which non-Windows platform best handles (for non-technical users) running with low privileges generally while providing the ability to easily elevate privileges when necessary for installs or configuration?
  2. What are your points of pain when running as a non-admin user on Windows (and what are your favorite workarounds)?

Note that I will probably try at least one Mac-based solution and one *nix-based (perhaps on Virtual PC), so recommendations should take that into account. Note also that I’m already familiar with the su concept in *nix, so I’m not looking for any treatises on that…just recommendations of who handles this best for non-technical users.

  • I use the Windows time settings as a calendar. I'm sure others do too. When I run as a user I get a message informing me that I dont have privs to access. I think a read-only state would be good, in addition maybe allow NTP sync even for non-admin users? Maybe I should checked the policy options before I posted this
  • One thing I'm impressed by is the configuration utility in KDE - When a non admin visits a tab that is editable only by administrators, you can read the tab, but the controls are disabled. At the bottom of the tab page is a button you can press which prompts you from admin credentials.

    After you've elevated your credentials, the current page is bordered in a very thick red line, indicating that control in the app is running as root. After you make your changes, if you leave the tab the control is unloaded and when you return, you see the grey disabled screen again and need to reauthenticate.

    When KDE apps partially elevate their permissions, they maintain the configuration options of the account that started the app, so a user does not lose his or her preferred settings when they need to perform work outside the scope of their normal user account
  • OS X, and it doesn't really matter from a *nix point of view, since they're more or less all the same, from a user perspective. Whatever you can get to run on your hardware. I'd suggest FreeBSD over Linux because BSD is better tested (the uncharitable part of me says 'i.e. it's tested').

    Points of pain - er, everything ;-) but mainly trying to raise privilege to use Control Panel. If the applets had Run As on their context menus, that would be great, but they don't. The runas command should try to use ShellExecute rather than CreateProcess (OK, it uses CreateProcessWithLogonW) so I don't have to do e.g. runas /user:administrator "cmd /k \"start compmgmt.msc\"" - I've got used to pressing Win+R to get the Run dialog and typing the name of a saved MMC console file, rather than going to Start > Programs > Administrative Tools (I use the classic Start menu on XP with Admin Tools shown as a Programs group). There are some consoles such as Group Policy Editor (gpedit.msc) which don't appear in the Admin Tools group.

    I had a weird issue on Thursday when trying to debug a VB6 ActiveX DLL where both VB6.exe and the client process were run from a cmd window launched from makemeadmin (via shortcuts dropped onto the window) - it seemed as though the client couldn't create an instance of the object. I can't reproduce the problem now!

    As a limited user, I'm disappointed that I can't select which file types I want to open with what program. The Set Program Access and Defaults screen simply reports 'You do not have permission to set program access and defaults'. The administrator should be able to set which programs are visible, yes, but if the user is allowed to see more than one program, he should be allowed to set which one he uses.

    I had a lot of trouble running some old DOS games yesterday (I got really into the Formula 1 coverage at Spa and pulled out my old copy of Geoff Crammond's Grand Prix 2) as a limited user. This was mainly due to the need to use VDMSound (ntvdm.cjb.net) to get SoundBlaster 16 compatibility; Windows' built-in Virtual DOS Machine environment has poor sound capability. Virtual PC sound can be a bit choppy.

    On Friday I noticed a couple of issues with Pocket PC device debugging, which I wrote up at http://channel9.msdn.com/ShowPost.aspx?PostID=19404#19404. I haven't yet fixed the issues with eVC 4.0 at work; again, it doesn't do it at home, but then I installed eVC using this user account at home, my account owns the directory and Creator Owner has full control. This is a little bit of a hole - I guess I'm going to have to go through as the administrator and take ownership of a lot of resources this account should be restricted on. I've noticed that on Server 2003, an administrator can set the owner of an object to be any arbitrary user; on XP an administrator can only set the owner to be himself or the Administrators alias.
  • 1. So far MacOS X is the only one I used that does privilege evelation when necessary: it popups a dialog to login as administrator when a normal user starts a setup or trys to change system settings.

    2. The applications that expect the user to be an administrator: require write access for the program files directory, write access for the HKLM\HKCR branches and friends which I usually come by with giving the user group the access rights for the necessary files and keys. Interestingly I've never experience configurations being stored in wrong places (well, apart from the application folder in program files). The only thing I could not get to work was the Bluetooth stack tools - though I did not bother much about it anyway as it seemed to leak GDI handles... For installations I used to do them with fast user switching but now it is a mix of switching and MakeMeAdmin.cmd. So far, this works quite nice - I'm a normal user for one month now :)
  • I have said/posted in other places:

    the first thing is for MS developers to run as non-admins. and make it SOP for MS to run all installs as "non-admin"
    then make the windows app cert require non-admin install as a test.

    then MS can tell us regular joe's how to develop as a non-admin.
  • As I posted in my blog a while ago there needs to be an "Install As" for MSI files. Currently its kind of messy like "runas /u:dadada msiexec mymsi.msi" so I can't have other people trying to do that. Also as a couple of people alluded to earlier the control panel applets.

    Fast User switching for domains. This pains me to no end.

    For Runas there needs to be an option to run it with /noprofile when you right click on a file.

    Something which I have been thinking about for the last couple of days is setting up a wiki or something like it to collect links, tools, and tips for running as a non admin. It is real uphill battle for me to convince other people to run as non admin because running as admin is so easy to do.

    Steve
  • My bigest anoyance:
    Bad error messages & silent failures. Example, installing a new font gives the message "file is in use".

    My favorite workaround:
    Create a shortcut to whatever, and set the shortcut to always run as different user.

    I didn't know about MakeMeAdmin until today. But it sounds like a really bad idea to me. Now the "hacker" just needs to find some setting in a user's profile which allows for code injection into the process you are launching. Maybe a logon script? Maybe SetWindowsHook? Maybe explorer runs plugins registered in HKCU? Heck, even HKCR has everything from HKCU\software\Classes merged into it. This is also why RunAs SHOULD NOT call ShellExec, IMHO.


    Dane - Yes, it is a Security Policy setting: User Rights->Change System Time. Excessive, yes. But I like to double-click to get the calendar too. :-)
  • Mike: Regarding the Control Panel and applets having Run As on their context menu. They don't by default but hold Left Shift and then bring up the context menu.

    This works on a number of areas where Run As isn't normally found. There are a few places where you will NEVER see Run As, namely Internet Explorer and a couple of other goodies on the Desktop. I suppose someone should probably make a list of which applications do or do not have Run As and which ones benefit from the Left Shift trick but who has all of that time? I would love if they just included Run As in every context menu but there's apparently a reason why it's not.
  • Mike Dimmick and others: See my "RunAs basic (and intermediate) topics" blog post re RunAs with Control Panel. (Also sort of addressed .msi).

    b.gr: Windows will also prompt for admin credentials if a non-admin runs a setup.exe or install.exe. (Possibly others...?)

    RJ: The problem exposed by MakeMeAdmin is really no greater than that of using RunAs at all - you have an elevated security context running within the same security boundary of the user's (Win32) desktop. An unprivileged app could potentially cause the privileged app to perform operations on its behalf. (Fast User Switching, if available, is probably the most secure way to have multiple simultaneous security contexts.)

    Jeremy Brayton: IE in the Quick Launch bar has RunAs in its context menu.

    LOTS more tips/tricks/workarounds/etc for non-admins in my blog...
  • > Windows will also prompt for admin credentials if a non-admin runs a setup.exe or install.exe. (Possibly others...?)

    Not on XP. The 3 setups I just tested popup an error message only. Guess I need to enable the elevate Windows Installer credentials policy (or whatever that one is called) but that won't cover non Windows Installer based setups...
  • b.gr:

    I think the confusion may be that older setup and MSI files don't prompt for admin credentials. Setup programs that use the latest version of Microsoft Installer technology should, AFAIK.

Page 1 of 1 (11 items)