Fair point that the actual installation does not create the file so the permissions of said file are up to it's creator. I just realized that I had another misconceptions that makes the entire problem moot. I was under the impression that changing the permissions of guacamole.properties would break things as tomcat isn't running as root. But apparently tomcat doesn't care at all, guacd does and guacd runs as root anyway, so it's totally fine to make guacamole.properties not world readable.
That being said, having built-in password hashing/obscuring would still be a great thing to have and this is (in many various ways) a solved problem: Service-Now MID discovery server makes you enter something like: password = encrypt:"PASSWORD", the next time you start the service and re-open the config file, it shows password = encrypted:"PASSWORDHASH" with the hash only working for authentication on that single particular machine/installation. Some software launches as root, reads the configuration and then drops privileges to a more reasonable level for as long as it's running. These 2 approaches make the most sense to me. Others do things like: password = /path/to/file where a password file can have different permissions from the service configuration. - Sincerely, Dan Naumov On Tue, May 5, 2020 at 2:38 PM Nick Couchman <vn...@apache.org> wrote: > > On Tue, May 5, 2020 at 7:12 AM Dan Naumov <dan.nau...@gmail.com> wrote: >> >> Hello folks. >> >> Regardless of whether you use MySQL, Postgres or MSSQL, your >> guacamole.properties configuration file still contains your database >> username and password in plain text so that Guacamole can connect to >> it. Considering the fact that to my understanding, the database itself >> contains connection details, including possible login info in plain >> text and the fact that guacamole.properties is world-readable by >> default, this seems like an extreme security risk. What's the >> appropriate way to hash or otherwise obscure the database password >> while still having Guacamole continue to work? >> > > Short answer: you can't - it must be stored in plain-text. > > TL;DR > The answer to this is to secure your database and you configuration files in > a way that insures that only Guacamole has access to this information. The > reality is that the password has to be stored in a format that it can be used > by the Java application in order to connect, which means that, at best, you > can, as you say, obscure the password. Security by obscurity doesn't add > much real security - it's just making it slightly more difficult to track > down the information, and usually more for yourself than any hacker. > > If you're concerned about the contents of your database being secure (and you > should be): > - Secure root access to your systems. > - Limit who has access to the server running the database and the Guacamole > components > - Limit access to the DB itself using the built-in security for whatever DB > platform you're running > - Use dedicated system accounts for running the various Guacamole components > - Set ownership and permissions appropriately on the configuration files > (/etc/guacamole) > - Encrypt communications where possible (support for configuring encrypted DB > connections is in the works for Guacamole Client) > > You mention that "guacamole.properties is world-readable by default" - this > is entirely up to you, and entirely within your control. Saying it's > world-readable by default implies that we (the Guacamole project) ship a > guacamole.properties that is installed world-readable. Since we (the > project) do not ship any default guacamole.properties, nor do we install a > default one as any part of our installation process, the ownership and > permissions of that file are left entirely up to you. You should absolutely > change this - and i would argue permissions on the entire /etc/guacamole > directory - as part of the process of setting up the software in a secure > fashion. > > -Nick --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@guacamole.apache.org For additional commands, e-mail: user-h...@guacamole.apache.org
