joshua stein <[email protected]> wrote: > 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.
I'm still very surprised. Their proposed model completely lacks any security, as it ignores obvious escalation techniques. The unveil/pledge/sandbox variables in question establish a process-containment. Let's say the attacker is aware of a browser bug which can achieve code-execution, well he will change those variables to request less (or no) containment, for FUTURE BROWSER RESTARTS. At that point he can crash the browser, which the user will restart WITHOUT CONTAINMENT, and the browser's default will revisit the same attacker pages permitting a continuation of the attack without sandbox constraints. If a program can disable it's own security policy, well then it isn't a security policy. I suggest doing as they ask to get it integrated, and then maintain a few lines of patch that causes root-owned-files to override the fragile user-selected options.
