On Jul 13, 2018, at 2:13 PM, Roy Keene <[email protected]> wrote:
>
> Upgrading from Fossil 2.1 to something more recent hasn't been a priority; I
> have to go through the versions and verify no new features will cause
> problems when hosting untrusted repositories, and I haven't done that.
I guess you’re worried about CSRF, XSS and such?
There was an XSS fix in 2.3, and there’s one still pending for the current
release. I didn’t pay attention to who noticed these problems and wanted these
fixes, but if you’d asked me yesterday, I’d have guessed Chiselapp!
> If you would like to volunteer to do that then it'll go faster ! :-D
Would it be easier to switch to a technology like BSD jails or Illumos zones
that let you run a separate Fossil instance for each customer, so that you
don’t have to worry about how multiple customers’ Fossil instances will
interact?
With Fossil’s option of a single statically-linked executable, you might end up
with only a handful of files in each container, so that the attack surface is
little more than Fossil itself, and if exploited, all you get access to is the
repository data within that single container.
cgroups based containers on Linux (e.g. Docker, though not limited to it) are
reportedly not as strong as BSD jails or Illumos zones:
https://unix.stackexchange.com/questions/127001/linux-lxc-vs-freebsd-jail
https://www.blackhat.com/docs/eu-15/materials/eu-15-Bettini-Vulnerability-Exploitation-In-Docker-Container-Environments-wp.pdf
https://www.reddit.com/r/IAmA/comments/31ny87/i_am_the_cto_of_joyent_the_father_of_dtrace_and/cq414ac
Yet, they may be strong enough for this purpose, given its tight scoping.
chroot() might even be strong enough given the tight scoping. None of the ways
I’m aware of to escape a chroot() apply to a minimal Fossil-in-a-box
configuration. Most of these methods require root access inside the chroot,
and there isn’t cause for that, not even for low-numbered port binding, since
your HTTPS front end could map external URLs to high-numbered internal port
numbers.
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
