On 2019/10/04 09:13, Solene Rapenne wrote: > On Wed, Oct 02, 2019 at 10:54:36AM +0200, Solene Rapenne wrote: > > On Wed, Sep 25, 2019 at 11:25:59AM -0500, joshua stein wrote: > > > This patchset goes back to files in /etc/firefox for unveil file > > > lists, and goes further and moves the pledge strings to separate > > > files too. This should be the most secure version that is still > > > tweakable at runtime. > > > > > > I switched away from using Firefox's NS_LOCAL_FILE_CONTRACTID/ > > > NS_LOCALFILEINPUTSTREAM_CONTRACTID mechanisms to read a file, since > > > they require a lot of internal setup to be done before they can be > > > used (which is otherwise a good thing, because other things later in > > > Firefox shouldn't have raw file access). Instead of those, I'm > > > using the normal C++ API for reading the /etc/firefox files and this > > > way I have been able to move the pledge/unveil calls earlier in the > > > process startup. Unfortunately this also means that I can't > > > dynamically detect the localized ~/Downloads directory, so if you > > > use a different directory, you'll just need to modify the > > > unveil.content and unveil.main files to change it. > > > > > > I tried the $TMPDIR shenanigans with the main process mkdtemp'ing > > > somewhere in $TMPDIR (or /tmp), and then exporting TMPDIR as that > > > directory so that everything else within Firefox uses that > > > subdirectory as its temp directory, allowing /tmp to be removed from > > > the unveil lists and only that subdirectory visible. Unfortunately > > > the first thing to break was our own shm_open() which hard-codes > > > /tmp and doesn't honor $TMPDIR. So that all was ripped out and > > > we're back to full access to /tmp. > > > > > > If the mailing list mangles this again, it's at > > > https://jcs.org/patches/firefox-port-unveil8.diff > > > > > > > > > > > > > In a very particular case, I get a > > firefox[4133]: pledge "inet", syscall 97 > > > > to do so, I make a ssh tunnel to a Proxmox web interface with default > > certificate (auto generated) > > > > ssh -L 44444:10.4.5.6:8006 some_remote_machine > > > > then, open https://localhost:44444 on firefox, and I get a pledge error > > with firefox showing "Gah. Your tab just crashed." > > > > Sadly, I've not been able to reproduce this with any other certificate. > > It may certainly not be related to ssh tunneling, but I can't try on direct > > lan > > access. > > > > kdump of the process (it's not the main process) when the tab crashes > > 43463 firefox CALL socket(AF_INET6,0x1<SOCK_STREAM>,0) > 43463 firefox PLDG socket, "inet", errno 1 Operation not permitted > 43463 firefox PSIG SIGABRT SIG_DFL > 43463 firefox NAMI "firefox.core" >
You may be able to figure out which process type it is, by looking at the earlier call to pledge() and examining the string. Or if the process was already created before opening the page you may also be able to figure it out from the pid if you "ps wwx" first. I wonder if a process without network pledge could be trying to fetch a missing intermediary cert from the address in the "CA Issuers" field in the cert. Might get some more information if you show the connection and cert from "openssl s_client -connect localhost:44444"..
