So, after some time off, I tracked this issue again.
The issue is definitely related to IE sandboxing, i.e. PRotected Mode
in some way, but why it cannot access the ADS for reading, I could not
figure still.
I have tried setting the integrity level of the file to Low before IE
accesses it, but didn’t help.
Kind regards, Dejan.
On Tue, Dec 9, 2014 at 1:19 AM, Tony Mason wrote:
>
>
> If it is really a security issue, then my best guess is that it’s a privilege. But the best way to do this is to examine the token - set a breakpoint in the driver (maybe when you see a non-null stream portion of the name for a process called iexplorer.exe) and then dig through the token (“!token” is your friend in WinDBG) - look at the thread to see if it has an impersonation token, otherwise look at the process and examine it’s token (so “!thread” which will either show the token address or “not impersonation” which means no token for the thread and in that case “!process” which always has a token address listed).
>
> Then compare the token where it works from the token where it does not. That will be your candidate list of things that might matter… then you may need to experiment with this by using CreateRestrictedToken (http://msdn.microsoft.com/en-us/library/windows/desktop/aa446583(v=vs.85).aspx) to figure out what it is that causes this to fail.
>
> I’ve never had to research this specific issue, but I must admit, I find that security refusals can be some of the most frustrating issues to resolve and fix - and the techniques Microsoft seems to be sharing with developers (like sandboxing with restricted tokens) to be frustrating to track down and understand at our layer.
>
> Tony
> OSR
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer