Hi,
start-tor-browser sets the SELFRANDO_write_layout_file environment variable to an empty string, which *enables* [1] the creation of the 7 MB /tmp/<PID>.mlf layout file. This adds 2 seconds of startup time on my system.
Would it make sense to *disable* it for alpha/stable builds? If so, the export line in start-tor-browser should be removed. (People who really want the layout file for debugging could still enable it by running "SELFRANDO_write_layout_file= ./start-tor-browser".)
Rusty
1. https://github.com/immunant/selfrando/blob/73f33ecc8031bdf9c2ba8d95191b23f7b...
On 17 May 2017, at 08:25, Rusty Bird rustybird@openmailbox.org wrote:
start-tor-browser sets the SELFRANDO_write_layout_file environment variable to an empty string, which *enables* [1] the creation of the 7 MB /tmp/<PID>.mlf layout file. This adds 2 seconds of startup time on my system.
Would it make sense to *disable* it for alpha/stable builds? If so, the export line in start-tor-browser should be removed. (People who really want the layout file for debugging could still enable it by running "SELFRANDO_write_layout_file= ./start-tor-browser".)
Even worse: can an exploit read this file to find out the memory layout?
(I think the answer is: yes, but it doesn't matter, because it would have to run arbitrary code to read the file. Maybe.)
T -- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 16 May 2017 at 19:21, teor teor2345@gmail.com wrote:
Even worse: can an exploit read this file to find out the memory layout?
(I think the answer is: yes, but it doesn't matter, because it would have to run arbitrary code to read the file. Maybe.)
My attitude towards this, and what I requested of the selfrando team for Mozilla's investigation, is that the seed/layout be written to disk and erased from memory. An attacker who gets an information disclosure could steal the seed from memory otherwise and undo the protection. Arbitrary file reads are less common that infoleaks. (And we want to keep the mapping around for debugging crashes.)
-tom
On Tue, 16 May 2017 19:45:40 -0500 Tom Ritter tom@ritter.vg wrote:
On 16 May 2017 at 19:21, teor teor2345@gmail.com wrote:
Even worse: can an exploit read this file to find out the memory layout?
(I think the answer is: yes, but it doesn't matter, because it would have to run arbitrary code to read the file. Maybe.)
My attitude towards this, and what I requested of the selfrando team for Mozilla's investigation, is that the seed/layout be written to disk and erased from memory. An attacker who gets an information disclosure could steal the seed from memory otherwise and undo the protection. Arbitrary file reads are less common that infoleaks. (And we want to keep the mapping around for debugging crashes.)
`sandboxed-tor-browser` doesn't set the env var, and I don't see myself ever setting it, because `/tmp` will get obliterated when firefox exits anyway.
Is it safe to assume that the current behavior of "not setting anything here will result in no files getting created" will remain consistent?
Regards,
Hi,
Since I suck and am a horrible person, can someone go and upload the alpha related update metadata resources there?
https://trac.torproject.org/projects/tor/ticket/22291
Thanks,
On Thu, 18 May 2017, Yawning Angel wrote:
Hi,
Since I suck and am a horrible person, can someone go and upload the alpha related update metadata resources there?
Ah sorry, I should have done it when releasing 7.0a4.
https://aus1.torproject.org/torbrowser/update_2/alpha/ should now be redirected to https://aus1.torproject.org/torbrowser/update_3/alpha/.
Nicolas
Rusty Bird:
Hi,
start-tor-browser sets the SELFRANDO_write_layout_file environment variable to an empty string, which *enables* [1] the creation of the 7 MB /tmp/<PID>.mlf layout file. This adds 2 seconds of startup time on my system.
Would it make sense to *disable* it for alpha/stable builds? If so, the export line in start-tor-browser should be removed. (People who really want the layout file for debugging could still enable it by running "SELFRANDO_write_layout_file= ./start-tor-browser".)
Yes, I think it is not unreasonable to remove that line once we move with selfrando to the stable series. I'd like to keep if for the alpha series for a while, though, as it might help to debug crashes in case we need to.
Georg
-
Georg Koppen -
Nicolas Vigier -
Rusty Bird -
teor -
Tom Ritter -
Yawning Angel