New issue
Advanced search Search tips

Issue 901430 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug



Sign in to add a comment

OSX Users Able to Bypass BrowserSignin/ForceBrowserSignin Policies

Reported by ank...@gmail.com, Nov 2

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
1. Login Chrome using an allowed Google/Gsuite account
2. Once logged in go to People > Add Person
3. This will launch a usable browser with a new local profile, bypassing the required logon.

What is the expected behavior?
With the BrowserSignin policy set to force users to sign in a user should not be able to access the browser until their account has been authenticated.

What went wrong?
We created a policy profile for Mac OSX which enables the ForceBrowserSignin and sets the BrowserSignin policy to force sign in. Users are prevented from using the browser until they successfully login. Once they are logged in they can then go to 'People > Add Person' in the top bar which will launch a new fully functional browser window with a local profile.

Did this work before? N/A 

Chrome version: 70.0.3538.77  Channel: stable
OS Version: OS X 10.14.1
Flash Version:
 
Owner: atwilson@chromium.org
Drew, do we have someone on the team who could take a look at this on OSX?
Cc: pmarko@chromium.org
Cc: kkaluri@chromium.org
Labels: Needs-Feedback
Unable to reproduce the issue on Mac OS(10.12.6) with chrome stable #70.0.3538.77 as per steps mentioned in the comment #0 and observed for 2nd profile also user login window is seen.

Attaching the screen-cast for reference.

ankler@ Could you please look into it and let us know your observations.
901430.mp4
907 KB View Download
Cc: atwilson@chromium.org
Owner: georgesak@chromium.org
Georges, sounds like we need to enforce ForceBrowserSignin on all profiles? What's the desired behavior here?
Cc: georgesak@chromium.org
Owner: zmin@chromium.org
Assigning to zmin@.

Can you navigate to chrome://policy, save to JSON and post the file here? We'll start by double checking that the policy is set to the expected value.

Thanks.
To clarify the problem occurs when you add a new people through the 'People' menu in the top Mac OSX menu bar. The problem doesn't occur with the built-in profile/person manager access from the Chrome menu bar. I've attached a video illustrating the issue. This was recorded on a device running El Capitan (our oldest version of OSX in production here) and Chrome 70.0.3538.77. Note the the recording actually cut off the top menu bar but you can still see the dialog from me clicking on it.
local-policies.json
823 bytes View Download
ChromeBrowserSignin.mp4
2.1 MB View Download
Project Member

Comment 7 by sheriffbot@chromium.org, Nov 5

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Enterprise-Policy
Thank you very much for the detailed feedback, very much appreciated.

This does look like a MAC specific escape that we need to address.

I will let zmin@ chime in as he's the owner of that feature.

We'll update this bug with our findings/progress.
Correction: the preview of it made it seem like the menu bar was cut off but it isn't.

When you go to 'People > Add Person' it launches a browser with a new local profile. You can use that browser normally up until you close out of it where it will then be locked and require a login to use. The policies still apply to the new profile however since the browser window is already open the user can simply disregard them. I've witnessed users use this as a type of guest browser, deleting the newly created local profile between sessions.

Some pretext: We are a Gsuite for Education school district that has transitioned almost entirely to Chrome devices. We have a few Mac and PC labs at some of our schools for certain classes where a Chrome device is insufficient. Recently we've had issues where students would use Chrome extensions to circumvent our internet filter and use a VPN to bully other students. Being forced to login is a great deterrent for our students and any malicious actions are archived in Google Vault. Being able to launch a temporary local session makes it more difficult for us to deal with these issues.
Thanks for the context.

As FYI, you might be interested in our new Chrome Browser Cloud Management which allows you to manage all Chrome instances on Win/Mac/Linux without requiring your users to login.

It's not currently launched, but if you'd like to try it, sign up here and you be part of our early access: https://cloud.google.com/chrome-enterprise/browser-management/
Status: Assigned (was: Unconfirmed)
Labels: -Pri-2 Pri-1
Status: Started (was: Assigned)
Project Member

Comment 14 by bugdroid1@chromium.org, Nov 10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7ec4c624ced67aef832b377d4f5f0aa491200eac

commit 7ec4c624ced67aef832b377d4f5f0aa491200eac
Author: Owen Min <zmin@chromium.org>
Date: Sat Nov 10 02:16:07 2018

profiles::OpenBrowserWindowForProfile respects IsSigninRequired flag.

