Re: firefox: unveil and pledge enhancements [8]

On Thu, Oct 03, 2019 at 04:25:23PM -0600, Theo de Raadt wrote:
> Solene Rapenne <solene@perso.pw> 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
> > >
> > >
> >
> > when opening a youtube video, after a few seconds (no need to start the
> > video) firefox stops with a pledge error.
> >
> > firefox[27483]: pledge "tty", syscall 54
>
> The output file will be huge, but by now it is obvious what is
> required:
>
> ktrace -di firefox
>
> kdump > hugefile
>
> And search for that the last record of that pid/thread (because the
> pledge killed it), and provide that information.
>
> It is ioctl. But what ioctl, and sometimes it also matters what
> that fd is, so you can search upwards for when it is created.
>
> Such information will be enough to find it in the code quickly.
>
> BTW, this applies to all pledge work.
>
>

I found this line just before writing a gigantic core file

52304 firefox CALL ioctl(124,VIDIOC_QUERYCAP,0x1d9a1d7ac158)

I'm not sure what I need to search for the fd, I found these lines
related to "124".

52304 firefox NAMI "/dev/video0"
52304 firefox GIO fd 4 wrote 4096 bytes
"\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\0\M^?\0\0\
[ lot of this ]
52304 firefox RET open 124/0x7c