1303325 - Network Drive file:// URLs not accessible with USER_NON_ADMIN token after chromium update

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, defect)

Description

[Bob Owen (:bobowen)]

The details of the original problem with USER_NON_ADMIN after the chromium update can be seen in bug 1287426 comment 11 and onwards.

The work-around that I landed in patch part 8 of that bug, causes a problem because all restricted tokens appear to lose access to network drives, so file:// URLs are no longer accessible with USER_NON_ADMIN.

However, I think I've finally worked out that it is this change that is causing the problem:
https://hg.mozilla.org/mozilla-central/diff/a46f0e32289b/security/sandbox/chromium/sandbox/win/src/policy_target.cc

It seems that there is quite a lot of blocking that goes on during start-up and in the CoInitializeSecurity call.
But with this reverted, the internal ResumeImpersonate call succeeds and we're not left with an Anonymous Impersonation token.

This change was part of a change to the chromium code for the LowBox token, which we don't currently use:
https://codereview.chromium.org/937353002

So, I think we can safely revert this for the moment, although we may well want to look into calling LowerToken before CoInitializeSecurity or some other way of not blocking these things in certain circumstances.

Comment 1

[Bob Owen (:bobowen)]

Attachment: Bug 1303325: Revert changes to policy_target.cc that cause issue with CoInitializeSecurity.

This also reverts the Bug 1287426 Part 8 patch that turned the USER_NON_ADMIN loken into a restricted token.

Review commit: https://reviewboard.mozilla.org/r/79232/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/79232/

Comment 2

[(No longer employed by Mozilla) Aaron Klotz]

That removed code is really strange! It looks like the only purpose of that code is to validate the function call as a legit ThreadImpersonationToken call and forward anything that doesn't look normal to the real API.

If I am interpreting this correctly, presumably something passes in data to a ThreadImpersonationToken call that is somehow different from Chromium's expected input. Previously the call was forwarded, whereas now all input to that call is being unconditionally blocked.

Comment 3

[(No longer employed by Mozilla) Aaron Klotz]

Comment on attachment 8791960 [details]
Bug 1303325: Revert changes to policy_target.cc that cause issue with CoInitializeSecurity.

https://reviewboard.mozilla.org/r/79232/#review77826

LGTM as long as all the tokens look OK at runtime!

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f4be1a7f9b3e
Revert changes to policy_target.cc that cause issue with CoInitializeSecurity. r=aklotz

Comment 5

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/f4be1a7f9b3e