#CBC-RS/TC-watchlist

+stevenjb

Sounds reasonable to me.

+cernekee@ since this would require a Shill change.

+derat@ in case Shill doesn't already know when the screen is locked; if not I'm not sure if it would be best/easiest for Chrome to inform Shill or for Shill to observe the screen lock state directly.

Makes sense to me.

session_manager already emits D-Bus signals about this that it'd be easy for shill to listen to. From https://chromium.googlesource.com/chromiumos/platform2/+/master/login_manager/README.md:

"... Once Chrome has successfully displayed the lock screen, it calls session_manager's HandleLockScreenShown D-Bus method. session_manager then emits a ScreenIsLocked D-Bus signal.

After the user successfully types their password to unlock the screen, Chrome calls session_manager's HandleLockScreenDismissed D-Bus method. session_manager updates its internal state to record that the screen is no longer locked and emits a ScreenIsUnlocked D-Bus signal."

> currently, we do not allow people to change WiFi settings while the screen is locked.  so why do we allow USB ethernet dongles to show up and reconfigure the network ?

I'm not sure I see the contradiction here.  When the screen is locked, shill will try to connect to the best available network (per configuration and policy).  For instance, if a locked Chromebook is connected to my local AP, and then I flip the power switch on my AP, the Chromebook will perform a wifi scan and roam over to GoogleGuest instead because it is the next best option.  An attacker can often influence this choice because it is easy to deauth wifi clients, or advertise fake SSIDs.

Letting the operator change wifi settings while the screen is locked means they can reconfigure the network preference order.  It's good that we don't allow this.  Also, we do allow enterprise administrators to disable all ethernet connections through CPanel.

Users who mostly rely on wired connectivity (maybe Chromebox users?) could be adversely impacted by the proposed change.  Or if you lock your screen, then dock your Chromebook, then go home for the day, everything may stop syncing: update_engine, email tabs, Hangouts, etc.  Then when you log in 16 hours later, it could take a few minutes to catch up.

Given that Chrome OS does not trust the network anyway, is there a major security benefit to this?

[drive-by comment]
I think this is more in line with the restriction on cros-disks to keep it from mounting a new filesystem while the screen is locked.  There's no reason to add a network device while the screen is locked (offline auth, etc) and plugging in a new device brings new privileged bugs. Shill ignoring it makes sense from that perspective.

Beyond that, it'd be even nicer if we could stop all USB enumeration _except_ HID device changes while the screen is locked.

(Bulk Edit) Adding the new conops Chrome OS hotlist to all open issues with the "#CBC-RS/TC-watchlist" tag, our former tracking tag.