guacamole-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Couchman <vn...@apache.org>
Subject Re: guacd not starting on boot
Date Mon, 11 Mar 2019 11:06:40 GMT
On Sun, Mar 10, 2019 at 11:04 PM Robert Dinse <nanook@eskimo.com> wrote:

>
>       Ok, rebuilt with the correct --with-systemd-dir=/lib/systemd/system
> and
> now I had more problems.  Launched out of init.d it ran as root, launced
> out
> of systemd, the unit file it created has User=daemon so it runs as daemon.
> Problem with that is only root has access to /var/run and to the
> encryption key
> file so I changed it back to root despite that being less secure.
>

Or you could change permissions on the files so that the daemon user has
access to them.  For the encryption key, this should be pretty
straight-forward:

chown daemon /path/to/encryption/key

For /var/run, I'm not sure why the daemon user would need access to that
directory?  I suppose it could if you're adding "-p /var/run/guacd.pid" to
the command line or specifying a PID file in the guacd configuration, but
by default there are no requirements for this.  Furthermore, with systemd
in particular, I'm not sure that's there much value to having it generate a
PID - system runs things in the foreground by default and manages tracking
the PID of the daemon, so there's really not much you'd need the PID file
for.

If you do want that PID file in /var/run, for whatever reason, in most
distributions that run systemd /var/run is managed by tmpfilesd, and can be
configured by adding the appropriate file to /etc/tmpfiles.d with the files
and/or directories and the required ownership and permissions.


>
>       Lastly it still failed because it tried to start before /misc was
> mounted
> which is where the key file was so I modified the unit file line:
>
> After=network.target
>
>     to:
>
> After=network.target misc.mount
>
>      /misc is the file system where I have the encryption certs and keys.
>
>      Now it starts properly after a reboot.  Downside, as with when it ran
> out of /etc/init.d, it is running as root which from a security perspective
> is undesirable.
>

But, this is your choice, not a requirement - you've changed it from daemon
to root to resolve other issues that should be resolved with either a chown
(or ACLs) and proper configuration.


>
>      What guacd should have is an item that goes into guacd.conf for user
> and
> group so it can start as root, write the pid file and read the necessary
> cert and key files, and then switch to said user and group just like Apache
> httpd and tomcat do.
>

httpd does this, Tomcat does not.  Tomcat is started by the startup.sh
script, and that script must be run under the account that you want running
Tomcat.  Tomcat does not implement user context switching at startup, and
should (IMHO) *never* be started as root.


>
>      Then it could be both secure and functional.
>

There may be some value to looking into doing this - having the initial
user be root and then switch to another user - but please understand that
it is not required to make guacd both "secure and functional" as it is
implemented today.  There is no reason at all that you cannot set
permissions on all of the required items - GUACAMOLE_HOME (/etc/guacamole),
encryption keys and certificates, and the necessary /var/run entries - to
the user specified in either the init script or the systemd file (+
tmpfiles.d) so that guacd runs under a non-root account.  You don't have to
use the daemon user if you don't want to - this was a convenient default
for the systemd unit file when we added it - you can create a separate user
for guacamole (I often use "guac") and change permissions to that user
along with the systemd script, and you will be able to operate in both a
"secure and functional" fashion.

Furthermore, there are other methods you could use to protect guacd and the
required files, like chroot jails or Docker containers.  Docker is already
available, and, while chroot jails are not implemented by default, the
requirements for guacd are reasonably simple enough that it should be
doable with minimal effort.

The point here is that, while there may be some value to having guacd start
under root and switch internally, there's no reason you have to do this in
order to make guacd function and function securely.

-Nick

Mime
View raw message