On Fri, Oct 04, 2019 at 11:14:18AM +0200, Solene Rapenne wrote:
> On Fri, Oct 04, 2019 at 10:00:18AM +0100, Stuart Henderson wrote:
> > 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"..
> > 
> 
> the failing process looks like this from ps
> 
> /usr/local/lib/firefox/firefox -contentproc -childID 1 -isForBrowser
> -prefsLen 170 -prefMapSize 197941 -parentBuildID 20190925193545 -appdir
> /usr/local/lib/firefox/browser 44467 tab
> 

I forgot to mention I've been able to try without ssh tunneling and same
issue happens with same previous error seen in kdump.
I wasn't sure but ssh tunneling is absolutely not related.

Reply via email to