This issue likely requires triage. The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days). Thanks for helping out!
-Anthony
Hello, I'd like to merge c91e967e98ace8db59aa9c29b0949603caa51050 to M-49. This would allow us to run the win32k lockdown study on a larger population. The functional part of the code has landed, this is just the ability for us to finch it. Thanks.
Please merge your change to M49 (branch: 2623) before 5:00 PM PST Tuesday [02/02/16], If you would like to make it to next week M49 Beta push on Wednesday [02/03/16].
I'm finding the the behavior/logic with the command line flags for this to be
backwards and potentially dangerous considering the security implications of
using this option.
What I'm referring to is the interaction of field trials combined with the
command line flag to enable this option. I'm not sure why but what's specified
in field trials seems to override the command line flag (set from the command
line or through chrome://flags since they're both the same thing essentially).
So what you wind up with when you enable it through chrome://flags or on the
command line with the follow:
--enable-win32k-lockdown-mimetypes=*
Is that it's not actually doing anything which says to me that the logic behind
this flag is broken. If I'm specifying it on the command line I actually expect
it to override any random field trails and actually enable the option which is
the ONLY way to reduce the kernel attack surface on Windows.
Instead to actually enable it you need something like this:
--force-fieldtrials="EnableWin32kLockDownMimeTypes/Default" ^
--enable-win32k-lockdown-mimetypes=*
For me the field trial defaulted to being enabled and the option was set to
something with Flash in the name but it still wasn't actually enabled for Flash
so I'm not sure what it was doing it that case.
I just find this logic to be backwards and I'm sort of thinking this may
actually be a bug in how the logic is being handled. I wonder if this[1] commit
had anything to do with it or if the logic was broken even before that.
[1] https://chromium.googlesource.com/chromium/src.git/+/c91e967e98ace8db59aa9c2[9b0949603caa51050
Win32k lockdown for ppapi plugin is an experimental feature, this is why it's behind a flag. Once it's ready for prime time then it will be gradually enabled across all channels for all users.
Having the field trial control the parameters of lockdown allows us to measure accurately the stability of the feature, and this was a deliberate design decision.
> Having the field trial control the parameters of lockdown allows us to measure accurately the stability of the feature, and this was a deliberate design decision.
Ok well I still think it's counter intuitive since there's a "Default" setting but I accept.
> Restrict PPAPI Win32k lockdown to Win10 and above.
It would be helpful if someone somewhere explained why (like in the commit message).
> This patch restricts enabling Win32k lockdown for PPAPI processes to Windows 10 and above.
This is just saying the same thing twice. IMO it should instead tell me why that choice was made (e.g. doesn't work, security considerations, etc).