Mike Howard kindly coded up a neat little tool called DropMyRights (follow this
link) that lets us run an application in a "low-privileged" context - i.e. if you logon to your computer with an account that's a member of the local Administrators group, you can run certain apps that you'd like to restrict in a context that is less-privileged than your full logon context.
There has been a raging debate lately about the scenarios in which DropMyRights doesn't work well, and there are two significant ones:
-
using DropMyRights to run Internet Explorer in "C" or "U" mode, and access SSL-protected web sites
-
using DropMyRights to run Internet Explorer in "C" or "U" mode, and access web sites that require SSPI-based user authentication (e.g. NTLM)
In the former case, IE will merely fail to load the page, giving me the famous "Cannot find server or DNS Error" message. So, sick geek that I am, I wanted to know what exactly was being blocked in this context - what was IE being blocked from doing in Constrained or Untrusted mode.
I first fired up Filemon from
www.sysinternals.com, and watched both the successful loading of an example http: web page, and then the failed loading of an https: web page. Turns out there's nothing really interesting at the filesystem level. Well, that's not entirely true - IE failed to open the Temporary Internet Files folder about 200 times, and a few other folders in my profile once or twice, but this occurred whether IE was accessing the SSL'd or non-SSL'd site (in Constrained mode).
Not to be so easily discouraged, I gave Regmon (sysinternals again - those guys…) a try, same scenario. This time, a very interesting set of differences arose:
-
IE failed to CreateKey under HKCU\Software\Microsoft\SystemCertificate\MY [what is IE doing creating new keys related to digital certs? It's not that I think it *shouldn't*, but merely that I don't *get it*.] This occurred only in the IE-browsing-SSL case.
-
IE failed to CreateKey under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. This occurred in both cases.
-
IE failed to SetValue under HKCU\Software\Microsoft\Windows\Explorer\Shell Folders\History. This only occurred in the IE-browsing-SSL case.
To me it's pretty clear that the primary cause of failure is the lack of permissions to write to the MY key in the registry. Makes me want to change the ACL on that key and see what happens, but ACL-muddling in HKCU is a fool's errand - at the very least, it's not a permanent solution.
What's my advice? I've been struggling with this for a few weeks now, hoping some "magic bullet" would come through; at this point however, I think it's best to just continue to heed
Aaron's wise words that he wrote when I first started down this road:
"My experience has been that SSL just does not work when you’re running with a Constrained or Untrusted token, in our current implementation."
I'll see about digging into the root cause on the latter case later on.
