From 67386cd118175ab6452871ceb8c39ff6b5b4c653 Mon Sep 17 00:00:00 2001 From: Solderpunk Date: Thu, 23 Feb 2023 18:57:56 +0100 Subject: [PATCH] Update README to reflect movement of unix security stuff out of config file into command line switches. --- README.md | 37 ++++++++++++++++++------------------- 1 file changed, 18 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index 5a9ba29..fc30482 100644 --- a/README.md +++ b/README.md @@ -107,6 +107,16 @@ command line option to tell Molly Brown where to find it. ### Running +The `molly-brown` executable recognises the following command line +switches: + +* `-c`: Used to specify a config file. +* `-C`: Used to specify a directory to chroot to (unix only). +* `-u`: Used to specify the name of an unprivileged user which + Molly Brown should switch to running as if started as + root or run as a setuid executable (unix only). +* `-v`: Print version number and exit. + Molly Brown does not handle details like daemonising itself, changing the user it runs as, etc. You will need to take care of these tasks by, e.g. integrating Molly Brown with your operating system's init @@ -318,13 +328,14 @@ can be set readable by the user who owns the binary, but not readable by the user who runs the binary. CGI processes will then be unable to read any of those sensitive files. If the binary is not SETUID but is run by the superuser/root, then Molly will change its UID to that of -the `nobody` user before accepting network connections, so CGI -processes will again not be able to read sensitive files. Note that -while these measures can protect Molly's own sensitive files from -CGI processes, CGI processes may still be able to read other sensitive -files anywhere else on the system. Consider chroot()-ing Molly Brown -into a small corner of the filesystem (see `ChrootDir` below) to -reduce this risk. +the `nobody` user (or any other user specified with the `-u` option) +before accepting network connections, so CGI processes will again not +be able to read sensitive files. Note that while these measures can +protect Molly's own sensitive files from CGI processes, CGI processes +may still be able to read other sensitive files anywhere else on the +system. Consider chroot()-ing Molly Brown into a small corner of the +filesystem (see discussion of the `-C` option at the start of the +Running section) to reduce this risk. When compiled on GNU/Linux with Go versions 1.15 or earlier, Molly Brown is completley unable to reliably change its UID due to the way @@ -387,18 +398,6 @@ facility. status code of 60. Requests made with a certificate not in the list will cause a response with a status code of 60. -### Security settings - -* `ChrootDir`: A directory to which Molly Brown should chroot(), - making it more difficult for the server itself or spawned CGI - processes to read or write any files higher in the hiearch. The - chroot happens immediately after reading the config file. All other - paths specified in the config file (e.g. `DocBase`, `KeyPath`, - `AccessLog`) must be specified relative to `ChrootDir`. -* `UnprivUsername`: The username of an unprivileged user on the system - which MollyBrown will change setuid() to if started by the superuser - or when run as a setuid binary (default value "nobody"). - ## .molly files In order to allow users of shared-hosting who do not have access to