profiles::OpenBrowserWindowForProfile uses IsSigninRequired flag as a
hack to unblock all extensions during Profile unlocking process.

Remove the hack and add a new parameter to unblock all extensions.
IsSigninRequired needs to be set to false before open the browser window.
If not, UserManager will be shown with selected Profile.

Bug:  901430 
Change-Id: I959dc21daa92f29bca7a279563015b168256762b
Reviewed-on: https://chromium-review.googlesource.com/c/1327236
Commit-Queue: Owen Min <zmin@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607081}
[modify] https://crrev.com/7ec4c624ced67aef832b377d4f5f0aa491200eac/chrome/browser/profiles/profile_window.cc
[modify] https://crrev.com/7ec4c624ced67aef832b377d4f5f0aa491200eac/chrome/browser/profiles/profile_window.h
[modify] https://crrev.com/7ec4c624ced67aef832b377d4f5f0aa491200eac/chrome/browser/profiles/profile_window_browsertest.cc
[modify] https://crrev.com/7ec4c624ced67aef832b377d4f5f0aa491200eac/chrome/browser/ui/webui/signin/inline_login_handler_impl.cc
[modify] https://crrev.com/7ec4c624ced67aef832b377d4f5f0aa491200eac/chrome/browser/ui/webui/signin/signin_create_profile_handler.cc

Project Member

Comment 15 by bugdroid1@chromium.org, Nov 12

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d9dd01f3ab16d77314e1571e9db9d83d025be0b4

commit d9dd01f3ab16d77314e1571e9db9d83d025be0b4
Author: Owen Min <zmin@chromium.org>
Date: Mon Nov 12 16:48:38 2018

Fix flaky profile window browsertest

Fix ProfileWindowBrowserTest.OpenBrowserWindowForProfileWithSigninRequired on Linux
The test is flaky due to race conditionin the test body.

Bug: 904397,  901430 
Change-Id: I80b73f507e3826fc7a707379b89b39a3e7aa68c5
Reviewed-on: https://chromium-review.googlesource.com/c/1330032
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Commit-Queue: Owen Min <zmin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607260}
[modify] https://crrev.com/d9dd01f3ab16d77314e1571e9db9d83d025be0b4/chrome/browser/profiles/profile_window_browsertest.cc

Labels: Merge-Request-71
I have verified the patch on Canary. The two CLs above need to be merged into 71.
Project Member

Comment 17 by sheriffbot@chromium.org, Nov 13

Labels: -Merge-Request-71 Hotlist-Merge-Review Merge-Review-71
This bug requires manual review: M71 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: benmason@(Android), kariahda@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
The patch fixes an issue of ForceBrowserSignin policy that allows user escape the lock. The fix is covered by browser test.
Labels: -Merge-Review-71 Merge-Approved-71
Approving merge to M71 branch 3578 based on comments #16 and #18. Please merge ASAP. Thank you.
Project Member

Comment 20 by bugdroid1@chromium.org, Nov 13

Labels: -merge-approved-71 merge-merged-3578
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2372c6068a6f32491bf48570921b1ea99bd14a8

commit d2372c6068a6f32491bf48570921b1ea99bd14a8
Author: Owen Min <zmin@chromium.org>
Date: Tue Nov 13 19:11:02 2018

Merge profiles::OpenBrowserWindowForProfile respects IsSigninRequired flag.

Merge into M71

profiles::OpenBrowserWindowForProfile uses IsSigninRequired flag as a
hack to unblock all extensions during Profile unlocking process.

Remove the hack and add a new parameter to unblock all extensions.
IsSigninRequired needs to be set to false before open the browser window.
If not, UserManager will be shown with selected Profile.

Bug:  901430 
Change-Id: I959dc21daa92f29bca7a279563015b168256762b
Reviewed-on: https://chromium-review.googlesource.com/c/1327236
Commit-Queue: Owen Min <zmin@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#607081}(cherry picked from commit 7ec4c624ced67aef832b377d4f5f0aa491200eac)
Reviewed-on: https://chromium-review.googlesource.com/c/1334101
Reviewed-by: Owen Min <zmin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#663}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/d2372c6068a6f32491bf48570921b1ea99bd14a8/chrome/browser/profiles/profile_window.cc
[modify] https://crrev.com/d2372c6068a6f32491bf48570921b1ea99bd14a8/chrome/browser/profiles/profile_window.h
[modify] https://crrev.com/d2372c6068a6f32491bf48570921b1ea99bd14a8/chrome/browser/profiles/profile_window_browsertest.cc
[modify] https://crrev.com/d2372c6068a6f32491bf48570921b1ea99bd14a8/chrome/browser/ui/webui/signin/inline_login_handler_impl.cc
[modify] https://crrev.com/d2372c6068a6f32491bf48570921b1ea99bd14a8/chrome/browser/ui/webui/signin/signin_create_profile_handler.cc

