User talk:Comrade693/SQLite 3.6.4 Security Review
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?
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
- Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
- See sqlite.def
- Does it interoperate with a web service? How will it do so?
- Explain the significant file formats, names, syntax, and semantics.
- temporary files
- Mozilla stores files in *.sqlite files.
- 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?
- What other modules are used (REQUIRES in the makefile, interfaces)
- 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
- 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
- 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?
- 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?
- 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.