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
>
running firefox on a fresh account produce an error because .config is
not there, creating it before starting firefox allow it to run.
$ firefox
firefox: /etc/firefox/unveil.main: unveil(/home/he-man/.config/dconf, rw) failed: No such file or directory
No comments:
Post a Comment