Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > > 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. I attempted to correct a mistake, by explaining how the decision to store the unveil/pledge configuration in userspace was pushing jcs's strong security design into a security theater. But you said Mozilla demanded it, and said you won't act against them. So once again, I attempted to correct the mistake, as I have interpreted that Mozilla's guidance in that direction is due to YOUR misguiding Mozilla people in that direction, ignoring the technical! And your reaction to that is "I'm done"? And all through this you say you don't care about the technical? Very strange.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Tue, Sep 24, 2019 at 12:57:57PM -0600, Theo de Raadt wrote: > Landry Breuil wrote: > > > On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > > > Landry Breuil wrote: > > > > > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > > > joshua stein 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.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > > Landry Breuil wrote: > > > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > > joshua stein 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. 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. > Sorry, in ports land we've always been told to work with upstream .. > https://www.openbsd.org/faq/ports/guide.html#PortsComplex as of now even > says 'Make sure the software authors are aware of your tweaks to make > it run on OpenBSD. You must endeavor to get OpenBSD patches into the > next release of the software. Otherwise, you can be prepared to rewrite > most of your patches from scratch every release.'. That page does not say "ignore the technical". Nor does it say "convince the upstream to incorporate useless diffs". It does not say "water down improvements".
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Tue, Sep 24, 2019 at 11:13:38AM -0600, Theo de Raadt wrote: > Landry Breuil wrote: > > > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > > joshua stein 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. You're of course free to disagree with me, and find someone else to do my work if you dont like the way i do it. > My personal opinion on this. I've contributed a technical point and > look at the result, I'm told to shut up and talk to some people I don't > care to talk to. Count me out, I will not run this trash fire. Sorry, in ports land we've always been told to work with upstream .. https://www.openbsd.org/faq/ports/guide.html#PortsComplex as of now even says 'Make sure the software authors are aware of your tweaks to make it run on OpenBSD. You must endeavor to get OpenBSD patches into the next release of the software. Otherwise, you can be prepared to rewrite most of your patches from scratch every release.'. Landry
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > joshua stein 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.. I've just explained how all this unveil/pledge effort is complete and utter security theater because the browser can undo the security, and you tell me to shut up and go to a bugzilla?
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > joshua stein 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.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil wrote: > On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > > joshua stein 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. My personal opinion on this. I've contributed a technical point and look at the result, I'm told to shut up and talk to some people I don't care to talk to. Count me out, I will not run this trash fire.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Tue, Sep 24, 2019 at 06:43:51AM -0600, Theo de Raadt wrote: > joshua stein 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..
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
joshua stein 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.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
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.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
> 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
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Sun, Sep 22, 2019 at 06:52:58PM +0200, Landry Breuil wrote: > On Sun, Sep 22, 2019 at 11:15:53AM -0500, joshua stein wrote: > > On Sun, 22 Sep 2019 at 14:13:02 +0200, prx wrote: > > > [snip] > > > > > > > > Everyone using firefox should definitely add its own usecases on top and > > > > test this. The idea is to refine the paths list until we have something > > > > we're confident with, then defaults will be pushed upstream. In the > > > > meantime, we'll work with upstream to get the plumbing/logic commited, > > > > as it can be done independentely from the paths list. > > > > > > > > If ppl have a hard time building with the patches, my beta pkgs for 70 > > > > available as usual at https://packages.rhaalovely.net/snapshots/amd64/ > > > > > > > > > > I installed the above package (thanks for this) and started firefox > > > after deleting ~/.mozilla. It's crashing. > > > > > > Below some more details : > > > > > > $ firefox > > > IPDL protocol error: main: > > > unveil(/.config/.config/.local/share/.cache/dconf, rwc) failed: 2 > > > > Do you have XDG_CONFIG_HOME, XDG_DATA_HOME, or XDG_CACHE_HOME set in > > your environment? > > > > There is a pledge for $XDG_CACHE_HOME/dconf which should expand to > > ~/.cache/dconf unless you have XDG_CACHE_HOME set to something else. > > How is the env var expansion supposed to work ? Fwiw i've reverted the env > vars > locally in > https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=unveil=595af5c9d77e489803da3068af91e588679d8017 > and uploaded a fixed pkg that should work. Havent had actual time to dig > into it though... maybe my patchset isnt enough in sync, will look. My patchset wasnt in sync with what jcs@ had posted to bugzilla, currently building with updated patches which should work. Will upload the resulting pkgs tmrw morning.. sorry for the mixup. Landry
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Sun, Sep 22, 2019 at 06:53:08PM +0200, prx wrote: > * joshua stein le [22-09-2019 11:15:53 -0500]: > > Do you have XDG_CONFIG_HOME, XDG_DATA_HOME, or XDG_CACHE_HOME set in > > your environment? > > > > None of them : > > $ echo $XDG_CONFIG_HOME - $XDG_DATA_HOME - $XDG_CACHE_HOME > - - Technically, that does not prove they're unset: $ XDG_CONFIG_HOME= $ echo $XDG_CONFIG_HOME They most certainly are, but to really check whether a variable is unset (so not even set to the empty string), I'd do $ set | grep -e ^XDG_ XDG_CONFIG_HOME= $
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Fri, Sep 20, 2019 at 10:00:32AM -0500, joshua stein wrote: > (I'm going to keep trying to send this until I get it right!) > > > I've been working on enhancing the security of our Firefox port over > the past couple weeks and would like some wider testing. > > - Firefox's GPU process gains pledge(2) support, now all three > process types (main, content, and gpu) are pledged. > > - The inet permission is removed from content processes as they work > without it. > > - All three process types gain unveil(2) support to limit filesystem > access. Similar to our Chrome port, ~/Downloads and /tmp become > the only major directories that the main process can read from and > write to (aside from some other Firefox- and Gtk-specific > cache/support directories like ~/.mozilla) and that the content > process can read from for viewing files as file:// URLs. Aftter light testing this works for me as intended. Also my settings of XDG env variables seem to work. Personnaly I don't like the restriction on reading files from a usability point of view (but I understand the security reasoning), and since Chrome users seeem to have accepted it, I will do the same with Firefox. A better solution would involve some confirmation dialog, telling which file is read for which purpose (internal use by a web app, or uploading to an external site, like nextcloud or mastodon, instagram whatever). But this may not always be possible with modern web technologies and is not in the scope of local patches to the OpenBSD port. sigh. -- Matthieu Herrb
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Sun, Sep 22, 2019 at 11:15:53AM -0500, joshua stein wrote: > On Sun, 22 Sep 2019 at 14:13:02 +0200, prx wrote: > > [snip] > > > > > > Everyone using firefox should definitely add its own usecases on top and > > > test this. The idea is to refine the paths list until we have something > > > we're confident with, then defaults will be pushed upstream. In the > > > meantime, we'll work with upstream to get the plumbing/logic commited, > > > as it can be done independentely from the paths list. > > > > > > If ppl have a hard time building with the patches, my beta pkgs for 70 > > > available as usual at https://packages.rhaalovely.net/snapshots/amd64/ > > > > > > > I installed the above package (thanks for this) and started firefox > > after deleting ~/.mozilla. It's crashing. > > > > Below some more details : > > > > $ firefox > > IPDL protocol error: main: > > unveil(/.config/.config/.local/share/.cache/dconf, rwc) failed: 2 > > Do you have XDG_CONFIG_HOME, XDG_DATA_HOME, or XDG_CACHE_HOME set in > your environment? > > There is a pledge for $XDG_CACHE_HOME/dconf which should expand to > ~/.cache/dconf unless you have XDG_CACHE_HOME set to something else. How is the env var expansion supposed to work ? Fwiw i've reverted the env vars locally in https://cgit.rhaalovely.net/mozilla-firefox/commit/?h=unveil=595af5c9d77e489803da3068af91e588679d8017 and uploaded a fixed pkg that should work. Havent had actual time to dig into it though... maybe my patchset isnt enough in sync, will look. Landry
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
* joshua stein le [22-09-2019 11:15:53 -0500]: > On Sun, 22 Sep 2019 at 14:13:02 +0200, prx wrote: > > [snip] > > > > > > Everyone using firefox should definitely add its own usecases on top and > > > test this. The idea is to refine the paths list until we have something > > > we're confident with, then defaults will be pushed upstream. In the > > > meantime, we'll work with upstream to get the plumbing/logic commited, > > > as it can be done independentely from the paths list. > > > > > > If ppl have a hard time building with the patches, my beta pkgs for 70 > > > available as usual at https://packages.rhaalovely.net/snapshots/amd64/ > > > > > > > I installed the above package (thanks for this) and started firefox > > after deleting ~/.mozilla. It's crashing. > > > > Below some more details : > > > > $ firefox > > IPDL protocol error: main: > > unveil(/.config/.config/.local/share/.cache/dconf, rwc) failed: 2 > > Do you have XDG_CONFIG_HOME, XDG_DATA_HOME, or XDG_CACHE_HOME set in > your environment? > None of them : $ echo $XDG_CONFIG_HOME - $XDG_DATA_HOME - $XDG_CACHE_HOME - - But how could I know I need them ? Should I set them in ~/.config/user-dirs.dirs? ?
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Sun, 22 Sep 2019 at 14:13:02 +0200, prx wrote: > [snip] > > > > Everyone using firefox should definitely add its own usecases on top and > > test this. The idea is to refine the paths list until we have something > > we're confident with, then defaults will be pushed upstream. In the > > meantime, we'll work with upstream to get the plumbing/logic commited, > > as it can be done independentely from the paths list. > > > > If ppl have a hard time building with the patches, my beta pkgs for 70 > > available as usual at https://packages.rhaalovely.net/snapshots/amd64/ > > > > I installed the above package (thanks for this) and started firefox > after deleting ~/.mozilla. It's crashing. > > Below some more details : > > $ firefox > IPDL protocol error: main: > unveil(/.config/.config/.local/share/.cache/dconf, rwc) failed: 2 Do you have XDG_CONFIG_HOME, XDG_DATA_HOME, or XDG_CACHE_HOME set in your environment? There is a pledge for $XDG_CACHE_HOME/dconf which should expand to ~/.cache/dconf unless you have XDG_CACHE_HOME set to something else. > Segmentation fault (core dumped) When pledge() fails, it calls mozilla::ipc::FatalError which triggers MOZ_CRASH_UNSAFE, which calls abort(), so these crashes are expected.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
> unveil(/.config/.config/.local/share/.cache/dconf, rwc) failed: 2 Let me just say wow, what a schizophenic pathname.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
[snip] > > Everyone using firefox should definitely add its own usecases on top and > test this. The idea is to refine the paths list until we have something > we're confident with, then defaults will be pushed upstream. In the > meantime, we'll work with upstream to get the plumbing/logic commited, > as it can be done independentely from the paths list. > > If ppl have a hard time building with the patches, my beta pkgs for 70 > available as usual at https://packages.rhaalovely.net/snapshots/amd64/ > I installed the above package (thanks for this) and started firefox after deleting ~/.mozilla. It's crashing. Below some more details : $ firefox IPDL protocol error: main: unveil(/.config/.config/.local/share/.cache/dconf, rwc) failed: 2 Segmentation fault (core dumped) $ tail /var/log/messages Sep 22 13:49:00 moria firefox: vfprintf %s NULL in "%s: Resetting desktop app info dirs from %s to %s" $ gdb firefox.core [...] Core was generated by `firefox'. Program terminated with signal 11, Segmentation fault. 0 0x11c39178be2a in ?? () (gbd) bt full #0 0x11c39178be2a in ?? () No symbol table info available. #1 0xfffb1b89345035c0 in ?? () No symbol table info available. #2 0xfff9 in ?? () No symbol table info available. #3 0x15f8073266f0 in ?? () No symbol table info available. #4 0x000b0252 in ?? () No symbol table info available. #5 0x74536c61626f6c47 in ?? () No symbol table info available. #6 0x00657461 in ?? () No symbol table info available. #7 0x in ?? () No symbol table info available. $ dmesg OpenBSD 6.6-beta (GENERIC.MP) #314: Mon Sep 16 19:13:24 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4217090048 (4021MB) avail mem = 4076605440 (3887MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (55 entries) bios0: vendor American Megatrends Inc. version "V30.6" date 12/15/2014 bios0: MSI MS-7721 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET UEFI IVRS SSDT SSDT CRAT SSDT SSDT SSDT acpi0: wakeup devices SBAZ(S4) P0PC(S4) OHC1(S4) EHC1(S4) OHC2(S4) EHC2(S4) OHC3(S4) EHC3(S4) OHC4(S4) XHC0(S4) XHC1(S4) PE20(S4) PE21(S4) PE23(S4) PB2_(S4) PB3_(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 16 (boot processor) cpu0: AMD A8-6600K APU with Radeon(tm) HD Graphics, 4021.08 MHz, 15-13-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1 cpu0: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative tsc_timecounter_init: TSC skew=0 observed drift=0 cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 103MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 17 (application processor) TSC skew=103 cpu1: AMD A8-6600K APU with Radeon(tm) HD Graphics, 798.76 MHz, 15-13-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,XOP,SKINIT,WDT,FMA4,TCE,NODEID,TBM,TOPEXT,CPCTR,ITSC,BMI1 cpu1: 64KB 64b/line 2-way I-cache, 16KB 64b/line 4-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 48 4KB entries fully associative, 24 4MB entries fully associative cpu1: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative tsc_timecounter_init: TSC skew=103 observed drift=0 cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 18 (application processor) TSC skew=-132 cpu2: AMD A8-6600K APU with Radeon(tm) HD Graphics, 798.25 MHz, 15-13-01 cpu2:
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
Landry Breuil writes: > On Fri, Sep 20, 2019 at 10:00:32AM -0500, joshua stein wrote: > > > >> These patches are being tracked upstream and landry@ will help to >> get them integrated once they are stable, although this review >> process may take a while and it will probably take a while before >> they reach a mainline release: >> >> - sandbox GPU process on OpenBSD with pledge(): >> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1580268 >> >> - enhance sandbox on OpenBSD with unveil(): >> https://bugzilla.mozilla.org/show_bug.cgi?id=3D1580271 >> >> As for testing, please try all of your normal Firefox usage as >> everything should still work. I've tested all of these things: >> >> - Launching with an existing profile or letting it create a new one >> in ~/.mozilla >> - Basic multi-tabbed and multi-window browsing >> - Add-ons (Bitwarden, uBlock Origin, Tunnelbear VPN, etc.) >> - Playing a YouTube video with sound >> - Webcam access >> - Accelerated graphics with MOZ_ACCELERATED=3D1 (verifying >> about:support shows HW_COMPOSITING enabled and detailed GPU #1 >> info), viewing some WebGL benchmark sites >> - File->Open, can only view ~/Downloads (this is the main process) >> - When a file is selected, it is able to be opened as a file:// >> URL (this is a content process reading it) >> - When uploading a file, only ~/Downloads can be seen (or a >> read-only directory like ~/Photos specifically added to the >> security.sandbox.unveil.main list) >> - Executing a 3rd party app via GIO/XDG such as mupdf for opening >> PDFs >> - Executing a 3rd party app from ~/.mailcap such as xpdf for PDFs >> - Printing via CUPS > > Everyone using firefox should definitely add its own usecases on top and > test this. The idea is to refine the paths list until we have something > we're confident with, then defaults will be pushed upstream. In the > meantime, we'll work with upstream to get the plumbing/logic commited, > as it can be done independentely from the paths list. > > If ppl have a hard time building with the patches, my beta pkgs for 70 > available as usual at https://packages.rhaalovely.net/snapshots/amd64/ > have some variation of the patches built from this git branch: > https://cgit.rhaalovely.net/mozilla-firefox/?h=unveil > I will keep this git branch updated with the patches posted upstream at > https://bugzilla.mozilla.org/show_bug.cgi?id=1580268 & > https://bugzilla.mozilla.org/show_bug.cgi?id=1580271 > > Many thanks jcs@ for working on this, and i hope to get them > tested/polished enough by november so that it can get commited around > p2k19. > > Landry Firefox fails to start after replacing the "stock version": firefox[22060]: pledge "tty", syscall 54 tmy@asteroid tmy $ firefox IPDL protocol error: main: unveil($XDG_CACHE_HOME/dconf, rwc) failed: 2 Segmentation fault (core dumped) tmy@asteroid tmy $ echo $XDG_CACHE_HOME tmy@asteroid tmy $ timo
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Fri, Sep 20, 2019 at 10:00:32AM -0500, joshua stein wrote: > These patches are being tracked upstream and landry@ will help to > get them integrated once they are stable, although this review > process may take a while and it will probably take a while before > they reach a mainline release: > > - sandbox GPU process on OpenBSD with pledge(): > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1580268 > > - enhance sandbox on OpenBSD with unveil(): > https://bugzilla.mozilla.org/show_bug.cgi?id=3D1580271 > > As for testing, please try all of your normal Firefox usage as > everything should still work. I've tested all of these things: > > - Launching with an existing profile or letting it create a new one > in ~/.mozilla > - Basic multi-tabbed and multi-window browsing > - Add-ons (Bitwarden, uBlock Origin, Tunnelbear VPN, etc.) > - Playing a YouTube video with sound > - Webcam access > - Accelerated graphics with MOZ_ACCELERATED=3D1 (verifying > about:support shows HW_COMPOSITING enabled and detailed GPU #1 > info), viewing some WebGL benchmark sites > - File->Open, can only view ~/Downloads (this is the main process) > - When a file is selected, it is able to be opened as a file:// > URL (this is a content process reading it) > - When uploading a file, only ~/Downloads can be seen (or a > read-only directory like ~/Photos specifically added to the > security.sandbox.unveil.main list) > - Executing a 3rd party app via GIO/XDG such as mupdf for opening > PDFs > - Executing a 3rd party app from ~/.mailcap such as xpdf for PDFs > - Printing via CUPS Everyone using firefox should definitely add its own usecases on top and test this. The idea is to refine the paths list until we have something we're confident with, then defaults will be pushed upstream. In the meantime, we'll work with upstream to get the plumbing/logic commited, as it can be done independentely from the paths list. If ppl have a hard time building with the patches, my beta pkgs for 70 available as usual at https://packages.rhaalovely.net/snapshots/amd64/ have some variation of the patches built from this git branch: https://cgit.rhaalovely.net/mozilla-firefox/?h=unveil I will keep this git branch updated with the patches posted upstream at https://bugzilla.mozilla.org/show_bug.cgi?id=1580268 & https://bugzilla.mozilla.org/show_bug.cgi?id=1580271 Many thanks jcs@ for working on this, and i hope to get them tested/polished enough by november so that it can get commited around p2k19. Landry
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Fri, Sep 20, 2019 at 10:00:32AM -0500, joshua stein wrote: > (I'm going to keep trying to send this until I get it right!) > > > I've been working on enhancing the security of our Firefox port over > the past couple weeks and would like some wider testing. > > - Firefox's GPU process gains pledge(2) support, now all three > process types (main, content, and gpu) are pledged. > > - The inet permission is removed from content processes as they work > without it. > > - All three process types gain unveil(2) support to limit filesystem > access. Similar to our Chrome port, ~/Downloads and /tmp become > the only major directories that the main process can read from and > write to (aside from some other Firefox- and Gtk-specific > cache/support directories like ~/.mozilla) and that the content > process can read from for viewing files as file:// URLs. I'm running Firefox with this patch, I did not encounter any issue with my typical daily usage.
Re: LOCALBASE [Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]]
> > After *all* these years, I don't understand why we are still pretending to > > be > > able to install stuff outside of /usr/local. > > It causes nothing but pain for porters for absolutely *0* benefit. Because > > it's > > a promise we cannot hold. > > Can't we just agree that VARBASE is /var, SYSCONFDIR is /etc and PREFIX is > > /usr/local once and for all? > > > > Sorry for hijacking this thread but we all know what all these SUBST_CMD do > > in > > real life: s,/usr/local,/usr/local, > > > > Time to be pragmatic... > > I'm not opposed to that. But it should be a decision taken separately > rather than just not bothering to continue with the status quo in any > particular port update. Agreed, that's why I said I was sorry about hijacking the thread. I will shut up and put it on the agenda for p2k19. -- Antoine
LOCALBASE [Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]]
On 2019/09/20 19:03, Antoine Jacoutot wrote:
> > > Ports shouldn't use hardcoded /usr/local - the diff attached uses
> > > ${LOCALBASE}/${TRUEPREFIX} instead of /usr/local as appropriate,
> > > ${X11BASE} instead of /usr/X11R6, ${SYSCONFDIR} for the /etc files
> > > that comes from ports rather than base, and ${SUBST_CMD} in
> > > post-patch to substitute them for the correct paths.
> >
> > These patches have to go upstream, so those paths can't be dynamic.
> > I don't know what Landry's plan is for patching our port before they
> > are committed upstream, but once they are committed, I guess there
> > can be a post-patch step to turn them from hard-coded defaults to
> > ${LOCALBASE} and friends.
>
> After *all* these years, I don't understand why we are still pretending to be
> able to install stuff outside of /usr/local.
> It causes nothing but pain for porters for absolutely *0* benefit. Because
> it's
> a promise we cannot hold.
> Can't we just agree that VARBASE is /var, SYSCONFDIR is /etc and PREFIX is
> /usr/local once and for all?
>
> Sorry for hijacking this thread but we all know what all these SUBST_CMD do in
> real life: s,/usr/local,/usr/local,
>
> Time to be pragmatic...
I'm not opposed to that. But it should be a decision taken separately
rather than just not bothering to continue with the status quo in any
particular port update.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
> > Ports shouldn't use hardcoded /usr/local - the diff attached uses
> > ${LOCALBASE}/${TRUEPREFIX} instead of /usr/local as appropriate,
> > ${X11BASE} instead of /usr/X11R6, ${SYSCONFDIR} for the /etc files
> > that comes from ports rather than base, and ${SUBST_CMD} in
> > post-patch to substitute them for the correct paths.
>
> These patches have to go upstream, so those paths can't be dynamic.
> I don't know what Landry's plan is for patching our port before they
> are committed upstream, but once they are committed, I guess there
> can be a post-patch step to turn them from hard-coded defaults to
> ${LOCALBASE} and friends.
After *all* these years, I don't understand why we are still pretending to be
able to install stuff outside of /usr/local.
It causes nothing but pain for porters for absolutely *0* benefit. Because it's
a promise we cannot hold.
Can't we just agree that VARBASE is /var, SYSCONFDIR is /etc and PREFIX is
/usr/local once and for all?
Sorry for hijacking this thread but we all know what all these SUBST_CMD do in
real life: s,/usr/local,/usr/local,
Time to be pragmatic...
--
Antoine
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Fri, 20 Sep 2019 at 11:44:58 -0500, joshua stein wrote:
> On Fri, 20 Sep 2019 at 17:33:40 +0100, Stuart Henderson wrote:
> > On 2019/09/20 10:00, joshua stein wrote:
> > > While the Chrome port uses separate files in /etc/chromium for
> > > unveil file lists, these patches use new comma-separated
> > > about:config keys for them.
> >
> > > onts r,/etc/machine-id r,/etc/mailcap r,/tmp rwc,/usr/bin/lpr
> > > rx,/usr/local=
> > > /bin/gio-launch-desktop rx,/usr/local/lib r,/usr/local/firefox
> > > r,/usr/local=
> > > /lib/firefox rx,/usr/local/share r,/usr/share/locale
> > > r,/var/cache/fontconfi=
> > > g r,/usr/X11R6/lib r,/usr/X11R6/share r,/var/run rw,~/.XCompose
> > > r,~/.Xautho=
> >
> > Ports shouldn't use hardcoded /usr/local - the diff attached uses
> > ${LOCALBASE}/${TRUEPREFIX} instead of /usr/local as appropriate,
> > ${X11BASE} instead of /usr/X11R6, ${SYSCONFDIR} for the /etc files
> > that comes from ports rather than base, and ${SUBST_CMD} in
> > post-patch to substitute them for the correct paths.
>
> These patches have to go upstream, so those paths can't be dynamic.
> I don't know what Landry's plan is for patching our port before they
> are committed upstream, but once they are committed, I guess there
> can be a post-patch step to turn them from hard-coded defaults to
> ${LOCALBASE} and friends.
Or I guess at that point it would actually be a patch to the
hard-coded files, which then has to get post-patched. I don't know.
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.
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On Fri, 20 Sep 2019 at 17:33:40 +0100, Stuart Henderson wrote:
> On 2019/09/20 10:00, joshua stein wrote:
> > While the Chrome port uses separate files in /etc/chromium for
> > unveil file lists, these patches use new comma-separated
> > about:config keys for them.
>
> > onts r,/etc/machine-id r,/etc/mailcap r,/tmp rwc,/usr/bin/lpr rx,/usr/local=
> > /bin/gio-launch-desktop rx,/usr/local/lib r,/usr/local/firefox r,/usr/local=
> > /lib/firefox rx,/usr/local/share r,/usr/share/locale r,/var/cache/fontconfi=
> > g r,/usr/X11R6/lib r,/usr/X11R6/share r,/var/run rw,~/.XCompose r,~/.Xautho=
>
> Ports shouldn't use hardcoded /usr/local - the diff attached uses
> ${LOCALBASE}/${TRUEPREFIX} instead of /usr/local as appropriate,
> ${X11BASE} instead of /usr/X11R6, ${SYSCONFDIR} for the /etc files
> that comes from ports rather than base, and ${SUBST_CMD} in
> post-patch to substitute them for the correct paths.
These patches have to go upstream, so those paths can't be dynamic.
I don't know what Landry's plan is for patching our port before they
are committed upstream, but once they are committed, I guess there
can be a post-patch step to turn them from hard-coded defaults to
${LOCALBASE} and friends.
> fwiw, I'm a bit worried about the per-user config for this, will the
> list be copied as-is to individual user prefs (my test build isn't done
> yet) .. The list will definitely need to be updated in the future and
> that won't work if users have to hand apply the changes to their own
> profile. (Also it makes life difficult for multi-user installs ..).
The new preferences are like any other default in Firefox and don't
actually get stored in the user's profile unless they have been
modified. So for most users, each Firefox/package update will be
using the new lists as shipped with Firefox or our package.
I would have preferred local files like Chromium because they are
much easier to view/edit, easier to diff, and if root-owned, an
unprivileged user can't modify them. But for integration into
Firefox, this is what they wanted and Landry and I would rather not
maintain our own ball of local patches (see Chromium).
Re: www/mozilla-firefox: add unveil and enhance pledge support [3rd time's a charm]
On 2019/09/20 10:00, joshua stein wrote:
> While the Chrome port uses separate files in /etc/chromium for
> unveil file lists, these patches use new comma-separated
> about:config keys for them.
> onts r,/etc/machine-id r,/etc/mailcap r,/tmp rwc,/usr/bin/lpr rx,/usr/local=
> /bin/gio-launch-desktop rx,/usr/local/lib r,/usr/local/firefox r,/usr/local=
> /lib/firefox rx,/usr/local/share r,/usr/share/locale r,/var/cache/fontconfi=
> g r,/usr/X11R6/lib r,/usr/X11R6/share r,/var/run rw,~/.XCompose r,~/.Xautho=
Ports shouldn't use hardcoded /usr/local - the diff attached uses
${LOCALBASE}/${TRUEPREFIX} instead of /usr/local as appropriate,
${X11BASE} instead of /usr/X11R6, ${SYSCONFDIR} for the /etc files
that comes from ports rather than base, and ${SUBST_CMD} in
post-patch to substitute them for the correct paths.
fwiw, I'm a bit worried about the per-user config for this, will the
list be copied as-is to individual user prefs (my test build isn't done
yet) .. The list will definitely need to be updated in the future and
that won't work if users have to hand apply the changes to their own
profile. (Also it makes life difficult for multi-user installs ..).
? .todo
Index: Makefile
===
RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
retrieving revision 1.394
diff -u -p -r1.394 Makefile
--- Makefile18 Sep 2019 16:58:05 - 1.394
+++ Makefile20 Sep 2019 16:33:33 -
@@ -10,6 +10,8 @@ MOZILLA_BRANCH = release
MOZILLA_PROJECT = firefox
MOZILLA_CODENAME = browser
+REVISION = 0
+
WRKDIST = ${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
HOMEPAGE = https://www.mozilla.org/firefox/
SO_VERSION = 84.0
@@ -74,6 +76,10 @@ SUBST_VARS +=LOCALBASE X11BASE
show-commit:
@curl -s
https://releases.mozilla.org/pub/mozilla.org/firefox/releases/${MOZILLA_VERSION}/SOURCE|
awk -F / '/^https:\/\/hg/ {print $$7 }'
+
+post-patch:
+ ${SUBST_CMD} ${WRKSRC}/toolkit/system/gnome/nsGIOService.cpp \
+ ${WRKSRC}/browser/app/profile/firefox.js
post-install:
${SUBST_MAN} ${FILESDIR}/mozilla-firefox.1 \
Index: patches/patch-browser_app_profile_firefox_js
===
RCS file: patches/patch-browser_app_profile_firefox_js
diff -N patches/patch-browser_app_profile_firefox_js
--- /dev/null 1 Jan 1970 00:00:00 -
+++ patches/patch-browser_app_profile_firefox_js20 Sep 2019 16:33:33
-
@@ -0,0 +1,33 @@
+$OpenBSD$
+
+sandbox GPU process on OpenBSD with pledge()
+https://bugzilla.mozilla.org/show_bug.cgi?id=1580268
+
+enhance sandbox on OpenBSD with unveil()
+https://bugzilla.mozilla.org/show_bug.cgi?id=1580271
+
+Index: browser/app/profile/firefox.js
+--- browser/app/profile/firefox.js.orig
browser/app/profile/firefox.js
+@@ -1130,11 +1130,18 @@ pref("security.sandbox.content.syscall_whitelist", "")
+ #endif
+
+ #if defined(XP_OPENBSD) && defined(MOZ_SANDBOX)
++pref("security.sandbox.content.level", 1);
++
+ // default pledge strings for the main & content processes, cf bug 1457092
+-// broad list for now, has to be refined over time
+ pref("security.sandbox.pledge.main", "stdio rpath wpath cpath inet proc exec
prot_exec flock ps sendfd recvfd dns vminfo tty drm unix fattr getpw mcast");
+-pref("security.sandbox.content.level", 1);
+-pref("security.sandbox.pledge.content", "stdio rpath wpath cpath inet recvfd
sendfd prot_exec unix drm ps");
++pref("security.sandbox.pledge.content", "stdio rpath wpath cpath recvfd
sendfd prot_exec unix drm ps");
++// and for gpu, bug 1580268
++pref("security.sandbox.pledge.gpu", "stdio rpath wpath cpath ps sendfd recvfd
drm dns unix prot_exec");
++
++// default file paths unveiled to each process, bug 1580271
++pref("security.sandbox.unveil.main", "/dev/urandom r,/dev/video rw,/etc/fonts
r,${SYSCONFDIR}/machine-id r,${SYSCONFDIR}/mailcap r,/tmp rwc,/usr/bin/lpr
rx,${LOCALBASE}/bin/gio-launch-desktop rx,${LOCALBASE}/lib
r,${TRUEPREFIX}/firefox r,${TRUEPREFIX}/lib/firefox rx,${LOCALBASE}/share
r,/usr/share/locale r,/var/cache/fontconfig r,${X11BASE}/lib r,${X11BASE}/share
r,/var/run rw,~/.XCompose r,~/.Xauthority r,~/.Xdefaults r,~/.fontconfig
r,~/.fonts r,~/.fonts.conf r,~/.fonts.conf.d r,~/.icons r,~/.mailcap
r,~/.mime.types r,~/.mozilla rwc,~/.pki rwc,~/.sndio rwc,~/.terminfo
r,$XDG_CACHE_HOME/dconf rwc,$XDG_CACHE_HOME/thumbnails
rwc,$XDG_CONFIG_HOME/dconf r,$XDG_CONFIG_HOME/fontconfig
r,$XDG_CONFIG_HOME/gtk-3.0 r,$XDG_CONFIG_HOME/mimeapps.list
r,$XDG_CONFIG_HOME/mozilla rwc,$XDG_CONFIG_HOME/user-dirs.dirs
r,$XDG_DATA_HOME/applications rwc,$XDG_DATA_HOME/applnk r,$XDG_DATA_HOME/fonts
r,$XDG_DATA_HOME/glib-2.0 r,$XDG_DATA_HOME/icons r,$XDG_DATA_HOME/mime
r,$XDG_DATA_HOME/recently-used.xbel rwc,$XDG_DATA_HOME/themes r,~/Downloads
rwc");
++pref("security.sandbox.unveil.content", "/dev/drm0 rw,/etc/fonts
r,${SYSCONFDIR}/machine-id r,/tmp
