Re: firefox: unveil and pledge enhancements [8]
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 4:10.4.5.6:8006 some_remote_machine > > > > > > > > then, open https://localhost:4 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,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:4".. > > > > 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.
Re: firefox: unveil and pledge enhancements [8]
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 4:10.4.5.6:8006 some_remote_machine > > > > > > then, open https://localhost:4 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,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:4".. > 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
Re: firefox: unveil and pledge enhancements [8]
On 2019/10/04 10:00, Stuart Henderson wrote: > 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:4".. Ah, Solene pointed out that she already included this in the first mail. There's no CAI in the certificate which invalidates my "fetching missing intermediary" theory.
Re: firefox: unveil and pledge enhancements [8]
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 4:10.4.5.6:8006 some_remote_machine > > > > then, open https://localhost:4 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,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:4"..
Re: firefox: unveil and pledge enhancements [8]
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 4:10.4.5.6:8006 some_remote_machine > > then, open https://localhost:4 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,0) 43463 firefox PLDG socket, "inet", errno 1 Operation not permitted 43463 firefox PSIG SIGABRT SIG_DFL 43463 firefox NAMI "firefox.core"
Re: firefox: unveil and pledge enhancements [8]
On Thu, Oct 03, 2019 at 07:59:33PM -0500, joshua stein wrote: > On Fri, 04 Oct 2019 at 01:05:12 +0200, Solene Rapenne wrote: > > 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 > > > > I'm guessing this is the main process since the content process > can't open /dev/video, but if you grep the kdump output for > "52304.*pledge" it will show what file it read its promises from. > Then you can add the video pledge to that file and see if it fixes > the crash. > > But perhaps it's stranger that Firefox is trying to read your webcam > information just by viewing a YouTube video... The browser is trying to access the webcam because a page called in GetUserMedia/WebRTC APIs to figure out if a webcam is available.. Afaict, firefox itself makes no decisions - the websites authors do.
Re: firefox: unveil and pledge enhancements [8]
joshua stein wrote: > On Fri, 04 Oct 2019 at 01:05:12 +0200, Solene Rapenne wrote: > > 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 > > > > I'm guessing this is the main process since the content process > can't open /dev/video, but if you grep the kdump output for > "52304.*pledge" it will show what file it read its promises from. > Then you can add the video pledge to that file and see if it fixes > the crash. > > But perhaps it's stranger that Firefox is trying to read your webcam > information just by viewing a YouTube video... Maybe they are taking photos of the people who won't use DOH.
Re: firefox: unveil and pledge enhancements [8]
joshua stein wrote: > On Fri, 04 Oct 2019 at 01:05:12 +0200, Solene Rapenne wrote: > > 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 > > > > I'm guessing this is the main process since the content process > can't open /dev/video, but if you grep the kdump output for > "52304.*pledge" it will show what file it read its promises from. > Then you can add the video pledge to that file and see if it fixes > the crash. > > But perhaps it's stranger that Firefox is trying to read your webcam > information just by viewing a YouTube video... Are we cynical yet??
Re: firefox: unveil and pledge enhancements [8]
On Fri, 04 Oct 2019 at 01:05:12 +0200, Solene Rapenne wrote: > 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 > I'm guessing this is the main process since the content process can't open /dev/video, but if you grep the kdump output for "52304.*pledge" it will show what file it read its promises from. Then you can add the video pledge to that file and see if it fixes the crash. But perhaps it's stranger that Firefox is trying to read your webcam information just by viewing a YouTube video...
Re: firefox: unveil and pledge enhancements [8]
Solene Rapenne wrote:
> 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
That process needs the "video" pledge.
if ((p->p_p->ps_pledge & PLEDGE_VIDEO)) {
switch (com) {
case VIDIOC_QUERYCAP:
Wonder what process it is in
Re: firefox: unveil and pledge enhancements [8]
On Thu, Oct 03, 2019 at 04:25:23PM -0600, Theo de Raadt wrote: > 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 > > > > > > > > > > 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
Re: firefox: unveil and pledge enhancements [8]
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 > > > > > > 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.
Re: firefox: unveil and pledge enhancements [8]
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
Re: firefox: unveil and pledge enhancements [8]
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
>
>
> Index: Makefile
> ===
> RCS file: /cvs/ports/www/mozilla-firefox/Makefile,v
> retrieving revision 1.395
> diff -u -p -u -p -r1.395 Makefile
> --- Makefile 22 Sep 2019 17:19:06 - 1.395
> +++ Makefile 25 Sep 2019 16:23:36 -
> @@ -10,6 +10,8 @@ MOZILLA_BRANCH =release
> MOZILLA_PROJECT =firefox
> MOZILLA_CODENAME = browser
>
> +REVISION=0
> +
> WRKDIST =${WRKDIR}/${MOZILLA_DIST}-${MOZILLA_DIST_VERSION:C/b[0-9]*//}
> HOMEPAGE = https://www.mozilla.org/firefox/
> SO_VERSION = 84.0
> @@ -93,5 +95,10 @@ post-install:
>
> # link default48.png to default.png to be used by default by non-icccm
> compliant wm
> ln
> ${PREFIX}/lib/${MOZILLA_PROJECT}/browser/chrome/icons/default/default{48,}.png
> +
> + ${INSTALL_DATA_DIR} ${PREFIX}/share/examples/${MOZILLA_PROJECT}
> +.for f in unveil.content unveil.gpu unveil.main pledge.content pledge.gpu
> pledge.main
> + ${INSTALL_DATA} ${FILESDIR}/${f}
> ${PREFIX}/share/examples/${MOZILLA_PROJECT}/
> +.endfor
>
> .include
> Index: files/all-openbsd.js
> ===
> RCS file: /cvs/ports/www/mozilla-firefox/files/all-openbsd.js,v
> retrieving revision 1.10
> diff -u -p -u -p -r1.10 all-openbsd.js
> --- files/all-openbsd.js 9 Sep 2019 18:50:35 - 1.10
> +++ files/all-openbsd.js 25 Sep 2019 16:23:36 -
> @@ -5,10 +5,6 @@ pref("app.normandy.enabled",false);
> pref("browser.safebrowsing.enabled", false);
> pref("browser.safebrowsing.malware.enabled", false);
> pref("spellchecker.dictionary_path", "${LOCALBASE}/share/mozilla-dicts/");
> -// enable pledging the content process
> -pref("security.sandbox.content.level", 1);
> -pref("security.sandbox.pledge.main","stdio rpath wpath cpath inet proc exec
> prot_exec flock ps sendfd recvfd dns vminfo tty drm unix fattr getpw mcast
> video");
> -pref("security.sandbox.pledge.content","stdio rpath wpath cpath inet recvfd
> sendfd prot_exec unix drm ps");
> pref("extensions.pocket.enabled", false);
> pref("browser.newtabpage.enabled", false);
> pref("browser.startup.homepage", "about:blank");
> Index: files/pledge.content
> ===
> RCS file: files/pledge.content
> diff -N files/pledge.content
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ files/pledge.content 25 Sep 2019 16:23:36 -
> @@ -0,0 +1,10 @@
> +stdio
> +rpath
> +wpath
> +cpath
> +recvfd
> +sendfd
> +prot_exec
> +unix
> +drm
> +ps
> Index: files/pledge.gpu
> ===
> RCS file: files/pledge.gpu
> diff -N files/pledge.gpu
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ files/pledge.gpu 25 Sep 2019 16:23:36 -
> @@ -0,0 +1,11 @@
> +stdio
> +rpath
> +wpath
> +cpath
> +ps
> +sendfd
> +recvfd
> +drm
> +dns
> +unix
> +prot_exec
> Index: files/pledge.main
> ===
> RCS file: files/pledge.main
> diff -N files/pledge.main
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ files/pledge.main 25 Sep 2019 16:23:36 -
> @@ -0,0 +1,20 @@
> +stdio
> +rpath
> +wpath
> +cpath
> +inet
> +proc
> +exec
> +prot_exec
> +flock
> +ps
> +sendfd
> +recvfd
> +dns
>
Re: firefox: unveil and pledge enhancements [8]
On Fri, 27 Sep 2019 at 15:40:55 +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 > > > > 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 Oops, I meant to ignore ENOENT in errno, not the return value of unveil. I'll post a new patch that fixes that and also tries to "mkdir -p" that dconf path because if it's not there, firefox does a lot of console spamming.
Re: firefox: unveil and pledge enhancements [8]
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
Re: firefox: unveil and pledge enhancements [8]
joshua stein wrote: Thanks for moving back to a secure approach. > 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. jcs and I have started talking to tedu about this, as the eixsting shm_open() is his design, a design which is now uncomfortable for unveil/pledge.
