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..
>From what ticket, it looks like the idea of not making the options
root-only comes from YOU in the introduction of the ticket chain:
"I doubt hardcoding /etc/firefox/unveil.main in the source
code will be accepted as is, since etc/firefox doesnt exist.
That directory was a jcs proposal, but there is nothing which said it
had to be that specific directory, and your entire approach leads
away from root-owned placement:
:gcp, what would be the preferred way to add a (potentially
user-customizable) config file listing paths and corresponding
perms ? Right now, filesystem isolation is configured this
way in our chromium port but i'm not comfortable with adding
/etc/firefox. A default file under
browser/defaults/preferences/, overridable by the user ? for
pledge we use about:config strings for that wont work for
unveil paths lists."
>From my quick read, it seems you are the one who led the firefox team to
requiring unveil/pledge choices be inside the program rather than in
root-only files.
then you mention that Linux and MacOS do it hardcoded and safe way, but:
"I know for linux & macos iirc the list is hardcoded in the source
code but that doesnt leave a way for the user to add paths."
And again, you are the one who leads the development towards the exactly
the insecurity mentioned in my post. Because only YOU suggested that
users must have a way to "add paths".
In the chrome paths, users cannot add paths, BECAUSE THAT WOULD BE
INSECURE.
>From my read, Mozilla didn't say this had to be user configurable on
their own. You did.
And in chrome, robert didn't. The root-owned files were added in
Slovenia years ago simply for fast-prototyping method so that chrome
didn't need to be recompiled to adjust the modes, they are effectively
hardcoded and once in a while I prod Robert asking if it is time to
remove those files and hardcode the pledges in the binary.
I'll say it again: I think this security problem I described comes
from you.
