On Fri, Apr 4, 2025, 17:36 Nick Couchman <vn...@apache.org> wrote: > On Thu, Apr 3, 2025 at 8:36 PM Cyrus <cyru...@gmail.com> wrote: > >> Hello!, >> >> I'm wondering what's the default protection everyone is applying to >> keystroke logging files. >> >> Since Guacamole cannot know if a bunch of keystrokes comprise a password, >> it's not possible to mask them in the keystroke logging. >> >> I can disable keystroke altogether and leave video recording only to >> cover any data exfiltration if the Guacamole server is compromised, but I >> wonder if there's an intermediate solution like encrypting those files and >> still have "playback in the console" when needed. >> >> > There's not really anything built-in to Guacamole, no, that you could use > to protect against this. And, ultimately what you're asking seems a bit > idealistic: > * You want guacd and guacamole-client (Tomcat) to be able to write > keystrokes to a file and read them back for playback, which requires that > these processes have the correct access to the files. > * However, you want to prevent someone who "compromises" your server from > being able to read these files? > > This largely depends on what you mean by "compromises the server"? If by > that you mean, "gains privileged (root) access," I don't really know what > to tell you - anyone who gains that level of permissions can simply "su - > guacd" (or whatever user guacd is running under) and grab the files. Since > guacd is running under that account, the account has to have access - how > would you simultaneously allow guacd to have access but deny someone else > with root access from moving to that user account and gaining access? There > may be ways to use SELinux and its ides of context to help with this, but, > in the end, it seems like this is asking for something that isn't really > achievable. > > If by "compromises the server" you mean, simply gains access to the > server, under a non-privileged account that isn't guacd and/or > guacamole-client related, then the answer is relatively simple: make sure > permissions are set correctly. > > If by "compromises the server" you mean, walks in and physically steals > the server and hauls it off to their warehouse, then some sort of at-rest > encryption where the key is physically disconnected from the server would > help. > > -Nick >
Hello!, Maybe I just wanted to validate my thinking about this. I totally agree with your comments. Sensitive data is even more exposed through the web UI, more people need to be able to manage/define sessions that people that needs access to the server OS. An "admin without session replay/audit access" would be good enough. Regards. >
