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:
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:
- Authenticating users with LDAP
- Using Guacamole with a MySQL Database
- Using Guacamole with a PostgreSQL Database
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:
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
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: