Closed Bug 1175627 Opened 9 years ago Closed 8 years ago

[FindMyDevice][Kill Switch]When the user enables "Kill-Switch" mode, the device should be inoperable

Categories

(Firefox OS Graveyard :: FindMyDevice, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: vkrishnamoorthy, Unassigned)

References

Details

An unauthorized user shall not be able to access the functions of, or data when the device is in "Kill-Switch" mode.

Additionally, the unauthorized user should not be able to access the device via USB or flash the device.


Note: the basic premise here is that if the device is not operable, the device does not have value and is no longer worth stealing
We need a precise list of what is to be blocked. Specifically, Gecko may not be able to do a lot of things. I think we can safely do:
 - adb blocking, since we already have a way to do so
 - UMS/MTP disabled
 - maybe somehow setup something for recovery to be blocked
Flags: needinfo?(vkrishnamoorthy)
Group: mozilla-employee-confidential, core-security
Flags: needinfo?(vkrishnamoorthy)
Moving this bug to Moz only for now.

Could we add the following to the list in Comment 1? We can go over each feature in the list and evaluate if it is an MVP candidate for first release
- disable developer Menu
- Disable "Reset Phone" 
- Power cycle or removing battery should not disable kill switch or FxA (this is already supported, adding it for completeness)
- Prevent changes to Wifi and Geolocation setting (In the "the kill switch mode" one should not be able to disable Wifi and geolocation as this is required by the service to locate the device)
- Disable Fastboot (OEM requirement)

Optional (depending on our analysis and ability to support)
- Prevent access to bootloader.
(In reply to vkrishnamoorthy@mozilla.com [:Vishy] from comment #2)
> Moving this bug to Moz only for now.
> 
> Could we add the following to the list in Comment 1? We can go over each
> feature in the list and evaluate if it is an MVP candidate for first release
> - disable developer Menu
> - Disable "Reset Phone" 

Does it make sense to list those ? Device is supposed to be locked, with no UMS/USB/ADB access.

> - Power cycle or removing battery should not disable kill switch or FxA
> (this is already supported, adding it for completeness)

Storing as a pref, setting or property should make sure of this.

> - Prevent changes to Wifi and Geolocation setting (In the "the kill switch
> mode" one should not be able to disable Wifi and geolocation as this is
> required by the service to locate the device)

If we consider the device is locked, and that ADB is blocked, there's no way this can happen. Except maybe in power saving mode ? So Kill switch should disable power saving ?

Should it also enforce WiFi and data connectivity ?

> - Disable Fastboot (OEM requirement)

Fastboot is disabled by default on production devices. Does it means it need to be re-disable it if it was enabled ?

> 
> Optional (depending on our analysis and ability to support)
> - Prevent access to bootloader.

Up to the OEM.

This is mixing parts which we can do and parts which we cannot do. Specifically, we need to know how Gaia/Gecko can communicate with very low-level parts to make sure the device stays locked.
Flags: needinfo?(vkrishnamoorthy)
(In reply to Alexandre LISSY :gerard-majax from comment #3)
> (In reply to vkrishnamoorthy@mozilla.com [:Vishy] from comment #2)
> > Moving this bug to Moz only for now.
> > 
> > Could we add the following to the list in Comment 1? We can go over each
> > feature in the list and evaluate if it is an MVP candidate for first release
> > - disable developer Menu
> > - Disable "Reset Phone" 
> 
> Does it make sense to list those ? Device is supposed to be locked, with no
> UMS/USB/ADB access.
when you mean device is locked, is it the lockscreen with FxA password?

> 
> > - Power cycle or removing battery should not disable kill switch or FxA
> > (this is already supported, adding it for completeness)
> 
> Storing as a pref, setting or property should make sure of this.

ok, I think fabrice introduced a flag for FMD that was not reset during power cycle, not sure.

> 
> > - Prevent changes to Wifi and Geolocation setting (In the "the kill switch
> > mode" one should not be able to disable Wifi and geolocation as this is
> > required by the service to locate the device)
> 
> If we consider the device is locked, and that ADB is blocked, there's no way
> this can happen. Except maybe in power saving mode ? So Kill switch should
> disable power saving ?

> Should it also enforce WiFi and data connectivity ?
Yes. Or can we just enable Wifi and geolocation in the power saving mode as an exception in kill-switch mode?

> 
> > - Disable Fastboot (OEM requirement)
> 
> Fastboot is disabled by default on production devices. Does it means it need
> to be re-disable it if it was enabled ?

This is more an OEM requirement and for our QA to test.

> 
> > 
> > Optional (depending on our analysis and ability to support)
> > - Prevent access to bootloader.
> 
> Up to the OEM.
I put it in here for completeness 
> 
> This is mixing parts which we can do and parts which we cannot do.
> Specifically, we need to know how Gaia/Gecko can communicate with very
> low-level parts to make sure the device stays locked.
Who can help here to get that information? gonk team or do we need someone from OEM?
Flags: needinfo?(vkrishnamoorthy)
Paul, could you assign a rating to this? Thanks.
Flags: needinfo?(ptheriault)
(In reply to Andrew McCreight [:mccr8] from comment #5)
> Paul, could you assign a rating to this? Thanks.

Hmm why is this a security bug - this is a feature that is still being developed. _maybe_ this needs to be partner confidential, but considering this is meeting a publicly known legal requirement, I dont see why this needs to be confidential.

Actually based on comment 2, I think you meant only to use moco only, not core-security as well, so I'm removing it. I'd still really like to know why this isnt public.
Group: core-security
Flags: needinfo?(vkrishnamoorthy)
Flags: needinfo?(ptheriault)
Group: mozilla-employee-confidential
Flags: needinfo?(vkrishnamoorthy)
Is this covered by bug 1175623?
Just want to clarify the scope.
feature-b2g: --- → 2.2r+
Flags: needinfo?(mtreese)
Flags: needinfo?(mtreese)
KS 2.6 requirement
blocking-b2g: --- → 2.6+
feature-b2g: 2.2r+ → 2.6+
blocking-b2g: 2.6+ → ---
feature-b2g: 2.6+ → ---
Because of bug 1270158.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.