On Mon, 23 Sep 2019 at 18:46:58 -0300, Anatoli wrote: > > 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.
I don't like the pledge and unveil settings being in preferences for these and other reasons, but it's currently what Mozilla people are asking for in order to get reviewed/upstreamed and is how their own sandboxing on other platforms is controlled (security.sandbox.content.level can be changed on Linux for example). In the end, this task of upstreaming these patches may be too difficult or insecure and I'll go back to reading from root-owned files in /etc/firefox like our Chromium port does, having to carry our own patches for each release. I'm not sure what the plan is yet. But in the meantime, you can try setting the unveil for ~/.mozilla in security.sandbox.unveil.content to just "r" instead of "rwc". It seems to work here but it might break something obscure. Be sure to restart Firefox after making changes to those preferences. > 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. I don't think mitigating such an attack is the responsibility of Firefox, but yes, having GetSpecialSystemDirectory return a subdirectory of /tmp being the only thing accessible to Firefox would be more secure by further restricting what else it can see. > 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. That is good to know. I'll have to see where that is localized and make it dynamic in the unveil list.
