Security/Reviews/MobileJavaAddOns

From MozillaWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
Please use "Edit with form" above to edit this page.

Item Reviewed

Mobile-APIs for Java Code in Addons
Target
   
     Full Query    
   
ID Summary Priority Status
805436 SecReview: Mobile - support / provide APIs for Java Code in Addons -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

blog post by kats: https://staktrace.com/spout/entry.php?id=778

{{#set:SecReview name=Mobile-APIs for Java Code in Addons

|SecReview target=

Full Query
ID Summary Priority Status
805436 SecReview: Mobile - support / provide APIs for Java Code in Addons -- RESOLVED

1 Total; 0 Open (0%); 1 Resolved (100%); 0 Verified (0%);

blog post by kats: https://staktrace.com/spout/entry.php?id=778 }}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

What solutions/approaches were considered other than the proposed solution?

  • no Java, thus no add-ons
  • How about creating APIs for other processes to interact with fennec?
    • No advantage in this over JS only and more work
    • Except that you can use the android perm. model to restrict things even more

Why was this solution chosen?

  • parity with desktop
    • is jetpack/SDK/FUEL type APIs an option?

Why was this solution chosen?

`

Any security threats already considered in the design and why?

`

Threat Brainstorming

  • Do we really want parity with desktop? Currently all sorts of bad things happen on desktop that we neatly sidestep due to the restrictions of fennec.
    • This could potentially mean that we provide a route for malware that's not there currently - (chrome XSS == any API access that we've requested)
  • Bypass security for things like camera access where Java code can silently open the camera while JS code will have to use getUserMedia and will have to go through a dialog for user approval
  • Possibility to download remote code to local filesystem and execute it
  • Have we thought about how this might impact on review procedures for addons?
    • We wouldn't be able to review binary only-stuff

{{#set: SecReview feature goal=* Allow addons to run Java code on native Fennec

|SecReview alt solutions=* no Java, thus no add-ons

  • How about creating APIs for other processes to interact with fennec?
    • No advantage in this over JS only and more work
    • Except that you can use the android perm. model to restrict things even more

Why was this solution chosen?

  • parity with desktop
    • is jetpack/SDK/FUEL type APIs an option?

|SecReview solution chosen=' |SecReview threats considered=' |SecReview threat brainstorming=* Do we really want parity with desktop? Currently all sorts of bad things happen on desktop that we neatly sidestep due to the restrictions of fennec.

    • This could potentially mean that we provide a route for malware that's not there currently - (chrome XSS == any API access that we've requested)
  • Bypass security for things like camera access where Java code can silently open the camera while JS code will have to use getUserMedia and will have to go through a dialog for user approval
  • Possibility to download remote code to local filesystem and execute it
  • Have we thought about how this might impact on review procedures for addons?
    • We wouldn't be able to review binary only-stuff

}}

Action Items

Action Item Status None
Release Target `
Action Items
'

{{#set:|SecReview action item status=None

|Feature version=` |SecReview action items=` }} Related to CTypes JNI - Which still needs review (Wes) Product has not made a decision about this feature explicitely