[jira] [Comment Edited] (GUACAMOLE-1587) how to intercept high-risk linux command

["Nick Couchman (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GUACAMOLE-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17526830#comment-17526830 ] 

Nick Couchman edited comment on GUACAMOLE-1587 at 4/23/22 11:36 AM:
--------------------------------------------------------------------

I'm not really sure this is feasible...

First, to do this reliably, I would think the terminal would have to wait for you to finish typing your command and press enter before any part of the command was sent to the remote system. Otherwise I'm not sure how you could evaluate that a "high risk" command is being sent - you would have to be able to look back and evaluate the "riskiness" of a command. For example, of the following two commands, one is high risk and one is not:
rm -Rf /
rm -Rf /home/nick/guacamole-server/build

To evaluate this as "high" or "low" risk, Guacamole would have to, upon the user pressing "return", read back the string on the command line and evaluate what it's doing. As it stands today, Guacamole just sends each keystroke and then displays the result - so as soon as you type the "r" for the command "rm -Rf /", the "r" is sent to the remote system and then displayed back to the client.

Beyond that, I would think there would be ways for people to work around it - if Guacamole is evaluating what the user types on the terminal and making decisions about its "safeness", then I would just put the commands in a script in my home directory and run that script with whatever commands I wanted. At this point, Guacamole would have no visibility into what commands are being run.

Maybe you can more thoroughly describe what you're trying to do - what commands you consider "risky" and what exactly you mean by "intercept them"? This seems to me like something that should be handled by the system itself, with privileged user management (sudo, su, pkexec, etc.), or perhaps by a custom shell or shell menu that limits what users can do.


was (Author: nick.couchman@yahoo.com):
I'm not really sure this is feasible...

First, to do this reliably, I would think the terminal would have to wait for you to finish typing your command and press enter before any part of the command was sent to the remote system. Otherwise I'm not sure how you could evaluate that a "high risk" command is being sent - you would have to be able to look back and evaluate the "riskiness" of a command. For example, of the following two commands, one is high risk and one is not:
rm -Rf /
rm -Rf /home/nick/guacamole-server/build

To evaluate this as "high" or "low" risk, Guacamole would have to, upon the user pressing "return", read back the string on the command line and evaluate what it's doing. This sounds like "machine learning" type stuff to me.

Beyond that, I would think there would be ways for people to work around it - if Guacamole is evaluating what the user types on the terminal and making decisions about its "safeness", then I would just put the commands in a script in my home directory and run that script with whatever commands I wanted. At this point, Guacamole would have no visibility into what commands are being run. 

Maybe you can more thoroughly describe what you're trying to do - what commands you consider "risky" and what exactly you mean by "intercept them"? This seems to me like something that should be handled by the system itself, with privileged user management (sudo, su, pkexec, etc.), or perhaps by a custom shell or shell menu that limits what users can do.

> how to intercept high-risk linux command
> ----------------------------------------
>
>                 Key: GUACAMOLE-1587
>                 URL: https://issues.apache.org/jira/browse/GUACAMOLE-1587
>             Project: Guacamole
>          Issue Type: Wish
>            Reporter: yishao
>            Priority: Minor
>
> when I use the guacamole terminal to writting linux command, how to identify and intercept the high-risk one？please help.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)