Open Bug 1151941 Opened 5 years ago Updated 2 years ago

Windows content sandbox with alternate winstation causes problems for common controls theme support

Categories

(Core :: Security: Process Sandboxing, defect)

All
Windows 8.1
defect
Not set

Tracking

()

People

(Reporter: bent.mozilla, Unassigned)

References

(Depends on 1 open bug)

Details

(Whiteboard: sb+)

Attachments

(2 files)

Attached image screenshot-low.jpg
See screenshots.
This is an x64 nightly build, on windows 8.1.
And I don't see anything in the browser console log that looks relevant.
Looks like this was caused by the previous stronger policy that level 1 represented.

Not sure which of those previous settings caused the problem, so I'll just change this to block the main content sandbox tightening bug for now.
Blocks: 1105816
No longer depends on: 1151767
Looks like this is down to using an alternate desktop.
Summary: Low-integrity processes lose common controls theme support → Windows content sandbox with alternate desktop causes problems for common controls theme support
Hi Gijs, do you have any idea where this styling change gets implemented?

I'm struggling to find out why using an alternate desktop is blocking this.

Not sure if this is your area, but IIRC you were doing some styling stuff for Windows 10.
Flags: needinfo?(gijskruitbosch+bugs)
That looks like widget level code to me... nsNativeTheme and moz-appearance implementations and all that jazz. Jim Mathies would know more than me if you need more details than that.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jmathies)
Looks like it's not a failure on individual widgets, more of a general failure. So the cause is going to be somewhere in here:

http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsNativeThemeWin.cpp#2592

Might be that pres shell variable set up, or more likely it's in the GetTheme code - 

http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsUXThemeData.cpp#66

Maybe HWND shouldn't be null here? The docs don't say this is acceptable, but clearly it's working generally. Throw in virtual desktops and who knows.
Flags: needinfo?(jmathies)
This only appears to be a problem when we use an alternate winstation as well as desktop.

So we should be able to land the alternate desktop on Nightly.
I'll leave this bug for looking into using an alternate winstation.
Summary: Windows content sandbox with alternate desktop causes problems for common controls theme support → Windows content sandbox with alternate winstation causes problems for common controls theme support
What is the value in the alternate window station? Does it provide a security boundary? Is there anything that stops a thread from doing SetProcessWindowStation(OpenWindowStation("Winsta0", FALSE, WINSTA_ALL_ACCESS)) ?

If there isn't, I'd say that the point is moot.
Whiteboard: sb+
The list of "access rights" from https://msdn.microsoft.com/en-us/library/windows/desktop/ms687391(v=vs.85).aspx seems to basically describe the security boundary winstations enforce.
(In reply to Alex Gaynor [:Alex_Gaynor] from comment #11)
> The list of "access rights" from
> https://msdn.microsoft.com/en-us/library/windows/desktop/ms687391(v=vs.85).
> aspx seems to basically describe the security boundary winstations enforce.

Those are for access rights generally to do things to/with a particular Windows Station (or Windows Station owner) I think, not necessarily what running in that winstation provides.

I think the theming is probably broken because the alternate Windows Station is necessarily a non-interactive one.
It looks like the primary resources a WinStation has are a clipboard, and an atom table (not sure what this is tbh).
You need to log in before you can comment on or make changes to this bug.