Fossil Forum
Post: Fossil complains about /dev/null, /dev/urandom and log file permissions, and vuln-report
Post: Fossil complains about /dev/null, /dev/urandom and log file permissions, and vuln-report
Edit: Fossil complains about /dev/null, /dev/urandom and log file permissions, and vuln-report
Edit: Fossil complains about /dev/null, /dev/urandom and log file permissions, and vuln-report
As suggested, I am using a Linux VPS to host Fossil as a server. So far everything seems okay, except that Fossil complains about not being able to write and read files /dev/null and /dev/urandom when I select the Admin tab, and that it can't write to a log file in /var/log/fossil when I look at the Security Audit. Fossil is running as stand-alone HTTP server, using a systemd system unit service. Looking at the permissions everything looks correct and a normal user has access to /dev/null and /dev/urandom so I am at a loss on how to proceed.
In addition, the security audit complains about vuln-report being log, even after I ran fossil all set vuln-report fatal both as a normal user and as root in the bash shell.
Fossil wants to access /dev/null and /dev/urandom on Linux. But if you run as root, Fossil also drops itself into a chroot jail prior to reading any input off the wire, as an extra layer of security. Once inside the chroot jail, it won't be able to access /dev/null, /dev/urandom, or /var/log/fossil as those are all outside the chroot jail.
See also: https://fossil-scm.org/home/doc/trunk/www/chroot.md
You can work around this by running the "fossil http command" (which is I assume what you are running via systemd in order to serve content) with the --nojail option. The downside there is that if there is ever a RCE found in Fossil (none has been found yet, to my remembrance) then your whole system could be vulnerable. FWIW, the Fossil instance running this forum is inside of a chroot jail.
Note To Devs: I thought we had more documentation about the chroot jail. But a quick search didn't find it. Did it get removed? Is it just not showing up in search? Or is my memory faulty. In any event, we need to work on this deficiency.
Note To Devs: I thought we had more documentation about the chroot jail. But a quick search didn't find it. Did it get removed?
To the best of my fallible recollection, what we have now is what we've had for years. The althttpd docs make some mention of it, but fossil's goes into more detail.
In any event, we need to work on this deficiency.
What more needs to be said than what's in www/chroot.md and the docs it links to (without writing a generic chroot tutorial, with which the internet is littered)?
I thought we had more documentation about the chroot jail.
The chroot.md document that you linked to seems to cover the core points, however, what specifically do you think is missing? It is linked to from:
https://fossil-scm.org/home/doc/trunk/www/server/debian/service.md
Which discusses how to use systemd to run Fossil and is in turn linked to from the Quick Start Guide:
https://fossil-scm.org/home/doc/trunk/www/quickstart.wiki
So presumably if someone starts from the Quick Start Guide and works their way through following the recommendations they eventually get to the discussion about chroot. Maybe it should be more prominent?
The downside there is that if there is ever a RCE found in Fossil (none has been found yet, to my remembrance) then your whole system could be vulnerable.
Only if Fossil is running as root. In one configuration that I use with daemontools, I have something like the following:
!/bin/sh
exec 2>&1 exec softlimit -m2000000 tcpserver \ -vDRHl0 172.19.23.7 8080 chroot -u _fossil /var/fossil /usr/local/bin/fossil http /fossils
So the chroot command itself imposes the chroot---which by the way does also have a /dev/null and /dev/{u,}random devices---so even if there is a flaw found in "fossil http", it's still locked down.
exec ... -vDRH...
That's a pretty wild coincidence ;).
That's a pretty wild coincidence ;).
Indeed it is and completely unintentional. I didn't even notice it until you pointed it out because I pretty much just copied and pasted the script from my server (changing only the IP). The meaning of those options are documented here:
https://cr.yp.to/ucspi-tcp/tcpserver.html
Reply: Fossil complains about /dev/null, /dev/urandom and log file permissions, and vuln-report
I created a user for fossil and after setting appropriate permissions, file access works. Your chroot jail hint is what got me to figure it out, thank you.
I was using fossil server. I only realized the fossil http command existed once I read your post. The only activation methods on the How To Configure A Fossil Server page I tried were CGI and as a Stand-alone HTTP server. I didn't fully try CGI because I figured the Stand-alone HTTP server method was the easiest. Also, I'm not using Docker or other similar containerized service.
Maybe Standalone HTTP Server could briefly mention that running fossil server as root will drop fossil into the chroot jail, and link to The Server Chroot Jail .
EDIT: Fixed the vuln-report issue, to set it using fossil all calling fossil open was needed so it would be added to .fossil . I could have used fossil set -R <repository file> instead, but what I found on the forum about setting vuln-report used fossil all, plus I couldn't find the -R switch in the documentation for fossil set.
I'm not using Docker or other similar containerized service.
Consider it. You avoid much of the trouble you ran into this way.
My fslsrv script makes it about as cookie-cutter as you can reasonably ask.
Yes, it buys new complexities, but with commensurate compensating benefits.
I created a user for fossil
That’s unnecessary under my scheme.
Z