On Tue, Sep 24, 2019 at 12:57:57PM -0600, Theo de Raadt wrote: > Landry Breuil <lan...@openbsd.org> wrote: > > > On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > > > Landry Breuil <lan...@openbsd.org> wrote: > > > > > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > > > joshua stein <j...@openbsd.org> 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. > > > > > > > > All good ideas need to be discussed with upstream at > > > > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271. I spent months > > > > upstreaming tons of patches, and i'm not carrying more of them.. > > > > > > Glad to se you've ignored the technical discussion and maintain the > > > opinion it must be upstream. > > > > I'm 'ignoring' the technical discussion because i dont feel qualified to > > have an opinion about it, nor do i have the time/energy to work on it. > > > > At that point, my best advice is to work with upstream because qualified > > people there might have a valuable technical opinion. Even if you doubt > > it. > > And I'm saying I don't believe it, to me it looks like the opening > comment leads the entire thread away form jcs's technically correct > solution. > > I believe those comments have led later Mozilla people who don't fully > understand pledge/unveil to echo your approach without understanding that > it totally nueters the security.
Then please enlighten them. > And as you said here, you "dont feel qualified". Yet you felt qualified > enough to break jcs's diffs. > > I'm suggesting that ignoring the technical, and focusing on the > political, being expedient at "reduction of patches", and bending over > backwards to please Mozilla people who don't understand unveil/pledge, > has caused harm here. It is turning a serious attempt at security > feature into security theater. Feel free to correct my mistakes there then, or find someone to do so. I'm done working on those diffs.