Project Member

Comment 21 by bugdroid1@chromium.org, Nov 13

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0def4228ce3203671b17812007a628fe35d0e91c

commit 0def4228ce3203671b17812007a628fe35d0e91c
Author: Owen Min <zmin@chromium.org>
Date: Tue Nov 13 19:11:36 2018

Merge Fix flaky profile window browsertest

Merge into M71

Fix ProfileWindowBrowserTest.OpenBrowserWindowForProfileWithSigninRequired on Linux
The test is flaky due to race conditionin the test body.

Bug: 904397,  901430 
Change-Id: I80b73f507e3826fc7a707379b89b39a3e7aa68c5
Reviewed-on: https://chromium-review.googlesource.com/c/1330032
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Commit-Queue: Owen Min <zmin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#607260}(cherry picked from commit d9dd01f3ab16d77314e1571e9db9d83d025be0b4)
Reviewed-on: https://chromium-review.googlesource.com/c/1334102
Reviewed-by: Owen Min <zmin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#664}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
[modify] https://crrev.com/0def4228ce3203671b17812007a628fe35d0e91c/chrome/browser/profiles/profile_window_browsertest.cc

Labels: Merge-Merged-71-3578
The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/0def4228ce3203671b17812007a628fe35d0e91c

Commit: 0def4228ce3203671b17812007a628fe35d0e91c
Author: zmin@chromium.org
Commiter: zmin@chromium.org
Date: 2018-11-13 19:11:36 +0000 UTC

Merge Fix flaky profile window browsertest

Merge into M71

Fix ProfileWindowBrowserTest.OpenBrowserWindowForProfileWithSigninRequired on Linux
The test is flaky due to race conditionin the test body.

Bug: 904397,  901430 
Change-Id: I80b73f507e3826fc7a707379b89b39a3e7aa68c5
Reviewed-on: https://chromium-review.googlesource.com/c/1330032
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Commit-Queue: Owen Min <zmin@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#607260}(cherry picked from commit d9dd01f3ab16d77314e1571e9db9d83d025be0b4)
Reviewed-on: https://chromium-review.googlesource.com/c/1334102
Reviewed-by: Owen Min <zmin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#664}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
The following revision refers to this bug: 
https://chromium.googlesource.com/chromium/src.git/+/d2372c6068a6f32491bf48570921b1ea99bd14a8

Commit: d2372c6068a6f32491bf48570921b1ea99bd14a8
Author: zmin@chromium.org
Commiter: zmin@chromium.org
Date: 2018-11-13 19:11:02 +0000 UTC

Merge profiles::OpenBrowserWindowForProfile respects IsSigninRequired flag.

Merge into M71

profiles::OpenBrowserWindowForProfile uses IsSigninRequired flag as a
hack to unblock all extensions during Profile unlocking process.

Remove the hack and add a new parameter to unblock all extensions.
IsSigninRequired needs to be set to false before open the browser window.
If not, UserManager will be shown with selected Profile.

Bug:  901430 
Change-Id: I959dc21daa92f29bca7a279563015b168256762b
Reviewed-on: https://chromium-review.googlesource.com/c/1327236
Commit-Queue: Owen Min <zmin@chromium.org>
Reviewed-by: Roger Tawa <rogerta@chromium.org>
Reviewed-by: Mihai Sardarescu <msarda@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#607081}(cherry picked from commit 7ec4c624ced67aef832b377d4f5f0aa491200eac)
Reviewed-on: https://chromium-review.googlesource.com/c/1334101
Reviewed-by: Owen Min <zmin@chromium.org>
Cr-Commit-Position: refs/branch-heads/3578@{#663}
Cr-Branched-From: 4226ddf99103e493d7afb23a4c7902ee496108b6-refs/heads/master@{#599034}
Status: Fixed (was: Started)

Sign in to add a comment