QSB #38: Qrexec policy bypass and possible information leak
99 views
Skip to first unread message
Marek Marczykowski-Górecki
Feb 19, 2018, 7:50:17 PM2/19/18
to qubes-announce, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #38:
Qrexec policy bypass and possible information leak.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #38 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt>
Learn about the qubes-secpack, including how to obtain, verify, and read it:
<https://www.qubes-os.org/security/pack/>
View all past QSBs:
<https://www.qubes-os.org/security/bulletins/>
```
---===[ Qubes Security Bulletin #38 ]===---
February 20, 2018
Qrexec policy bypass and possible information leak
Summary
========
One of our developers, Wojtek Porczyk, discovered a vulnerability in the way
qube names are handled, which can result in qrexec policies being bypassed, a
theoretical information leak, and possibly other vulnerabilities. The '$'
character, when part of a qrexec RPC name and/or destination
specification (like '$adminvm', '$default', or one of the variants of
'$dispvm') is expanded according to shell parameter expansion [1]
after evaluating the qrexec policy but before invoking the RPC handler
executable.
Impact
=======
1. Potential policy bypass. The qrexec argument value that is delivered to the
handler executable can be different from the value that is present in the
RPC policy at the time the policy is evaluated. This is especially
problematic when the policy is defined as a blacklist of arguments rather
than a whitelist, e.g. "permit any arguments to example.Call but
PROHIBITED". If an attacker were to call 'example.Call+PROHIBITED$invalid',
the argument would not match the blacklisted variable at the time of policy
evaluation, so it would be admitted. However, performing shell parameter
expansion on the argument results in the prohibited value, which is what the
actual handler receives.
2. Potential information leak. If the qrexec handler acts upon the argument,
the attacker could read or deduce the contents of those variables.
3. Other potential vulnerabilities. Some of the variables present in the
environment, like $HOME and $PATH, also contain characters that are not
permissible in qrexec names or arguments that could theoretically lead to
other classes of vulnerabilities, such as directory traversal.
Technical details
==================
The '$' character is used in several places in qrexec and is therefore an
allowed character in parameters to Qubes RPC calls. It is also allowed as part
of the RPC name. The validation code is as follows [2]:
static void sanitize_name(char * untrusted_s_signed, char *extra_allowed_chars)
{
unsigned char * untrusted_s;
for (untrusted_s=(unsigned char*)untrusted_s_signed; *untrusted_s; untrusted_s++) {
if (*untrusted_s >= 'a' && *untrusted_s <= 'z')
continue;
if (*untrusted_s >= 'A' && *untrusted_s <= 'Z')
continue;
if (*untrusted_s >= '0' && *untrusted_s <= '9')
continue;
if (*untrusted_s == '$' ||
*untrusted_s == '_' ||
*untrusted_s == '-' ||
*untrusted_s == '.')
continue;
if (extra_allowed_chars && strchr(extra_allowed_chars, *untrusted_s))
continue;
*untrusted_s = '_';
}
}
and is invoked as [3]:
sanitize_name(untrusted_params.service_name, "+");
sanitize_name(untrusted_params.target_domain, ":");
Those arguments are part of the basis of policy evaluation. If policy
evaluation was successful, the parameters are then forwarded to the destination
domain over qrexec, and the call is executed using the qubes-rpc-multiplexer
executable, which is invoked by a POSIX shell. The exact mechanism differs
between dom0 and other qubes [4]:
if self.target == 'dom0':
cmd = '{multiplexer} {service} {source} {original_target}'.format(
multiplexer=QUBES_RPC_MULTIPLEXER_PATH,
service=self.service,
source=self.source,
original_target=self.original_target)
else:
cmd = '{user}:QUBESRPC {service} {source}'.format(
user=(self.rule.override_user or 'DEFAULT'),
service=self.service,
source=self.source)
# ...
try:
subprocess.call([QREXEC_CLIENT] + qrexec_opts + [cmd])
For the dom0 case, these are the relevant parts from the executable referenced
as QREXEC_CLIENT above [5]:
/* called from do_fork_exec */
void do_exec(const char *prog)
{
execl("/bin/bash", "bash", "-c", prog, NULL);
}
/* ... */
static void prepare_local_fds(char *cmdline)
{
/* ... */
do_fork_exec(cmdline, &local_pid, &local_stdin_fd, &local_stdout_fd,
NULL);
}
/* ... */
int main(int argc, char **argv)
{
/* ... */
if (strcmp(domname, "dom0") == 0) {
/* ... */
prepare_local_fds(remote_cmdline);
For qubes other than dom0, the command line is reconstructed from the command
passed through qrexec [6]:
void do_exec(const char *cmd)
{
char buf[strlen(QUBES_RPC_MULTIPLEXER_PATH) + strlen(cmd) - RPC_REQUEST_COMMAND_LEN + 1];
char *realcmd = index(cmd, ':'), *user;
/* ... */
/* replace magic RPC cmd with RPC multiplexer path */
if (strncmp(realcmd, RPC_REQUEST_COMMAND " ", RPC_REQUEST_COMMAND_LEN+1)==0) {
strcpy(buf, QUBES_RPC_MULTIPLEXER_PATH);
strcpy(buf + strlen(QUBES_RPC_MULTIPLEXER_PATH), realcmd + RPC_REQUEST_COMMAND_LEN);
realcmd = buf;
}
/* ... */
#ifdef HAVE_PAM
/* ... */
shell_basename = basename (pw->pw_shell);
/* this process is going to die shortly, so don't care about freeing */
arg0 = malloc (strlen (shell_basename) + 2);
/* ... */
/* FORK HERE */
child = fork ();
switch (child) {
case -1:
goto error;
case 0:
/* child */
if (setgid (pw->pw_gid))
exit(126);
if (setuid (pw->pw_uid))
exit(126);
setsid();
/* This is a copy but don't care to free as we exec later anyways. */
env = pam_getenvlist (pamh);
execle(pw->pw_shell, arg0, "-c", realcmd, (char*)NULL, env);
/* ... */
#else
execl("/bin/su", "su", "-", user, "-c", realcmd, NULL);
perror("execl");
exit(1);
#endif
Notice that the '$' character is unescaped in all cases when it is passed to
the shell and is interpreted according to the rules of parameter expansion [1].
Mitigating factors
===================
Only the '$' shell special character character was allowed, so only the
corresponding simple form of parameter expansion is permitted [1]. The '{}'
characters are prohibited, so other forms of parameter expansion are not
possible. Had other characters like '()', been permitted, which is not the
case, this vulnerability would amount to code execution.
The qrexec calls that are present in a default Qubes OS installation and that
have, by default, a policy that would actually allow them to be called:
- do not contain the '$' character; and
- do not act upon differences in their arguments.
Therefore, this vulnerability is limited to custom RPCs and/or custom policies.
The attacker is constrained to preexisting environment variables and shell
special variables, which do not appear to contain very valuable information.
Since writing policies in the blacklist paradigm is a poor security practice in
general, it is perhaps less common among the security-conscious Qubes userbase.
All users who write custom RPCs or policies are henceforth advised to adopt the
whitelist paradigm.
Resolution
===========
We've decided to deprecate the '$' character from qrexec-related usage.
Instead, to denote special tokens, we will use the '@' character,
which we believe is less likely to be interpreted in a special way
by the relevant software.
This is a forward-incompatible change for existing systems, specifically in
policy syntax, remote domain parameters to the qrexec-client and
qrexec-client-vm tools, and the API exposed to the qrexec handler script. In
order to maintain backward compatibility, these tools will accept older
keywords while parsing policy and command line parameters, then translate them
to the new keywords before evaluating the policy or invoking the actual call,
respectively.
It will no longer be possible to define calls and receive arguments containing
the '$' character. However, we believe that no such calls exist. Had they
existed, this bug would have been disclosed earlier.
In addition, the shell will not be used to call qubes-rpc-multiplexer.
The environment variable specifying the original target qube will also be
specified differently for cases that, in the past, would have contained the '$'
character. However, this wasn't working as specified anyway, so we believe the
impact of this change to be minimal. The new variables will be as follows:
- - QREXEC_REQUESTED_TARGET_TYPE
with value of either 'name' or 'keyword'
- - QREXEC_REQUESTED_TARGET
set only when QREXEC_REQUESTED_TARGET_TYPE set to 'name'
- - QREXEC_REQUESTED_TARGET_KEYWORD
set only when QREXEC_REQUESTED_TARGET_TYPE set to 'keyword'
Patching
=========
The specific packages that resolve the problem discussed in this bulletin are
as follows:
For Qubes 3.2, dom0:
- qubes-utils 3.2.7
- qubes-core-dom0-linux 3.2.17
For Qubes 3.2, domUs:
- qubes-utils 3.2.7
- qubes-core-vm (Fedora) / qubes-core-agent (Debian) 3.2.24
For Qubes 4.0, dom0:
- qubes-utils 4.0.16
- qubes-core-dom0 4.0.23
- qubes-core-dom0-linux 4.0.11
For Qubes 4.0, domUs:
- qubes-utils 4.0.16
- qubes-core-agent 4.0.22
The packages for dom0 are to be installed in dom0 via the Qubes VM Manager or
via the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
The packages for domUs are to be installed in TemplateVMs and StandaloneVMs via
the Qubes VM Manager or via the respective package manager:
For updates to Fedora from the stable repository (not immediately available):
$ sudo dnf update
For updates to Fedora from the security-testing repository:
$ sudo dnf update --enablerepo=qubes-vm-*-security-testing
For updates to Debian from the stable repository (not immediately available):
$ sudo apt update && sudo apt dist-upgrade
For updates to Debian from the security-testing repository:
First, uncomment the line below "Qubes security updates testing repository" in
/etc/apt/sources.list.d/qubes-r*.list
Then:
$ sudo apt update && sudo apt dist-upgrade
A restart is required for these changes to take effect. In the case of dom0,
this entails a full system restart. In the case of TemplateVMs, this entails
shutting down the TemplateVM before restarting all the TemplateBasedVMs based
on that TemplateVM.
These packages will migrate from the security-testing repository to the current
(stable) repository over the next two weeks after being tested by the
community.
Timeline
=========
2011-07-22 Commit c23cc48 permits '$' character [7].
2016-03-27 Commit 0607d90 introduces qrexec arguments [8][9].
2018-02-14 The vulnerability is discovered and reported internally.
2018-02-20 The vulnerability is patched, and this bulletin is released.
Credits
========
The issue was discovered by Wojtek Porczyk.
References
===========
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
[2] https://github.com/QubesOS/qubes-core-admin-linux/blob/v4.0.10/qrexec/qrexec-daemon.c#L643-L662
[3] https://github.com/QubesOS/qubes-core-admin-linux/blob/v4.0.10/qrexec/qrexec-daemon.c#L685-L686
[4] https://github.com/QubesOS/qubes-core-admin/blob/v4.0.22/qubespolicy/__init__.py#L452
[5] https://github.com/QubesOS/qubes-core-admin-linux/blob/v4.0.10/qrexec/qrexec-daemon.c
[6] https://github.com/QubesOS/qubes-core-agent-linux/blob/v4.0.21/qrexec/qrexec-agent.c#L136
[7] https://github.com/QubesOS/qubes-core-admin/commit/c23cc48#diff-3aa52ac2dd3e25700efd40e77b02b2d0
[8] https://github.com/QubesOS/qubes-core-admin-linux/commit/0607d90
[9] https://github.com/QubesOS/qubes-issues/issues/1876
- --
The Qubes Security Team
https://www.qubes-os.org/security/
```
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqLcJkACgkQ24/THMrX
1yz3vgf/Z+EGbCuLA/ZNH0KmDKZdtv1Zn1iO7lbVlsmN7vxdFiZaGX0m1oEj7czR
pNRCk6UE9w+ZSzD2UbKiq5RXBeZ/sMm4CsaDZmfOi0HdKEJbDvPa+S9jx7l8Zlu3
kVgtfBRgl+YNfjC8A1szAsuE3c2xuynvQmAjDTYLjsX/LekqORW+EL7xEkTyfH8a
Ijub5N3gyK97Wmu4MHuXqZwvMnirn9BzCL2r4aZKh24LIcXVA70qxQd4+Bg0qRgQ
6ZQttdR8dJVdlPbKrB+ob9uuOYX3syh2r6l54UBMzdTcqMMMSBv+5GJ8SCumVX5U
Lv5kbQjCKTlAR2c/s+kw2YmmdrSk1w==
=uOOl
-----END PGP SIGNATURE-----
Hash: SHA256
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #38:
Qrexec policy bypass and possible information leak.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).
View QSB #38 in the qubes-secpack:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt>
Learn about the qubes-secpack, including how to obtain, verify, and read it:
<https://www.qubes-os.org/security/pack/>
View all past QSBs:
<https://www.qubes-os.org/security/bulletins/>
```
---===[ Qubes Security Bulletin #38 ]===---
February 20, 2018
Qrexec policy bypass and possible information leak
Summary
========
One of our developers, Wojtek Porczyk, discovered a vulnerability in the way
qube names are handled, which can result in qrexec policies being bypassed, a
theoretical information leak, and possibly other vulnerabilities. The '$'
character, when part of a qrexec RPC name and/or destination
specification (like '$adminvm', '$default', or one of the variants of
'$dispvm') is expanded according to shell parameter expansion [1]
after evaluating the qrexec policy but before invoking the RPC handler
executable.
Impact
=======
1. Potential policy bypass. The qrexec argument value that is delivered to the
handler executable can be different from the value that is present in the
RPC policy at the time the policy is evaluated. This is especially
problematic when the policy is defined as a blacklist of arguments rather
than a whitelist, e.g. "permit any arguments to example.Call but
PROHIBITED". If an attacker were to call 'example.Call+PROHIBITED$invalid',
the argument would not match the blacklisted variable at the time of policy
evaluation, so it would be admitted. However, performing shell parameter
expansion on the argument results in the prohibited value, which is what the
actual handler receives.
2. Potential information leak. If the qrexec handler acts upon the argument,
the attacker could read or deduce the contents of those variables.
3. Other potential vulnerabilities. Some of the variables present in the
environment, like $HOME and $PATH, also contain characters that are not
permissible in qrexec names or arguments that could theoretically lead to
other classes of vulnerabilities, such as directory traversal.
Technical details
==================
The '$' character is used in several places in qrexec and is therefore an
allowed character in parameters to Qubes RPC calls. It is also allowed as part
of the RPC name. The validation code is as follows [2]:
static void sanitize_name(char * untrusted_s_signed, char *extra_allowed_chars)
{
unsigned char * untrusted_s;
for (untrusted_s=(unsigned char*)untrusted_s_signed; *untrusted_s; untrusted_s++) {
if (*untrusted_s >= 'a' && *untrusted_s <= 'z')
continue;
if (*untrusted_s >= 'A' && *untrusted_s <= 'Z')
continue;
if (*untrusted_s >= '0' && *untrusted_s <= '9')
continue;
if (*untrusted_s == '$' ||
*untrusted_s == '_' ||
*untrusted_s == '-' ||
*untrusted_s == '.')
continue;
if (extra_allowed_chars && strchr(extra_allowed_chars, *untrusted_s))
continue;
*untrusted_s = '_';
}
}
and is invoked as [3]:
sanitize_name(untrusted_params.service_name, "+");
sanitize_name(untrusted_params.target_domain, ":");
Those arguments are part of the basis of policy evaluation. If policy
evaluation was successful, the parameters are then forwarded to the destination
domain over qrexec, and the call is executed using the qubes-rpc-multiplexer
executable, which is invoked by a POSIX shell. The exact mechanism differs
between dom0 and other qubes [4]:
if self.target == 'dom0':
cmd = '{multiplexer} {service} {source} {original_target}'.format(
multiplexer=QUBES_RPC_MULTIPLEXER_PATH,
service=self.service,
source=self.source,
original_target=self.original_target)
else:
cmd = '{user}:QUBESRPC {service} {source}'.format(
user=(self.rule.override_user or 'DEFAULT'),
service=self.service,
source=self.source)
# ...
try:
subprocess.call([QREXEC_CLIENT] + qrexec_opts + [cmd])
For the dom0 case, these are the relevant parts from the executable referenced
as QREXEC_CLIENT above [5]:
/* called from do_fork_exec */
void do_exec(const char *prog)
{
execl("/bin/bash", "bash", "-c", prog, NULL);
}
/* ... */
static void prepare_local_fds(char *cmdline)
{
/* ... */
do_fork_exec(cmdline, &local_pid, &local_stdin_fd, &local_stdout_fd,
NULL);
}
/* ... */
int main(int argc, char **argv)
{
/* ... */
if (strcmp(domname, "dom0") == 0) {
/* ... */
prepare_local_fds(remote_cmdline);
For qubes other than dom0, the command line is reconstructed from the command
passed through qrexec [6]:
void do_exec(const char *cmd)
{
char buf[strlen(QUBES_RPC_MULTIPLEXER_PATH) + strlen(cmd) - RPC_REQUEST_COMMAND_LEN + 1];
char *realcmd = index(cmd, ':'), *user;
/* ... */
/* replace magic RPC cmd with RPC multiplexer path */
if (strncmp(realcmd, RPC_REQUEST_COMMAND " ", RPC_REQUEST_COMMAND_LEN+1)==0) {
strcpy(buf, QUBES_RPC_MULTIPLEXER_PATH);
strcpy(buf + strlen(QUBES_RPC_MULTIPLEXER_PATH), realcmd + RPC_REQUEST_COMMAND_LEN);
realcmd = buf;
}
/* ... */
#ifdef HAVE_PAM
/* ... */
shell_basename = basename (pw->pw_shell);
/* this process is going to die shortly, so don't care about freeing */
arg0 = malloc (strlen (shell_basename) + 2);
/* ... */
/* FORK HERE */
child = fork ();
switch (child) {
case -1:
goto error;
case 0:
/* child */
if (setgid (pw->pw_gid))
exit(126);
if (setuid (pw->pw_uid))
exit(126);
setsid();
/* This is a copy but don't care to free as we exec later anyways. */
env = pam_getenvlist (pamh);
execle(pw->pw_shell, arg0, "-c", realcmd, (char*)NULL, env);
/* ... */
#else
execl("/bin/su", "su", "-", user, "-c", realcmd, NULL);
perror("execl");
exit(1);
#endif
Notice that the '$' character is unescaped in all cases when it is passed to
the shell and is interpreted according to the rules of parameter expansion [1].
Mitigating factors
===================
Only the '$' shell special character character was allowed, so only the
corresponding simple form of parameter expansion is permitted [1]. The '{}'
characters are prohibited, so other forms of parameter expansion are not
possible. Had other characters like '()', been permitted, which is not the
case, this vulnerability would amount to code execution.
The qrexec calls that are present in a default Qubes OS installation and that
have, by default, a policy that would actually allow them to be called:
- do not contain the '$' character; and
- do not act upon differences in their arguments.
Therefore, this vulnerability is limited to custom RPCs and/or custom policies.
The attacker is constrained to preexisting environment variables and shell
special variables, which do not appear to contain very valuable information.
Since writing policies in the blacklist paradigm is a poor security practice in
general, it is perhaps less common among the security-conscious Qubes userbase.
All users who write custom RPCs or policies are henceforth advised to adopt the
whitelist paradigm.
Resolution
===========
We've decided to deprecate the '$' character from qrexec-related usage.
Instead, to denote special tokens, we will use the '@' character,
which we believe is less likely to be interpreted in a special way
by the relevant software.
This is a forward-incompatible change for existing systems, specifically in
policy syntax, remote domain parameters to the qrexec-client and
qrexec-client-vm tools, and the API exposed to the qrexec handler script. In
order to maintain backward compatibility, these tools will accept older
keywords while parsing policy and command line parameters, then translate them
to the new keywords before evaluating the policy or invoking the actual call,
respectively.
It will no longer be possible to define calls and receive arguments containing
the '$' character. However, we believe that no such calls exist. Had they
existed, this bug would have been disclosed earlier.
In addition, the shell will not be used to call qubes-rpc-multiplexer.
The environment variable specifying the original target qube will also be
specified differently for cases that, in the past, would have contained the '$'
character. However, this wasn't working as specified anyway, so we believe the
impact of this change to be minimal. The new variables will be as follows:
- - QREXEC_REQUESTED_TARGET_TYPE
with value of either 'name' or 'keyword'
- - QREXEC_REQUESTED_TARGET
set only when QREXEC_REQUESTED_TARGET_TYPE set to 'name'
- - QREXEC_REQUESTED_TARGET_KEYWORD
set only when QREXEC_REQUESTED_TARGET_TYPE set to 'keyword'
Patching
=========
The specific packages that resolve the problem discussed in this bulletin are
as follows:
For Qubes 3.2, dom0:
- qubes-utils 3.2.7
- qubes-core-dom0-linux 3.2.17
For Qubes 3.2, domUs:
- qubes-utils 3.2.7
- qubes-core-vm (Fedora) / qubes-core-agent (Debian) 3.2.24
For Qubes 4.0, dom0:
- qubes-utils 4.0.16
- qubes-core-dom0 4.0.23
- qubes-core-dom0-linux 4.0.11
For Qubes 4.0, domUs:
- qubes-utils 4.0.16
- qubes-core-agent 4.0.22
The packages for dom0 are to be installed in dom0 via the Qubes VM Manager or
via the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
The packages for domUs are to be installed in TemplateVMs and StandaloneVMs via
the Qubes VM Manager or via the respective package manager:
For updates to Fedora from the stable repository (not immediately available):
$ sudo dnf update
For updates to Fedora from the security-testing repository:
$ sudo dnf update --enablerepo=qubes-vm-*-security-testing
For updates to Debian from the stable repository (not immediately available):
$ sudo apt update && sudo apt dist-upgrade
For updates to Debian from the security-testing repository:
First, uncomment the line below "Qubes security updates testing repository" in
/etc/apt/sources.list.d/qubes-r*.list
Then:
$ sudo apt update && sudo apt dist-upgrade
A restart is required for these changes to take effect. In the case of dom0,
this entails a full system restart. In the case of TemplateVMs, this entails
shutting down the TemplateVM before restarting all the TemplateBasedVMs based
on that TemplateVM.
These packages will migrate from the security-testing repository to the current
(stable) repository over the next two weeks after being tested by the
community.
Timeline
=========
2011-07-22 Commit c23cc48 permits '$' character [7].
2016-03-27 Commit 0607d90 introduces qrexec arguments [8][9].
2018-02-14 The vulnerability is discovered and reported internally.
2018-02-20 The vulnerability is patched, and this bulletin is released.
Credits
========
The issue was discovered by Wojtek Porczyk.
References
===========
[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02
[2] https://github.com/QubesOS/qubes-core-admin-linux/blob/v4.0.10/qrexec/qrexec-daemon.c#L643-L662
[3] https://github.com/QubesOS/qubes-core-admin-linux/blob/v4.0.10/qrexec/qrexec-daemon.c#L685-L686
[4] https://github.com/QubesOS/qubes-core-admin/blob/v4.0.22/qubespolicy/__init__.py#L452
[5] https://github.com/QubesOS/qubes-core-admin-linux/blob/v4.0.10/qrexec/qrexec-daemon.c
[6] https://github.com/QubesOS/qubes-core-agent-linux/blob/v4.0.21/qrexec/qrexec-agent.c#L136
[7] https://github.com/QubesOS/qubes-core-admin/commit/c23cc48#diff-3aa52ac2dd3e25700efd40e77b02b2d0
[8] https://github.com/QubesOS/qubes-core-admin-linux/commit/0607d90
[9] https://github.com/QubesOS/qubes-issues/issues/1876
- --
The Qubes Security Team
https://www.qubes-os.org/security/
```
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqLcJkACgkQ24/THMrX
1yz3vgf/Z+EGbCuLA/ZNH0KmDKZdtv1Zn1iO7lbVlsmN7vxdFiZaGX0m1oEj7czR
pNRCk6UE9w+ZSzD2UbKiq5RXBeZ/sMm4CsaDZmfOi0HdKEJbDvPa+S9jx7l8Zlu3
kVgtfBRgl+YNfjC8A1szAsuE3c2xuynvQmAjDTYLjsX/LekqORW+EL7xEkTyfH8a
Ijub5N3gyK97Wmu4MHuXqZwvMnirn9BzCL2r4aZKh24LIcXVA70qxQd4+Bg0qRgQ
6ZQttdR8dJVdlPbKrB+ob9uuOYX3syh2r6l54UBMzdTcqMMMSBv+5GJ8SCumVX5U
Lv5kbQjCKTlAR2c/s+kw2YmmdrSk1w==
=uOOl
-----END PGP SIGNATURE-----
Tom Zander
Feb 20, 2018, 7:21:37 AM2/20/18
to qubes-users, qubes-devel
On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> We've decided to deprecate the '$' character from qrexec-related usage.
> Instead, to denote special tokens, we will use the '@' character,
> which we believe is less likely to be interpreted in a special way
> by the relevant software.
I would argue against the @ sign on account that it is a special character
> We've decided to deprecate the '$' character from qrexec-related usage.
> Instead, to denote special tokens, we will use the '@' character,
> which we believe is less likely to be interpreted in a special way
> by the relevant software.
in bash as well.
Search for it here;
https://linux.die.net/man/1/bash
I don't immediately see a way to exploit it, but why risk it?
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Wojtek Porczyk
Feb 20, 2018, 8:04:16 AM2/20/18
to Tom Zander, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> > We've decided to deprecate the '$' character from qrexec-related usage.
> > Instead, to denote special tokens, we will use the '@' character,
> > which we believe is less likely to be interpreted in a special way
> > by the relevant software.
>
> I would argue against the @ sign on account that it is a special character
> in bash as well.
>
> Search for it here;
> https://linux.die.net/man/1/bash
> I don't immediately see a way to exploit it, but why risk it?
We absolutely need a special character that is not allowed in qube name to
> On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> > We've decided to deprecate the '$' character from qrexec-related usage.
> > Instead, to denote special tokens, we will use the '@' character,
> > which we believe is less likely to be interpreted in a special way
> > by the relevant software.
>
> I would argue against the @ sign on account that it is a special character
> in bash as well.
>
> Search for it here;
> https://linux.die.net/man/1/bash
> I don't immediately see a way to exploit it, but why risk it?
make the special tokens immediately obvious in policy. The process I used was
to list available characters (POSIX Portable Character Set [1]) and substract
the characters that are special to some relevant things:
- - qube name: a-z A-Z 0-9 _ -
- - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
- - POSIX shell reserved words [3]: ! { }
- - non-POSIX things [3]: [ ]
- - special qrexec character: +
- - path separators (POSIX and NT): / \ :
- - regular expressions: ^. (and other already excluded)
This leaves: '\0\a\b,@'. The point is, all characters are special to
something. I'm sure if I searched for more "special" characters, I'd find them
('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
',' we use in other context in policy). So I stopped there and by consensus we
picked '@'.
If I missed something, could you please point out? I know shell just good
enough to know that it's not possible to know every shell quirk. :)
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
[2] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
[3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
/PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
t9joU8uqhcS4Wt6nA9lh
=EN6G
-----END PGP SIGNATURE-----
donoban
Feb 20, 2018, 9:18:31 AM2/20/18
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
Hash: SHA256
After upgrading Qubes 3.2 with the patches all seems fine.
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqMLisACgkQFBMQ2OPt
CKW0nw/8D/T+ShxOuAVnlG38T6f/LZ8Hx/1tlVe7Ad+Keihe7+eP/t8HDQmO1kpw
JJdkeOvDNEM+uUS9frEtKTDVnRQTQhKVjfGzkFAPd02opNhS7TqG2OKPqh7CUqTl
xM87mZ1OLbEnpc1ppPZ3pBM/cOFBsd8i07/skd/CN/NEBSkBABABoTSMWJwVdLEN
0GaQOaV7F+Ani7Vq8yD9RkJPuC5npMtMtXMNo1PnOtwTix6P8Q+yvF/jb+cc1uRH
FNcl7/YkDS8N492ikJwdsIA/Vss+fSRv4w85S4hWaqlb8b6C0R4+OjjovW40o5v0
XuLT6aoT3jFnAioXeSPCXY4s7+eP/DZkTJpYTcyR4aFseoQaGkU/UY3RoU+w7eL/
gqnf+F/UwjgZ4KfFoL23I2QaO4euFTHJTRfrnk4rPE0CRgj/pQ2OYRkugdPG3qON
kbpVR/HGo1DIeQzI33Qfee2wAGV2DcqW6ysg6c9G8wxLWipr1CuGTHaWgKE6voKI
d4ywuA5OpKLl1CyBAKQQ9PqfOjkXV+EQLQuCpN0xOcIlgNC8FR69BPYevHs1EDB2
pYdkwObAk+euUhsCINy/kR31SKAvIlt1JF65f3vcatAqJTXdE+efOSxPemti+FwY
psBR3gfLEN+C//Qay7Ki5wVkjGsKKtpkanRRnc+smxOkA48Tlto=
=LN7Q
-----END PGP SIGNATURE-----
Tom Zander
Feb 20, 2018, 10:27:24 AM2/20/18
to Wojtek Porczyk, qubes-users, qubes-devel
On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote:
> On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel
wrote:
> > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki
wrote:
> > > We've decided to deprecate the '$' character from qrexec-related
> > > usage.
> > > Instead, to denote special tokens, we will use the '@' character,
> > > which we believe is less likely to be interpreted in a special way
> > > by the relevant software.
> >
> > I would argue against the @ sign on account that it is a special
> > character in bash as well.
> >
> On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel
wrote:
> > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki
wrote:
> > > We've decided to deprecate the '$' character from qrexec-related
> > > usage.
> > > Instead, to denote special tokens, we will use the '@' character,
> > > which we believe is less likely to be interpreted in a special way
> > > by the relevant software.
> >
> > I would argue against the @ sign on account that it is a special
> > character in bash as well.
> >
> > I don't immediately see a way to exploit it, but why risk it?
>
> We absolutely need a special character that is not allowed in qube name to
> make the special tokens immediately obvious in policy. The process I used
> was to list available characters (POSIX Portable Character Set [1])
[]
>
> We absolutely need a special character that is not allowed in qube name to
> make the special tokens immediately obvious in policy. The process I used
> was to list available characters (POSIX Portable Character Set [1])
> If I missed something, could you please point out? I know shell just good
> enough to know that it's not possible to know every shell quirk. :)
The thing you have to rememeber is that the escape character never needs to
> enough to know that it's not possible to know every shell quirk. :)
be typed by the user.
In QRexec you are defining an API, applications like qvm-run are using that
API. What the user passes into qvm-run and what is actually sent to dom0
does not have to be identical.
I guess you do the translation currently as well; '$' turns into '@' in your
new code.
The consequence of this is that you don't have to limit yourself to the
posix list.
Using the portable characters set for a non-character simply isn't needed.
So, knowing that your API is actually based on 8-bit characters and not 7
bits which you are limiting yourself to, my suggestion is to take something
above 127 and below 256 as a special char.
Most fun one would be “ÿ” which is a normal character you can pass on a
shell script if you must, its actual byte-value is 0xFF
Marek Marczykowski-Górecki
Feb 20, 2018, 10:55:17 AM2/20/18
to Tom Zander, Wojtek Porczyk, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Tue, Feb 20, 2018 at 04:27:16PM +0100, 'Tom Zander' via qubes-devel wrote:
> On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote:
> > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel
> wrote:
> > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki
> wrote:
> > > > We've decided to deprecate the '$' character from qrexec-related
> > > > usage.
> > > > Instead, to denote special tokens, we will use the '@' character,
> > > > which we believe is less likely to be interpreted in a special way
> > > > by the relevant software.
> > >
> > > I would argue against the @ sign on account that it is a special
> > > character in bash as well.
> > >
> > > I don't immediately see a way to exploit it, but why risk it?
> >
> > We absolutely need a special character that is not allowed in qube name to
> > make the special tokens immediately obvious in policy. The process I used
> > was to list available characters (POSIX Portable Character Set [1])
> []
> > If I missed something, could you please point out? I know shell just good
> > enough to know that it's not possible to know every shell quirk. :)
>
> The thing you have to rememeber is that the escape character never needs to
> be typed by the user.
> In QRexec you are defining an API, applications like qvm-run are using that
> API. What the user passes into qvm-run and what is actually sent to dom0
> does not have to be identical.
In theory yes, but this would introduce more complexity to this code
> On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote:
> > On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel
> wrote:
> > > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki
> wrote:
> > > > We've decided to deprecate the '$' character from qrexec-related
> > > > usage.
> > > > Instead, to denote special tokens, we will use the '@' character,
> > > > which we believe is less likely to be interpreted in a special way
> > > > by the relevant software.
> > >
> > > I would argue against the @ sign on account that it is a special
> > > character in bash as well.
> > >
> > > I don't immediately see a way to exploit it, but why risk it?
> >
> > We absolutely need a special character that is not allowed in qube name to
> > make the special tokens immediately obvious in policy. The process I used
> > was to list available characters (POSIX Portable Character Set [1])
> []
> > If I missed something, could you please point out? I know shell just good
> > enough to know that it's not possible to know every shell quirk. :)
>
> The thing you have to rememeber is that the escape character never needs to
> be typed by the user.
> In QRexec you are defining an API, applications like qvm-run are using that
> API. What the user passes into qvm-run and what is actually sent to dom0
> does not have to be identical.
(taking care where which encoding is used etc).
> I guess you do the translation currently as well; '$' turns into '@' in your
> new code.
>
> The consequence of this is that you don't have to limit yourself to the
> posix list.
> Using the portable characters set for a non-character simply isn't needed.
>
> So, knowing that your API is actually based on 8-bit characters and not 7
> bits which you are limiting yourself to, my suggestion is to take something
> above 127 and below 256 as a special char.
> Most fun one would be “ÿ” which is a normal character you can pass on a
> shell script if you must, its actual byte-value is 0xFF
as UTF-8.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yxCegf+Iii677oWd0CmJgoygfVfiQnmDl+a7XBX/i+tb8BMqO67AgwzoM6cWXq6
ZaA76a50qKSmcSjj6xSPtg4sPV0hqpgORsnxikAn5zg9vi7QJMJ0q+hKuKVxHAY1
TZSVFynTs6ci0JjgVRiB8QZCrl2eC9hQraGs46u6Zevvj80ZapaEqu0Sh0rowpDe
SZ+QbiKi/QD1IeSF03OjnlqtoEyAZtPJ4dMY9F8IpR0P/vzsPxnkx/493HVjSA1i
7Z7kutdCcrGAqCtROhQ9DnS7+GTfdNcDJ5zwZ5yz5fJWlrzFgDSjENuwrSUqU/13
W6HNQVwx/fW+RBseUkJ/o98GHVW8sg==
=af4O
-----END PGP SIGNATURE-----
Tom Zander
Feb 20, 2018, 12:57:43 PM2/20/18
to Marek Marczykowski-Górecki, Wojtek Porczyk, qubes-users, qubes-devel
On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote:
> > The thing you have to rememeber is that the escape character never needs
> > to be typed by the user.
> > In QRexec you are defining an API, applications like qvm-run are using
> > that API. What the user passes into qvm-run and what is actually sent
> > to dom0 does not have to be identical.
>
> In theory yes, but this would introduce more complexity to this code
> (taking care where which encoding is used etc).
I read the code, there is no encoding.
> > The thing you have to rememeber is that the escape character never needs
> > to be typed by the user.
> > In QRexec you are defining an API, applications like qvm-run are using
> > that API. What the user passes into qvm-run and what is actually sent
> > to dom0 does not have to be identical.
>
> In theory yes, but this would introduce more complexity to this code
> (taking care where which encoding is used etc).
You correctly used the POSIX Portable Character Set for text. So no need
for encoding.
When you use the qrexec API you just sent a struct with some arrays of bytes
for VM names.
In your qrexec code you use an array of unsigned chars. Also, no encoding.
The point is that you use encodings only when you have **text** with
characters > 127. Which you don't allow.
The problem you fear doesn't exist.
The reason is because when accepting user-input you use encodings.
When your app starts talking to qrexec/qubsed there is no longer any
encoding. Just an 8-bit bytearray. The text has been standardized.
On the 'other' side of qrexec (on dom0) you have perfect control over the
situation and you also don't have any need for recoding or encodings or
anything like that. It still is just 8 bits data, not encoded.
> > I guess you do the translation currently as well; '$' turns into '@' in
> > your new code.
> >
> > The consequence of this is that you don't have to limit yourself to the
> > posix list.
> > Using the portable characters set for a non-character simply isn't
> > needed.
> >
> > So, knowing that your API is actually based on 8-bit characters and not
> > 7
> > bits which you are limiting yourself to, my suggestion is to take
> > something above 127 and below 256 as a special char.
> > Most fun one would be “ÿ” which is a normal character you can pass on a
> > shell script if you must, its actual byte-value is 0xFF
>
> Until some helpful application (shell or else) will try to interpret it
> as UTF-8.
policy-frameowork? If you fear that you have bigger issues as they could
replace anything with anything...
Anyway, to answer your fear.
No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken.
(see attached example file) Or, more likely, it will just switch off utf-8.
Marek Marczykowski-Górecki
Feb 20, 2018, 1:43:42 PM2/20/18
to Tom Zander, Wojtek Porczyk, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Tue, Feb 20, 2018 at 06:57:34PM +0100, Tom Zander wrote:
> On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote:
> > > The thing you have to rememeber is that the escape character never needs
> > > to be typed by the user.
> > > In QRexec you are defining an API, applications like qvm-run are using
> > > that API. What the user passes into qvm-run and what is actually sent
> > > to dom0 does not have to be identical.
> >
> > In theory yes, but this would introduce more complexity to this code
> > (taking care where which encoding is used etc).
>
> I read the code, there is no encoding.
> You correctly used the POSIX Portable Character Set for text. So no need
> for encoding.
> When you use the qrexec API you just sent a struct with some arrays of bytes
> for VM names.
> In your qrexec code you use an array of unsigned chars. Also, no encoding.
>
> The point is that you use encodings only when you have **text** with
> characters > 127. Which you don't allow.
>
> The problem you fear doesn't exist.
>
> The reason is because when accepting user-input you use encodings.
>
> When your app starts talking to qrexec/qubsed there is no longer any
> encoding. Just an 8-bit bytearray. The text has been standardized.
>
> On the 'other' side of qrexec (on dom0) you have perfect control over the
> situation and you also don't have any need for recoding or encodings or
> anything like that. It still is just 8 bits data, not encoded.
And then, after policy evaluation, you pass that data to actual service
> On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote:
> > > The thing you have to rememeber is that the escape character never needs
> > > to be typed by the user.
> > > In QRexec you are defining an API, applications like qvm-run are using
> > > that API. What the user passes into qvm-run and what is actually sent
> > > to dom0 does not have to be identical.
> >
> > In theory yes, but this would introduce more complexity to this code
> > (taking care where which encoding is used etc).
>
> I read the code, there is no encoding.
> You correctly used the POSIX Portable Character Set for text. So no need
> for encoding.
> When you use the qrexec API you just sent a struct with some arrays of bytes
> for VM names.
> In your qrexec code you use an array of unsigned chars. Also, no encoding.
>
> The point is that you use encodings only when you have **text** with
> characters > 127. Which you don't allow.
>
> The problem you fear doesn't exist.
>
> The reason is because when accepting user-input you use encodings.
>
> When your app starts talking to qrexec/qubsed there is no longer any
> encoding. Just an 8-bit bytearray. The text has been standardized.
>
> On the 'other' side of qrexec (on dom0) you have perfect control over the
> situation and you also don't have any need for recoding or encodings or
> anything like that. It still is just 8 bits data, not encoded.
to execute the operation (which may be in dom0 or another VM).
> > > I guess you do the translation currently as well; '$' turns into '@' in
> > > your new code.
> > >
> > > The consequence of this is that you don't have to limit yourself to the
> > > posix list.
> > > Using the portable characters set for a non-character simply isn't
> > > needed.
> > >
> > > So, knowing that your API is actually based on 8-bit characters and not
> > > 7
> > > bits which you are limiting yourself to, my suggestion is to take
> > > something above 127 and below 256 as a special char.
> > > Most fun one would be “ÿ” which is a normal character you can pass on a
> > > shell script if you must, its actual byte-value is 0xFF
> >
> > Until some helpful application (shell or else) will try to interpret it
> > as UTF-8.
>
> Ehm, how would “some helpful application” manage to get in your qrexec
> policy-frameowork? If you fear that you have bigger issues as they could
> replace anything with anything...
thing executing the service handle arguments. Not policy evaluating part
- - there '$' or other potentially shell special characters are handled
correctly. Anyone can write a qrexec service, and we want to provide a
framework that make it hard to shoot yourself in the foot.
> Anyway, to answer your fear.
>
> No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken.
> (see attached example file) Or, more likely, it will just switch off utf-8.
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqMa8cACgkQ24/THMrX
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yyE6gf+McyBJoK/NW4KAfYEL5xritven8tl35yXaWND674jddKz/WXMaaf9mdar
338xMDBLoeDMZvYVpujd2+lbbnwyMPOUvxGtDQ87R+mluWX5YkWcrzNgVWhrjbJu
GTczmlkCT+PaW5cYonXCvFMzGyB3Afu2T7BMBD947RU2SUpiaooAfUUqpS1dCGG8
cQF8xe2Ab3vCBF1e1ocOEF5KRYgsC8NsTc1KDqlDp9AORqfLOINHv0ZNFS/Gaksn
CLqvKO5VPr+oswHm8v5I4MLQPK5cQuFvn7oJOs3+pOzZqVk9y7xvjZ4xKiVNF4pB
tK0B3Tpp3F0VzI9fhAoYHi4pI2PSUg==
=mIGj
-----END PGP SIGNATURE-----
Tom Zander
Feb 20, 2018, 1:54:32 PM2/20/18
to Marek Marczykowski-Górecki, Wojtek Porczyk, qubes-users, qubes-devel
On Tuesday, 20 February 2018 19:41:19 CET Marek Marczykowski-Górecki wrote:
> > On the 'other' side of qrexec (on dom0) you have perfect control over
> > the
> > situation and you also don't have any need for recoding or encodings or
> > anything like that. It still is just 8 bits data, not encoded.
>
> And then, after policy evaluation, you pass that data to actual service
> to execute the operation (which may be in dom0 or another VM).
Yes, WITHOUT the escape character.
> > On the 'other' side of qrexec (on dom0) you have perfect control over
> > the
> > situation and you also don't have any need for recoding or encodings or
> > anything like that. It still is just 8 bits data, not encoded.
>
> And then, after policy evaluation, you pass that data to actual service
> to execute the operation (which may be in dom0 or another VM).
Remember, you escape the special names of VM names that dom0 will
substitute. “$adminvm” doesn't end up being the string you offer to qubesd,
the string “dom0” is.
Likewise; you don't start a service in Dispvm18431 and send it the text
“$dispvm”.
Wojtek Porczyk
Feb 21, 2018, 6:12:19 AM2/21/18
to Tom Zander, qubes-users, qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
The character has to be input in at least two places: in /etc/qubes-rpc/policy
as the second token (destination) on the line and as argument to
qrexec-client[-vm] executable. Using any of the common editors, any
language-specific keyboard layout, and any common encoding. Most people have
UTF-8, or ISO-8859-*, but we don't exclude the possibility to have admin qube
on Windows -- there was at least one serious attempt -- so this brings UTF-16
and Windows-125*.
As and example, may I use ÿ character you provided:
1) You're right the codepoint is U+00FF, but UTF-8 encoding is actually
"\xc3\xbf", so no, we cannot use it.
2) I don't have it on my keyboard. So anytime I have to input one of those
characters, I search all the modifiers for the right one (ý? no. ŷ? neither.
ỹ? my font has trouble with that, is that even a letter? ý? tried this one
already...). I don't have real data, but I think most people don't even know
where to start looking for this and in the optimistic case will end up
sourcing it from gucharmap or equivalent. This is bad UX.
Maybe there is a character outside portable charset that is portable and
writable enough, but I don't know of any. I haven't thought there is hope
enough to actually find one, so I didn't bother searching. That's why I've
asked.
Again, thanks for your review. I think it's helpful, because this change was
made behind community's back (for obvious reasons), fast, and in very limited
group of people. I wasn't sure if we didn't make some mistake, so the best
what I could hope for was to explain myself and get ex post facto review,
which you provided.
- --
pozdrawiam / best regards _.-._
Wojtek Porczyk .-^' '^-.
Invisible Things Lab |'-.-^-.-'|
| | | |
I do not fear computers, | '-.-' |
I fear lack of them. '-._ : ,-'
-- Isaac Asimov `^-^-_>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
/KNCL9gfVt3T6/keBBuEwfX3XcOIiO/FBWNfcf6dxeBGGcMHHQn0pd4Ucj/HZw8b
0/s63gjXH+ru7m4x2VW/3uDI4igkic6UUYPVHDB0sQtbTvGGWsr5pPJxcx7JgbwX
+mJmDgt7i/9Y3lAGEva5ex+q7WG4hJd8ArgnJGAVnp7MrTgIduHW1/2QufC6uvvE
gRRc3gbZK5FkT5Yg38UumE4sNcmnV0Nvu3m+o/g/cBcEER7wO81XW6TKFj0Ok/Bg
Ostsov9NwO3iGv0usSUvMKfw7Aac3VK9SsW0r5sxA/QFe9jVvasVnmvIrxTRwwL+
W+gP5piagxgphLhUcR6LwyEhRPWzb06iDaaztXnLXyInWFEGdei1ATmlQNI0Rmno
pNh/QLQqS6YF+hAl8LxSkOj3tjcg7MTYl00y9Z6ePJRUDA84s1hlWT43agWNN4L3
SX55/UzTU8DlhcduL3WmY6DVIKKlfE2Q82VorkprY6i/u/d7fdCblYLOtatZh2JB
OK1ZFOprRlAJodYQMUws7o8cDgY3LxfgKX45PC23DJG6o5CDM+WoqmUw72uxMFft
jRE299HwUV3qfzxm9/bjLPJqgnP+nSFnY/4J02iHUQxkg3Xb9ibKxFmTWhnf78zd
REwcpFmrrjnrVVy14CZ2
=wkxM
-----END PGP SIGNATURE-----
Tom Zander
Feb 21, 2018, 6:35:56 AM2/21/18
to Wojtek Porczyk, qubes-users, qubes-devel
On Wednesday, 21 February 2018 12:12:06 CET Wojtek Porczyk wrote:
> This is bad UX.
This is frustrating, I spent too many emails making the point clear that
this is an API level escape token. Not a user-visible one, and then you
respond to the thread showing you still completely missed that.
So let me be blunt as this is likely the last email from me to qubes anyway;
Fact: Variables given to qrexec are going to be replaced with the actual
relevant value.
For instance bash takes`ls *` and replaces the star with the actual values
_before_ calling ls. Ls or any executable does not have to deal with things
like star or dollar sign etc.
Your and Marek complaints are that you need to escape the variables when you
pass them on to the target VM handler.
If you are indeed doing that, you are doing it wrong and you can wait for
the next security bulletin like the one we are discussing right now.
The point of a variable that is passed from a VM to the dom0 qrexec daemon
is that your source VM doesn't have to know about who is $adminVM or what is
the actually started dispVM's name.
QRexec daemon (in dom0) should do the variable replacement before the user
request leaves qrexec-daemon running in dom0.
Just like bash does the replacement before it forwards the command-line.
Again, if you do not do the variable replacement there, but instead pass it
through unvalidated and unrelated software, you are going to continue having
security flaws.
> This is bad UX.
This is frustrating, I spent too many emails making the point clear that
this is an API level escape token. Not a user-visible one, and then you
respond to the thread showing you still completely missed that.
So let me be blunt as this is likely the last email from me to qubes anyway;
Fact: Variables given to qrexec are going to be replaced with the actual
relevant value.
For instance bash takes`ls *` and replaces the star with the actual values
_before_ calling ls. Ls or any executable does not have to deal with things
like star or dollar sign etc.
Your and Marek complaints are that you need to escape the variables when you
pass them on to the target VM handler.
If you are indeed doing that, you are doing it wrong and you can wait for
the next security bulletin like the one we are discussing right now.
The point of a variable that is passed from a VM to the dom0 qrexec daemon
is that your source VM doesn't have to know about who is $adminVM or what is
the actually started dispVM's name.
QRexec daemon (in dom0) should do the variable replacement before the user
request leaves qrexec-daemon running in dom0.
Just like bash does the replacement before it forwards the command-line.
Again, if you do not do the variable replacement there, but instead pass it
through unvalidated and unrelated software, you are going to continue having
security flaws.
qubenix
Feb 21, 2018, 11:41:41 AM2/21/18
to Tom Zander, qubes-users, qubes-devel
> So let me be blunt as this is likely the last email from me to qubes
anyway;
Bye, I'm happy to see you go away finally. It was killing me inside that
anyway;
you were working on the new gui controller. Fuck off back to bcash.
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
awokd
Feb 21, 2018, 11:49:35 AM2/21/18
to qubenix, Tom Zander, qubes-users, qubes-devel
On Wed, February 21, 2018 4:41 pm, qubenix wrote:
>> So let me be blunt as this is likely the last email from me to qubes
>>
> anyway;
>
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.
Tom had some constructive criticism to offer, which is healthy. I don't
>> So let me be blunt as this is likely the last email from me to qubes
>>
> anyway;
>
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.
think your response is particularly constructive or appropriate for the
mailing lists, however.
Yuraeitha
Feb 21, 2018, 12:14:15 PM2/21/18
to qubes-users
Not trying to understand other people a trap many fall into, even among those who try to understand others, we can all at times fail at it. Especially if something bad is going on in a persons life at the time, which can trigger an otherwise understanding person not to try understand another person, thereby igniting a conflict which wouldn't have happened otherwise. The world is complex.
Once the initial conflict has been ignited, personal grudges or even long exhausting and devastating wars, people often forget why they were even fight in the first place. Initial conflicts can go out of control, the lack of understanding being the fuel to seeking protect one self, by harming the opponent, instead of seeing the find the root of the issue and solving it.
Conflicts, can become self realized prophecy, what matters is to break this "circle" early on. It's like the butterfly effect in Chaos Theory, the first impression of a person can lead to very complex situations later on. If not taking steps to break the circle, initial conditions will then determine your relationship with that person. Like an unstoppable but irrational momentum.
It's not always possible to stop one self to cause more harm rather than try to understand the other, especially if having a bad time from something else in ones own life, but in the very end most people by far don't mean to harm one another. It's simply a lack of understanding of each others. The actual "harm" being done, is not the root, the lack of understanding is what leads to the "harming", not the other way around.
So trying to understand is key, to not harm each others. Something we can all fail at, even the most peaceful humans can forget it, we all live complex lives with ups and downs.
It's also human nature to be lazy, it's encoded in us from evolution, and it's even an universal law in entropy. The entire universe, and every system in it, including ourselves, have incentives to be lazy and uptimize to the most efficient approach. Even how you walk is highly efficient, the way you conduct your social life is efficient.
If one wants to break away from it, then one self needs to introduce more energy to the system from outside the system (entropy). And there lies the issue, conflicts are systems which no energy are given (or effort) to try understand one another. The conflict (or the system of relationship following the universal rules of entropy) will then exhaust itslef and burn out. Even relationships and marriages follow this logic.
By in an on it self, we're not channeling enough energy into this relationship, and thereby the relationship is suffering. By being lazy, we justify it by just calling the other "bad" or "evil". But in reality, very few people are actually such.
haaber
Feb 21, 2018, 12:17:17 PM2/21/18
to qubes...@googlegroups.com
On 02/21/2018 05:41 PM, qubenix wrote:
>> So let me be blunt as this is likely the last email from me to qubes
> anyway;
>
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.
>
I really hope that you will understand one day that the first victim of
>> So let me be blunt as this is likely the last email from me to qubes
> anyway;
>
> Bye, I'm happy to see you go away finally. It was killing me inside that
> you were working on the new gui controller. Fuck off back to bcash.
>
your hate is yourself. Until this day I prefer that you keep such kind
of language out of this mailing list ... Bernhard
bill...@gmail.com
Feb 21, 2018, 12:42:22 PM2/21/18
to qubes-users
On Tuesday, February 20, 2018 at 10:27:24 AM UTC-5, Tom Zander wrote:
> So, knowing that your API is actually based on 8-bit characters and not 7
> bits which you are limiting yourself to, my suggestion is to take something
> above 127 and below 256 as a special char.
> Most fun one would be “ÿ” which is a normal character you can pass on a
> shell script if you must, its actual byte-value is 0xFF
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
Hah! I'm starting to have nightmares from my old days programming in APL. There be dragons there...
> So, knowing that your API is actually based on 8-bit characters and not 7
> bits which you are limiting yourself to, my suggestion is to take something
> above 127 and below 256 as a special char.
> Most fun one would be “ÿ” which is a normal character you can pass on a
> shell script if you must, its actual byte-value is 0xFF
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
donoban
Feb 21, 2018, 4:59:01 PM2/21/18
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 02/20/2018 03:18 PM, donoban wrote:
> Hi,
>
> After upgrading Qubes 3.2 with the patches all seems fine.
I noticed updates from qubes-manager are not working in Qubes 3.2. Not
> Hi,
>
> After upgrading Qubes 3.2 with the patches all seems fine.
sure if it's related with this patch though...
I'm pretty sure this line is being called:
vm.run_service("qubes.InstallUpdatesGUI", gui=True,
user="root", wait=False)
But nothing happens :\
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqN65gACgkQFBMQ2OPt
CKWGRw/+LhzHUgYdQW89f1bTvS+UpPhxqhE5jKKQv0pZpLAsZU5u9kZnf4+czxq1
dN0ZW5cGg0NwAg1ra3rvpclKKat+IkcmhN5yFJ5IVlSzmjTHLJ6T6LjoPnmyc0iD
XRaWNaGu+3Gg8jQmiCJ9i0ZgbdgdHegbLRpKu5R5jnO0ux1wAVTrpo3OEJfijUx+
26sGbSGVh+K2XD5nXk3xHd44F1K3/iJYBTRLcUYzoSH5kN94gs/AgUFqd1XgrIRs
o5pi/kC5Qkp0bBFptpV2yCQY+b2KCpGHsqoIa43WLR/qpxjHr39FXqAgkzlVq8DC
LIoWRfljv4B7GmvoOSfBCdigaFKInPKX3XJA+dRzVW8aMZQZ/ZjYz2YLnDzw+qnR
zA/Qv1OAJ32GtGoUEbhux2STOekbNgnyx5nyBRMUjZMSWDoTlyJrH2ZJg7o/BBok
juIBqtB91niAWBUZwbR7NMvLI5GAAkVL2yWx0lSVaYrjPBXhafME3/SXY4q7fNwu
JalDGLt0Qii3XpPrH1mCZ5Jild7gn0Eg54BTwvtM/xxGGPH9j876m32w7PuTeO70
OHL7yM0ZEOF8FDOe0/PHIeXEGhPtX2oWIzsAIdEOqiDCGjVzpvMtXPAFLlHO1drK
wwp9o/8TnhNROSJz2QJDJkvaeYF5D/qm2zLAn/hfMRwpWWmJbz8=
=PGjU
-----END PGP SIGNATURE-----
donoban
Feb 21, 2018, 5:08:38 PM2/21/18
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On 02/21/2018 10:58 PM, donoban wrote:
> On 02/20/2018 03:18 PM, donoban wrote:
>> Hi,
>
>> After upgrading Qubes 3.2 with the patches all seems fine.
>
>
> I noticed updates from qubes-manager are not working in Qubes 3.2.
> Not sure if it's related with this patch though...
>
> I'm pretty sure this line is being called:
>
> vm.run_service("qubes.InstallUpdatesGUI", gui=True, user="root",
> wait=False)
>
> But nothing happens :\
>
Looking at systemd logs I noticed it fails because DISPLAY is not set.
> On 02/20/2018 03:18 PM, donoban wrote:
>> Hi,
>
>> After upgrading Qubes 3.2 with the patches all seems fine.
>
>
> I noticed updates from qubes-manager are not working in Qubes 3.2.
> Not sure if it's related with this patch though...
>
> I'm pretty sure this line is being called:
>
> vm.run_service("qubes.InstallUpdatesGUI", gui=True, user="root",
> wait=False)
>
> But nothing happens :\
>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAlqN7doACgkQFBMQ2OPt
CKVUtxAAjHsP2zj9X39En6P6HmuA8tqrEL48+A7bNb50npFQoJpMpdIsS29WdwkK
/5+0Wq3PHE3UXwUMuxomXr3gAQsqOVrkUeFE3wbS9fiZA5OzMJ7V1HI1zF5+lRmb
Jfo+kTCu8w3hbcGS6vFK2WbaFRtPzGatSsYHNSs++oAa0A0usrTXuQEVJ4roxNm2
qE28FG8ZnvDF2e5mpXwqfsvCYSUPwTe61cgVYTnb0+0cqqi9UP6z+wvR3yYHodfz
3pY/kpTk34/7Ul6WSX4ENFcb5q4e1U/cmxU5ZXRLQxycfErs+YLdZzL5Ql7flPac
x0e/1rWEnOITd0CSsT7v1u0FJRciSZDt/QYb96CruXNlhAltyl3JF2P/ea+EOLqE
WPZjB/wQCw+t4DbCRY+DzbJ/mxuSBUAnCFLyOsrqnbDVefv8esmmBfM+Y8+VGWIS
m3AslW1f5wkzC48LqCmA9gYEqeT92Ch3gej993M0NGfLGreBN7X6gxvCbaaDvexh
ZratzSgciH4WFdqnoBa0GQX7CWMVDlAEyp0gxjhhp05wzj9gtrMSDEKAnRI+EoRz
rAm8dAUd0DN0JBqKeK+zLNCEd1aAjsPxJkB1XNc/S79ha0ByMZd6Lf46IKSBWLl9
Uqya4sKfUfM4QCcjuLZktU5qf6UqJCtNSvvEpLlzxxmnJ5pjxg0=
=G6dD
-----END PGP SIGNATURE-----
Tim W
Feb 21, 2018, 6:32:31 PM2/21/18
to qubes-users
That is uncalled for and just common. Toms comments were constructive and topic specific. Sure, showing some frustration as we all have from time to time, but your comment was just common thug personal attack and has no place here. In fact I do not see where you have offered a single thing of on topic value, only a vulgar personal attck.
FYI. Many of us are professionals in the field and I for one do not expect to be speak or be spoken to by anyone in such a mannner even if it is the net where people can hide behind screen names and distance. Maybe take your own advice if that is how you handle a small bit of critism, debate, and disagreement.
Respectfully,
Tim
Reply all
Reply to author
Forward
0 new messages