Browsing the Web and Reading E-mail Safely as an Administrator, Part 2


In November 2004 I posted an article to MSDN entitled, “Browsing the Web and Reading E-mail Safely as an Administrator“. The amount of positive commentary and feedback was staggering, which made me write the follow-up to this article a little faster than I had anticipated!

Browsing the Web and Reading E-mail Safely as an Administrator, Part 2” goes one step further and outlines how you can use policy, rather than API calls, to force and application to run as a user, even if you are logged on as an admin. For example, you could mark you fave browser to always run as a user, regardless of whether it starts by invoking an URL on the desktop, a link in email, a newly spawned browser and so on.

Comments welcome. And thanks to all those who provided feedback on DropMyRights.

Comments (23)

  1. Hi Michael,

    Will this run as user will prevent to a hostile program to write a shortcut in the startup of the current user, and adquiere Admin rights in the next logon?

  2. I also think this is an interesting approach of using the group policy objects to apply limited rights to an application you do not wish to implicity trust.

    <a href=“http://www.easyrecorder.com”target=“_blank”> sound recorder </a>

  3. Michael Howard has released an interesting article on using "Software Restriction Policies" to browse the web and read email safely as an Administrator. I wouldn’t recommend this, as I am a serious believer in using least privilege and using runas to elevate privileges as needed (hey, even Michael admits and recommends that). However, if you have to, this is an interesting approach of using the group policy objects to apply limited rights to an application you do not wish to implicity trust. Anyways, good read. Enjoy!…

  4. Kevin R says:

    Michael:

    This is a great article, and very helpful indeed. However, during my initial tries at this, it appear the software restriction policy only applies to new process, and not existing ones. E.g. after I run gpupdate I have to start a new command prompt (or presumably log out/log back in) to see the restriction taking effect.

    Is that expected behavior?

  5. Mike Kolitz says:

    Michael,

    You mention that SAFER will change between now and Longhorn – I don’t suppose there are any details that you can release about that. As someone who is primarily working on implementing SAFER at a corporation right now, I’d be curious to find out whether the work I’m putting in is worth while if I’ll have to re-implement everything later on.

  6. Hofi says:

    Thank you for your publications, I’ve learned a lot from them! I’m also interesting in that what will be the feature of SAFER in Longhorn.

    Everybody who like Michael’s elegant security solutions might have worth to take a look at here:

    https://sourceforge.net/projects/runasadmin/

    and here

    http://hofi.fw.hu/NavFromOutside.html

    Thank you once again!

  7. Al says:

    I added the "levels" registry entry and now see the "Basic User" in Group Policy. So far, working great. (I used it to get a non-Microsoft service privileges reduced. For some reason, only services running as SYSTEM can interact with the desktop.) I would be interested in registry entries that would expose the "Constrained" and the "Untrusted" entries as choices in Group Policy.

  8. It is expected behavior that changing SAFER policies will not affect processes already running. It is not very practical to replace security tokens throughout a process already running unfortunately.

    After making changes to SAFER rules, they will only impact new processes launched from another new process. This is due to the policy caching done within each process.

    For example, Explorer will continue to apply the previously cached ruleset, but if you launch CMD.EXE from Explorer and then try to launch a new process from that command-prompt, the updated ruleset will now be enforced against the new process.

    You can also try using Task Manager to kill your Explorer.exe process, and then relaunch it.

    A full logout/login is probably recommended for full testing purposes.

  9. Karan Mavai says:

    Hi Michael,

    Thanks for the great info both here and on the DropMyRights article.

    I tried running your SetSAFER utility with beta 1 of .Net 2.0 redistributable, but it seems this version of .Net is older. Your app requires 2.0.40903 and beta 1 available off the link in your article is 2.0.40607. I can download the full December CTP from MSDN, but wanted to avoid installing the SDK if at all possible.

    Is there a newer version of the redistributable .net framework available elsewhere?

  10. Al says:

    FYI: I have noticed that an executable marked to run as a "Basic User" won’t start when it is the target of a runas command. (No serious negative impact for me.)

  11. Mark Dormer says:

    I have added the other levels on my blog.

    Oh I may as well put here too.

    Values

    0x10000 – Constrained (also named Restricted)

    0x20000 – Normal User (also named Basic User)

    0x01000 – Untrusted

    0x31000 – to get all 3

  12. Keith Brown says:

    http://pluralsight.com/blogs/keith/archive/2005/01/25/5448.aspx

    I followed up a bit on these articles with respect to luring attacks. I would love to know how SAFER prevents these, because otherwise, I am afraid this might be giving people a false sense of security.

    And are these levels now documented? They certainly aren’t listed in the Platform SDK documentation for SaferCreateLevel, and I had assumed this was due to the presence of luring vulnerabilities:

    http://msdn.microsoft.com/library/en-us/secmgmt/security/safercreatelevel.asp

    I agree with Dana – Mike’s first paragraph about running as non-admin is the best possible advice you can follow.

  13. Keith Brown says:

    Heh, I notice that after I made this post last night, the documentation for SaferCreateLevel has now been updated to include these new levels:

    http://msdn.microsoft.com/library/en-us/secmgmt/security/safercreatelevel.asp

    Is it a coincidence? <grin>

    Anyway, I’m still interested in the problem of luring attacks. It’d be nice to warn people about these so they don’t get a false sense of security.

  14. Michael Howard says:

    The updated MSDN/Platform SDK docs going live last night with the new info is total coincidence! I was reviewing the final updated docs a week ago, and it finally got push to MSDN!

    As for luring attacks, SAFER doesn’t help prevent these kinds of attack at all. But it may mitigate the damage!

  15. Keith Brown says:

    Thanks for confirming my belief about luring attacks. Will you get the documentation guys to add that warning to the docs?

    Seems like a prudent thing to do.

  16. Mark Dormer says:

    I was only kidding <g>