User talk:Comrade693/SQLite 3.6.4 Security Review

From MozillaWiki
Jump to: navigation, search

Overview

Upgrading SQLite so we can get the perf and stability improvements they've had since April.

Background links

Security and Privacy

  • What security issues do you address in your project?
    • none that I am aware of
  • Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
    • no
  • Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

Exported APIs

  • Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
  • Does it interoperate with a web service? How will it do so?
    • No
  • Explain the significant file formats, names, syntax, and semantics.
  • Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
    • No - they should use mozStorage APIs
  • Does it change any existing interfaces?
    • No

Module interactions

  • What other modules are used (REQUIRES in the makefile, interfaces)
    • none

Data

  • What data is read or parsed by this feature
    • SQLite database files
  • What is the output of this feature
    • SQLite database files
  • What storage formats are used
    • SQLite's internal storage format

Reliability

  • What failure modes or decision points are presented to the user?
    • There are none in this code; consumer specific
  • Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
    • Yes, if you turn off synchronous behavior which ensures that files cannot be corrupted by a crash.
    • Yes, locks and files added are cleaned up after a crash

Configuration

  • Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
    • yes - they can change how fsyncs with toolkit.storage.synchronous
  • Are there build options for developers? [#ifdefs, ac_add_options, etc.]
    • yes - they can enable system sqlite over our own version (must be version number at or equal to what we have in tree)
  • What ranges for the tunable are appropriate? How are they determined?
    • toolkit.storage.synchronous
      • 0 - OFF, makes fsyncs not happen at all (risky for data integrity)
      • 1 - NORMAL, reduces the number of fsyncs by one in normal transactions. This is the default value, and the value used for an invalid input.
      • 2 - FULL, which is the safest setting for data integrity
  • What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
    • updating to newer versions if something comes up (fairly trivial to do)

Relationships to other projects

Are there related projects in the community?

  • If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
  • Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

Review comments

  • tangentially related: review code that has turned off synchronous writes for data integrity. Cookies, permission manager, per-site settings, offline cache
  • some SQL consumers were added prior to systematic security design reviews. Need to look at their SQL and make sure we're not vulnerable to injection.
  • Need a "best practices" mozStorage developer doc, for Mozilla developers and addon developers.
Retrieved from "https://wiki.mozilla.org/index.php?title=User_talk:Comrade693/SQLite_3.6.4_Security_Review&oldid=113652"