[
https://issues.apache.org/jira/browse/GUACAMOLE-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Jumper closed GUACAMOLE-2317.
----------------------------------
Resolution: Invalid
Similar to GUACAMOLE-2305, this is not correct (sending the value of a
parameter from server to client via `argv` does not occur automatically). There
is no need for a filtering mechanism beyond what is already present: don't send
what you don't want to send (and don't register for automatic sending what you
don't want automatically sent).
> guacd should not stream sensitive connection parameters back to the client
> via argv
> -----------------------------------------------------------------------------------
>
> Key: GUACAMOLE-2317
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-2317
> Project: Guacamole
> Issue Type: Improvement
> Reporter: Ciro Iriarte
> Priority: Major
>
> Follow-up to GUACAMOLE-2305 and
> [guacamole-client#1232|https://github.com/apache/guacamole-client/pull/1232].
> When guacd streams a connection parameter back to the client through an
> {{argv}} stream, the client reflects the value into the UI-visible arguments
> model. GUACAMOLE-2305 addresses the *client-side* read exposure (filtering
> sensitive parameter names before reflecting them), but the durable fix is
> server-side: guacd should not stream sensitive values (passwords,
> passphrases, private keys) back to the client at all.
> Today there is no mechanism for this — {{argv}} registration only supports
> {{GUAC_ARGV_OPTION_ONCE}} and {{GUAC_ARGV_OPTION_ECHO}}, with no notion of a
> sensitive / non-echoed parameter. Proposed work:
> * Add a sensitivity / no-reflect concept to the libguac {{argv}} API (e.g. a
> new option flag), or have guacd never stream back a parameter that originated
> from server-side configuration.
> * Adopt it across the protocol implementations that register sensitive
> parameters.
> This is defense-in-depth: mutating an immutable argument toward guacd is
> already rejected server-side, so the concern is what a user can *read*, not
> send. With this in place, the client-side name-matching heuristic in
> GUACAMOLE-2305 becomes a redundant backstop rather than the primary control.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
