User:Dolske/NewSecurityModel

The Problem

• Monolithic model
  • chrome gets all, web content gets nothing
  • no limitations on XPCOM usage (once you can get it)
  • (a few special cases for web content, like signed JS)
  • (remote XUL/XBL limitations?)
• Similarity to historical Unix security
  • root can do everything
  • too many people with root access
• Rise in popularity of extensions/themes can (will?) become an attack vector
  • false sense of security (extn's / FF is "safe")
  • little oversight of AMO approved code
• Defense in depth
  • reduce seriousness of security flaws from browser JS code (?)
  • reduce seriousness of security flaws from 3rd party code
    • XPCNativeWrapper

A Solution

• least priv / capabilities
• Unix parallels?
  • TSol RBAC
  • linux security thing like RH(?) had enabled
• Unix differences
  • giving limited priv to a user == easy
  • taking away rights from a traditionally-root role == hard
  • limiting rights in our chrome model == probably really hard
  • not really a clear user/role/process model in browser.
  • instead, looking at particular files/functions containing code
  • we have a UI to worry about
• strawman architecture?

Other Benefits

• a way to improve web apps by giving them limited access to platform?

Challenges

• avoiding escalation of privs
  • we're somewhat bolting security onto an existing model
  • examples? (like using an API in unintended ways)
• being meaningful to the user
  • Vista teaching people to just click ok?
  • lazy developers who just request every priv
  • use as a way for AMO reviewers to rate security of extn?
• backend support (JS engine and XPCOM layer, FF4 plans)
• performance
• what are the right set of privs to use (see also granularity)

References

1. Overview of signed JS code
2. More details on signed JS code
3. Configurable security policies using CAPS
4. Same-origin policy