The packages provided by Glyptodon Enterprise have been designed to follow best practices with respect to security, particularly with respect to the Principle of Least Privilege. This is accomplished through careful delegation of rights through users and groups which are automatically created by the Glyptodon Enterprise packages, and through strict file permissions.

The Glyptodon team actively monitors the upstream Apache Guacamole project for newly-disclosed security vulnerabilities, and has procedures in place for releasing security updates outside the normal release cycle. Should a vulnerability be found in Guacamole, the patch for that vulnerability will made be immediately available through the Glyptodon Enterprise repository, and can be applied automatically using the upgrade process of your package manager:

$ sudo yum upgrade

Important Configuration Details for Production

Once ready to deploy Glyptodon Enterprise to production, it is critically important to configure SSL encryption. It is not safe to operate any remote desktop software without proper encryption, including Guacamole. You will need to obtain an SSL certificate for your server such that all Guacamole traffic is encrypted. To configure SSL encryption in front of Guacamole, we recommend using a reverse proxy like Apache or Nginx. We provide documentation for configuring either of these reverse proxies for Glyptodon Enterprise:

In addition, as the user-mapping.xml authentication mechanism is meant only as a quick means of testing Guacamole (it is not supported for production deployments), you will need to migrate to a production-ready authentication mechanism. All authentication methods  packaged within Glyptodon Enterprise and which are not user-mapping.xml are production-ready:

If you wish to enable multi-factor authentication in front of Guacamole, you may do so with Duo. Multi-factor authentication is supported in front of any of the above production-ready authentication mechanisms:

Service/System Accounts and Groups

The Glyptodon Enterprise packages create the following users and groups in order to limit the access of services within the Guacamole stack:

  • The "guacamole" group - owns all files which the Guacamole web application should be able to read.
  • The "guacd" group - owns all files which the guacd service should be able to read.
  • The "guacd" user - the sole member of the "guacd" group, and the user which runs the guacd service.

After deploying Guacamole under Tomcat, you will need to ensure the "tomcat" user is a member of the "guacamole" group. If this is not done, the Guacamole web application will not be able to read its own configuration files, and web application startup will fail:

$ sudo usermod -aG guacamole tomcat

The "guacd" user and group are intentionally limited in privilege. If you need guacd to have access to additional files or directories, such as for file transfer or storing session recordings, you will need to set the ownership and permissions of those files appropriately.

Users and File Ownership

The ownership and permissions of sensitive files like guacamole.properties, user-mapping.xml, and guacd.conf have been set such that only the components of the Apache Guacamole stack that should be able to read those files can read those files, and such that no component within the Guacamole stack can write or otherwise modify those files:

$ ls -l /etc/guacamole/
total 20
drwxr-xr-x. 2 root root      47    Apr 27 23:17 extensions
-rw-r-----. 1 root guacamole 10748 Jun 24  2017 guacamole.properties
-rw-r-----. 1 root guacd     1334  Apr 26 05:18 guacd.conf
drwxr-xr-x. 2 root root      32    Apr 27 23:17 lib
-rw-r-----. 1 root guacamole 1938  Apr 27 22:40 user-mapping.xml
$