> But to clarify, I'm not proposing to commit what I'm sending out, > this is just to get feedback from Firefox users so I can refine the > changes that are going upstream. Then once they are committed or at > least slated for inclusion, we can figure out how to integrate them > into our port(s) and patch up any hard-coded paths. >
Joshua, thanks a lot for your great work! With the proposed patch the overall security improvement is really large, but I see 3 ways how it could be circumvented. A compromised ff process: 1. writes prefs.js in ~/.mozilla/firefox/profile/prefs.js, setting the security.sandbox prefs for unrestricted access, restarts itself (via a crash, programmatically or by user), gets unrestricted access. 2. changes files in ~/.mozilla in such a way as to trigger an unknown vulnerability in the ff initialization logic that is executed before unveil() is locked, restarts itself, gets unrestricted access. 3. changes (user-owned) files of other programs in /tmp in such a way as to trigger an unknown vulnerability in some other un-unveiled app like say libreoffice or messes with sockets trying to find its way out. This way it doesn't escalate its privs up or compromises another user, but it gains un-unveiled/un-pledged execution. recently-used.xbel probably shouldn't be allowed at all. I believe the following changes could mitigate these escapes: 1. It could be decided which paths are customizable and which are not. Those that are not (i.e. system-wide paths and some paths in home) should be hardcoded. Those that are customizable (inside home like ~/Downloads, but not many more) could be processed like the patch proposes. ~/Downloads on non-English installs could be another folder (~/Descargas in Spanish) and it's a setting: browser.download.dir. Its value should be retrieved from there IMO and this way there would be no (many) customizable paths. If there are paths that do need to be user-customizable, they could be read from a dedicated file in ~/.mozilla/, to which unveil would only give read access, so a compromised ff process can't modify it. This would mitigate the 1st escape. 2. FF could be made to write tmp files to its own dir, i.e. instead of /tmp/xxx it could write its temp stuff to /tmp/firefox/xxx and unveil /tmp/firefox instead of the entire /tmp. This would mitigate the 3rd escape. 3. In order to mitigate the 2nd escape, the non-customizable hardcoded paths should be unveil()ed ASAP (i.e. on the 1st line inside main()) and then the process would continue refining the needed paths while initializing and reading configs (like browser.download.dir). For tmp case, on the 1st line in main() /tmp/firefox would be unveiled and later, once the tmp folder for the current profile & session is known/created, it would be restricted further to /tmp/firefox/xxx. The last point supposes that it's possible to progressively drop access to fs which is not available with unveil at this moment. I'd like to work on this extension (I call it veil()) and this case could serve as one of the possible use-cases of why it could be useful. Regards, Anatoli
