QSB #38: Qrexec policy bypass and possible information leak
https://www.qubes-os.org/news/2018/02/20/qsb-38/
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
https://www.qubes-os.org/news/2018/02/20/qsb-38/
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.
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 noscript. 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].
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 noscript. 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/
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/
XSA-252, XSA-255, and XSA-256 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/02/27/xsa-252-255-256-qubes-not-affected/
The Xen Project has published Xen Security Advisories 252, 255, and 256
(XSA-252, XSA-255, and XSA-256, respectively). These XSAs do not
affect the security of Qubes OS, and no user action is necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#252
https://www.qubes-os.org/security/xsa/#255
https://www.qubes-os.org/security/xsa/#256
https://www.qubes-os.org/news/2018/02/27/xsa-252-255-256-qubes-not-affected/
The Xen Project has published Xen Security Advisories 252, 255, and 256
(XSA-252, XSA-255, and XSA-256, respectively). These XSAs do not
affect the security of Qubes OS, and no user action is necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#252
https://www.qubes-os.org/security/xsa/#255
https://www.qubes-os.org/security/xsa/#256
Xen Project Member Spotlight: DornerWorks
https://blog.xenproject.org/2018/02/28/xen-project-member-spotlight-dornerworks/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2018/02/28/xen-project-member-spotlight-dornerworks/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Comment on Xen Project Spectre/Meltdown FAQ by Meltdown and Spectre Explained - WWT
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/#comment-464
[…] Security Advisory (XSA-254) / FAQ […]
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/#comment-464
[…] Security Advisory (XSA-254) / FAQ […]
Comment on What’s New in the Xen Project Hypervisor 4.9? by prome.4
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-465
Is It here any tutol how to install new update?
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-465
Is It here any tutol how to install new update?
Comment on Xen Project Contributor Spotlight: Kevin Tian by Xen Project Contributor Spotlight: Kevin Tian – Nerd Junkie
https://blog.xenproject.org/2018/02/14/xen-project-contributor-spotlight-kevin-tian/#comment-466
[…] Read more at Xen Project […]
https://blog.xenproject.org/2018/02/14/xen-project-contributor-spotlight-kevin-tian/#comment-466
[…] Read more at Xen Project […]
Comment on Xen Project Member Spotlight: DornerWorks by Xen Project Member Spotlight: DornerWorks – Nerd Junkie
https://blog.xenproject.org/2018/02/28/xen-project-member-spotlight-dornerworks/#comment-475
[…] Read more at Xen Project […]
https://blog.xenproject.org/2018/02/28/xen-project-member-spotlight-dornerworks/#comment-475
[…] Read more at Xen Project […]
Qubes OS 4.0-rc5 has been released!
https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/
We’re pleased to announce the fifth release candidate for Qubes 4.0!
This release contains bug fixes for the issues discovered in the
previous release candidate (https://www.qubes-os.org/news/2018/01/31/qubes-40-rc4/). A full list of the Qubes 4.0
issues closed so far is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed). Further
details about this release, including full installation instructions,
are available in the Qubes 4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new
installation image is available on the Downloads (https://www.qubes-os.org/downloads/) page.
As always, we’re immensely grateful to our community of testers for
taking the time to discover and report bugs (https://www.qubes-os.org/doc/reporting-bugs/). Thanks to your efforts,
we’re able to fix these bugs before the final release of Qubes 4.0. We
encourage you to continue diligently testing this fourth release
candidate so that we can work together to improve Qubes 4.0 before the
stable release.
The Qubes 4.0 stable release
If the testing of 4.0-rc5 does not reveal any major problems, we hope to
declare it the stable 4.0 release without any further significant
changes. In this scenario, any bugs discovered during the testing
process would be fixed in subsequent updates.
If, on the other hand, a major issue is discovered, we will continue
with the standard release schedule (https://www.qubes-os.org/doc/version-scheme/#release-schedule), and Qubes 4.0 stable will be a
separate, later release.
Current Qubes 4.0 Users
Current users of Qubes 4.0-rc4 can upgrade in-place by downloading the
latest updates from the testing repositories in both
dom0 (https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#testing-repositories).
https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/
We’re pleased to announce the fifth release candidate for Qubes 4.0!
This release contains bug fixes for the issues discovered in the
previous release candidate (https://www.qubes-os.org/news/2018/01/31/qubes-40-rc4/). A full list of the Qubes 4.0
issues closed so far is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed). Further
details about this release, including full installation instructions,
are available in the Qubes 4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new
installation image is available on the Downloads (https://www.qubes-os.org/downloads/) page.
As always, we’re immensely grateful to our community of testers for
taking the time to discover and report bugs (https://www.qubes-os.org/doc/reporting-bugs/). Thanks to your efforts,
we’re able to fix these bugs before the final release of Qubes 4.0. We
encourage you to continue diligently testing this fourth release
candidate so that we can work together to improve Qubes 4.0 before the
stable release.
The Qubes 4.0 stable release
If the testing of 4.0-rc5 does not reveal any major problems, we hope to
declare it the stable 4.0 release without any further significant
changes. In this scenario, any bugs discovered during the testing
process would be fixed in subsequent updates.
If, on the other hand, a major issue is discovered, we will continue
with the standard release schedule (https://www.qubes-os.org/doc/version-scheme/#release-schedule), and Qubes 4.0 stable will be a
separate, later release.
Current Qubes 4.0 Users
Current users of Qubes 4.0-rc4 can upgrade in-place by downloading the
latest updates from the testing repositories in both
dom0 (https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#testing-repositories).
Call for Proposals Open for the Xen Project Developer and Design Summit Happening in June!
https://blog.xenproject.org/2018/03/15/call-for-proposals-open-for-the-xen-project-developer-and-design-summit-happening-in-june/
Registration and the call for proposals are open for the Xen Project Developer and Design Summit 2018, which will be held in Nanjing Jiangning, China from June 20 – 22, 2018. The Xen Project Developer and Design Summit combines the formats of Xen Project Developer Summits with Xen Project Hackathons, and brings together the Xen […]
https://blog.xenproject.org/2018/03/15/call-for-proposals-open-for-the-xen-project-developer-and-design-summit-happening-in-june/
Registration and the call for proposals are open for the Xen Project Developer and Design Summit 2018, which will be held in Nanjing Jiangning, China from June 20 – 22, 2018. The Xen Project Developer and Design Summit combines the formats of Xen Project Developer Summits with Xen Project Hackathons, and brings together the Xen […]
Update for Qubes Security Bulletin #37: Information leaks due to processor speculative execution bugs (XSA-254, Mel… https://t.co/2oKwn0vAAc
Twitter
Qubes OS
Update for Qubes Security Bulletin #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Spectre) https://t.co/kWg2p15c0M
Update for QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Spectre)
https://www.qubes-os.org/news/2018/03/15/qsb-37-update/
Dear Qubes Community,
We have just updated Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.
The text of the main changes are reproduced below. For the full
text, please see the complete QSB in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-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/
View XSA-254 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#254
Changelog
==========
2018-01-11: Original QSB published
2018-01-23: Updated mitigation plan to XPTI; added Xen package versions
2018-03-14: Updated package versions with Spectre SP2 mitigations
[...]
(Proper) patching
==================
## Qubes 4.0
[...]
Additionally, Xen provided patches to mitigate Spectre variant 2. While
we don't believe this variant is reliably exploitable to obtain
sensitive information from other domains, it is possible to use it
for help with other attacks inside a domain (like escaping a sandbox
of web browser). This mitigation to be fully effective require
updated microcode - refer to your BIOS vendor for updates.
The specific packages that contain the XPTI and Spectre variant 2
patches for Qubes 4.0 are as follows:
- Xen packages, version 4.8.3-3
The packages 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
A system restart will be required afterwards.
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.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.
## Qubes 3.2
[...]
Additionally, Xen provided patches to mitigate Spectre variant 2. While
we don't believe this variant is reliably exploitable to obtain
sensitive information from other domains, it is possible to use it
for help with other attacks inside a domain (like escaping a sandbox
of web browser). This mitigation to be fully effective require updated
microcode - refer to your BIOS vendor for updates.
The specific packages that contain the XPTI and Spectre variant 2
patches for Qubes 3.2 are as follows:
- Xen packages, version 4.6.6-37
[...]
https://www.qubes-os.org/news/2018/03/15/qsb-37-update/
Dear Qubes Community,
We have just updated Qubes Security Bulletin (QSB) #37:
Information leaks due to processor speculative execution bugs.
The text of the main changes are reproduced below. For the full
text, please see the complete QSB in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-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/
View XSA-254 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#254
Changelog
==========
2018-01-11: Original QSB published
2018-01-23: Updated mitigation plan to XPTI; added Xen package versions
2018-03-14: Updated package versions with Spectre SP2 mitigations
[...]
(Proper) patching
==================
## Qubes 4.0
[...]
Additionally, Xen provided patches to mitigate Spectre variant 2. While
we don't believe this variant is reliably exploitable to obtain
sensitive information from other domains, it is possible to use it
for help with other attacks inside a domain (like escaping a sandbox
of web browser). This mitigation to be fully effective require
updated microcode - refer to your BIOS vendor for updates.
The specific packages that contain the XPTI and Spectre variant 2
patches for Qubes 4.0 are as follows:
- Xen packages, version 4.8.3-3
The packages 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
A system restart will be required afterwards.
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.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new Xen
binaries.
## Qubes 3.2
[...]
Additionally, Xen provided patches to mitigate Spectre variant 2. While
we don't believe this variant is reliably exploitable to obtain
sensitive information from other domains, it is possible to use it
for help with other attacks inside a domain (like escaping a sandbox
of web browser). This mitigation to be fully effective require updated
microcode - refer to your BIOS vendor for updates.
The specific packages that contain the XPTI and Spectre variant 2
patches for Qubes 3.2 are as follows:
- Xen packages, version 4.6.6-37
[...]
Qubes Canary #15
https://www.qubes-os.org/news/2018/03/15/canary-15/
Dear Qubes Community,
We have published Qubes Canary #15. The text of this canary is
reproduced below. This canary and its accompanying signatures will always be
available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #15 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-015-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 canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #15 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is March 14, 2018.
2. There have been 38 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of June 2018. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Wed, 14 Mar 2018 13:38:04 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Refugee Bedtime Stories: 'A Long, Long Time Ago, Syria Was Beautiful, My Son'
Creative Destruction: Macron Eyes Expanding His Movement Across Europe
'The Sale of Our Identity': C&A Family Member Discusses Firm's Uncertain Future
The Trade Warrior: Donald Trump's Attack on German Prosperity
Reporter Podcast: Understanding the Riddles of Greenland
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Why Moscow Will Never Apologize for Attack on Ex-Spy
The Biggest Refugee Camp Braces for Rain: ‘This Is Going to Be a Catastrophe’
Tillerson’s Firing Had Been Expected, but It Still Stunned Observers
Now Two Former Presidents of South Korea Are Under Investigation
New Zealand Diplomat Censured for Vulgar Tweet About U.S. Democrats
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Stephen Hawking: Visionary physicist dies aged 76
Democrat Conor Lamb claims victory in Pennsylvania election
Rex Tillerson: Secretary of state fired by Trump in Russia warning
Italy bomb: World War Two device forces mass evacuation in Fano
Caribbean volcano Kick 'em Jenny: Ships warned off area
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
https://www.qubes-os.org/news/2018/03/15/canary-15/
Dear Qubes Community,
We have published Qubes Canary #15. The text of this canary is
reproduced below. This canary and its accompanying signatures will always be
available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #15 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-015-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 canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #15 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is March 14, 2018.
2. There have been 38 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of June 2018. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Wed, 14 Mar 2018 13:38:04 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Refugee Bedtime Stories: 'A Long, Long Time Ago, Syria Was Beautiful, My Son'
Creative Destruction: Macron Eyes Expanding His Movement Across Europe
'The Sale of Our Identity': C&A Family Member Discusses Firm's Uncertain Future
The Trade Warrior: Donald Trump's Attack on German Prosperity
Reporter Podcast: Understanding the Riddles of Greenland
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Why Moscow Will Never Apologize for Attack on Ex-Spy
The Biggest Refugee Camp Braces for Rain: ‘This Is Going to Be a Catastrophe’
Tillerson’s Firing Had Been Expected, but It Still Stunned Observers
Now Two Former Presidents of South Korea Are Under Investigation
New Zealand Diplomat Censured for Vulgar Tweet About U.S. Democrats
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Stephen Hawking: Visionary physicist dies aged 76
Democrat Conor Lamb claims victory in Pennsylvania election
Rex Tillerson: Secretary of state fired by Trump in Russia warning
Italy bomb: World War Two device forces mass evacuation in Fano
Caribbean volcano Kick 'em Jenny: Ships warned off area
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Britain expels 23 Russian diplomats over chemical attack on ex-spy
Stephen Hawking, who unlocked the secrets of space and time, dies at 76
Turkey's Erdogan says hopes Syria's Afrin town to be captured by Wednesday evening
Civilians needing medical aid leave Syria's Ghouta for second day
Tokyo bids farewell to 'trustworthy' Tillerson, Seoul awaits seasoned Pompeo
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
00000000000000000020436a19f4772283e739a4dbd171be51214f5fe73c6804
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Stephen Hawking, who unlocked the secrets of space and time, dies at 76
Turkey's Erdogan says hopes Syria's Afrin town to be captured by Wednesday evening
Civilians needing medical aid leave Syria's Ghouta for second day
Tokyo bids farewell to 'trustworthy' Tillerson, Seoul awaits seasoned Pompeo
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
00000000000000000020436a19f4772283e739a4dbd171be51214f5fe73c6804
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Xen Project Contributor Spotlight: Yurii Konovalenko
https://blog.xenproject.org/2018/03/21/xen-project-contributor-spotlight-yurii-konovalenko/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2018/03/21/xen-project-contributor-spotlight-yurii-konovalenko/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Qubes OS 4.0 has been released!
https://www.qubes-os.org/news/2018/03/28/qubes-40/
After nearly two years in development and countless hours of testing,
we’re pleased to announce the stable release of Qubes OS 4.0!
Major changes in version 4.0
Version 4.0 includes several fundamental improvements to the security
and functionality of Qubes OS:
The Qubes Admin API (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/)
Qubes Core Stack version 3 (https://www.qubes-os.org/news/2017/10/03/core3/)
Fully virtualized VMs for enhanced security (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt)
Multiple, flexible Disposable VM templates (https://github.com/QubesOS/qubes-issues/issues/2253)
A more expressive, user-friendly Qubes RPC policy
system (https://www.qubes-os.org/doc/qrexec3/#extra-keywords-available-in-qubes-40-and-later)
A powerful new VM volume manager that makes it easy to keep VMs on
external drives (https://github.com/QubesOS/qubes-issues/issues/1842)
Enhanced TemplateVM security via split packages (https://github.com/QubesOS/qubes-issues/issues/2771) and network
interface removal (https://github.com/QubesOS/qubes-issues/issues/1854)
More secure backups with scrypt for stronger key
derivation and enforced encryption
Rewritten command-line tools with new options (https://www.qubes-os.org/doc/tools/4.0/)
This release delivers on the features we promised in our announcement
of Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), with some course corrections along the way,
such as the switch from HVM to PVH for most VMs in response to Meltdown
and Spectre (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt). For more details, please see the full Release
Notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The Qubes 4.0 installation image is available on the
Downloads (https://www.qubes-os.org/downloads/) page, along with the complete Installation Guide (https://www.qubes-os.org/doc/installation-guide/).
Current 4.0 release candidate users
In our Qubes 4.0-rc5 announcement (https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/), we explained that if the
testing of 4.0-rc5 did not reveal any major problems, we would declare
it to be the stable 4.0 release without any further significant changes
and that, in this scenario, any bugs discovered during the testing
process would be fixed in subsequent updates. This is, in fact, what has
occurred. We found that, with the fifth release candidate, 4.0 had
finally reached a level of stability that met our standards such that we
were comfortable designating it the stable release. Accordingly, current
users of 4.0-rc5 can upgrade in-place by downloading the latest updates
from the stable repositories in both dom0 (https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm).
We know that this stable release has been a long time in coming for many
you. We sincerely appreciate your patience. Thank you for sticking with
us. We’re especially grateful to all of you who have contributed code (https://www.qubes-os.org/doc/contributing/#contributing-code)
and documentation (https://www.qubes-os.org/doc/doc-guidelines/) to this release, tested (https://www.qubes-os.org/doc/testing/) release candidates, and
diligently reported bugs (https://www.qubes-os.org/doc/reporting-bugs/). This stable release would not have been
possible without your efforts. Your involvement makes Qubes a truly
open-source project. Your energy, skill, and good will make this project
a joy to work on. We are lucky to have you.
The past and the future
Since first announcing extended support for Qubes 3.2 (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32),
https://www.qubes-os.org/news/2018/03/28/qubes-40/
After nearly two years in development and countless hours of testing,
we’re pleased to announce the stable release of Qubes OS 4.0!
Major changes in version 4.0
Version 4.0 includes several fundamental improvements to the security
and functionality of Qubes OS:
The Qubes Admin API (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/)
Qubes Core Stack version 3 (https://www.qubes-os.org/news/2017/10/03/core3/)
Fully virtualized VMs for enhanced security (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt)
Multiple, flexible Disposable VM templates (https://github.com/QubesOS/qubes-issues/issues/2253)
A more expressive, user-friendly Qubes RPC policy
system (https://www.qubes-os.org/doc/qrexec3/#extra-keywords-available-in-qubes-40-and-later)
A powerful new VM volume manager that makes it easy to keep VMs on
external drives (https://github.com/QubesOS/qubes-issues/issues/1842)
Enhanced TemplateVM security via split packages (https://github.com/QubesOS/qubes-issues/issues/2771) and network
interface removal (https://github.com/QubesOS/qubes-issues/issues/1854)
More secure backups with scrypt for stronger key
derivation and enforced encryption
Rewritten command-line tools with new options (https://www.qubes-os.org/doc/tools/4.0/)
This release delivers on the features we promised in our announcement
of Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), with some course corrections along the way,
such as the switch from HVM to PVH for most VMs in response to Meltdown
and Spectre (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt). For more details, please see the full Release
Notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The Qubes 4.0 installation image is available on the
Downloads (https://www.qubes-os.org/downloads/) page, along with the complete Installation Guide (https://www.qubes-os.org/doc/installation-guide/).
Current 4.0 release candidate users
In our Qubes 4.0-rc5 announcement (https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/), we explained that if the
testing of 4.0-rc5 did not reveal any major problems, we would declare
it to be the stable 4.0 release without any further significant changes
and that, in this scenario, any bugs discovered during the testing
process would be fixed in subsequent updates. This is, in fact, what has
occurred. We found that, with the fifth release candidate, 4.0 had
finally reached a level of stability that met our standards such that we
were comfortable designating it the stable release. Accordingly, current
users of 4.0-rc5 can upgrade in-place by downloading the latest updates
from the stable repositories in both dom0 (https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm).
We know that this stable release has been a long time in coming for many
you. We sincerely appreciate your patience. Thank you for sticking with
us. We’re especially grateful to all of you who have contributed code (https://www.qubes-os.org/doc/contributing/#contributing-code)
and documentation (https://www.qubes-os.org/doc/doc-guidelines/) to this release, tested (https://www.qubes-os.org/doc/testing/) release candidates, and
diligently reported bugs (https://www.qubes-os.org/doc/reporting-bugs/). This stable release would not have been
possible without your efforts. Your involvement makes Qubes a truly
open-source project. Your energy, skill, and good will make this project
a joy to work on. We are lucky to have you.
The past and the future
Since first announcing extended support for Qubes 3.2 (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32),
we determined that users would be better served by having a version of
Qubes 3.2 with updated TemplateVMs and a newer kernel. We’ve designated
this release Qubes 3.2.1. As the name suggests, this is a point release
for Qubes 3.2 that does not contain any major changes, and it is this
release to which the extended support period will apply. We intend for
Qubes 3.2.1 to be a viable alternative to version 4.0 for those who wish
to use Qubes on hardware that does not meet the system requirements for
Qubes 4.0 (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x). While our standard policy (https://www.qubes-os.org/doc/supported-versions/#qubes-os) is to
support each Qubes release for six months after the next major or minor
release, the special extension for 3.2.1 raises this period to one full
year. Therefore, the stable release of Qubes 4.0 sets the EOL
(end-of-life) date for Qubes 3.2.1 at one year from today on 2019-03-28.
We expect 3.2.1 to be available soon, after Kernel 4.9 testing is
completed.
Looking forward, our work on Qubes 4.x has only just begun. Our sights
are now set on Qubes 4.1, for which we have a growing
list (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.1%22+label%3Aenhancement) of planned enhancements to nearly every aspect
of Qubes OS. Whether you’re new to Qubes or have been here for years, we
welcome you to join us and get involved (https://www.qubes-os.org/doc/contributing/). We’ve
personally chosen to devote our time and skills to making Qubes freely
available to the world because we believe that being open-source is
essential to Qubes being trustworthy and secure. If Qubes is valuable to
you, we ask that you please consider making a donation (https://www.qubes-os.org/donate/) to the project.
With your support, we can continue to make reasonable security a reality
for many years to come.
Qubes 3.2 with updated TemplateVMs and a newer kernel. We’ve designated
this release Qubes 3.2.1. As the name suggests, this is a point release
for Qubes 3.2 that does not contain any major changes, and it is this
release to which the extended support period will apply. We intend for
Qubes 3.2.1 to be a viable alternative to version 4.0 for those who wish
to use Qubes on hardware that does not meet the system requirements for
Qubes 4.0 (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x). While our standard policy (https://www.qubes-os.org/doc/supported-versions/#qubes-os) is to
support each Qubes release for six months after the next major or minor
release, the special extension for 3.2.1 raises this period to one full
year. Therefore, the stable release of Qubes 4.0 sets the EOL
(end-of-life) date for Qubes 3.2.1 at one year from today on 2019-03-28.
We expect 3.2.1 to be available soon, after Kernel 4.9 testing is
completed.
Looking forward, our work on Qubes 4.x has only just begun. Our sights
are now set on Qubes 4.1, for which we have a growing
list (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.1%22+label%3Aenhancement) of planned enhancements to nearly every aspect
of Qubes OS. Whether you’re new to Qubes or have been here for years, we
welcome you to join us and get involved (https://www.qubes-os.org/doc/contributing/). We’ve
personally chosen to devote our time and skills to making Qubes freely
available to the world because we believe that being open-source is
essential to Qubes being trustworthy and secure. If Qubes is valuable to
you, we ask that you please consider making a donation (https://www.qubes-os.org/donate/) to the project.
With your support, we can continue to make reasonable security a reality
for many years to come.
Join us at Root Linux Conference Happening in Kyiv, Ukraine This April!
https://blog.xenproject.org/2018/03/30/join-us-at-root-linux-conference-happening-in-kyiv-ukraine-this-april/
Root Linux Conference is coming to Kyiv, Ukraine on April 14th. The conference is the biggest Linux and embedded conference in Eastern Europe with presenters exploring topics like: Linux in mobile devices, wearables, medical equipment, vehicles, and more. Want to learn about the next generation of embedded solutions? This is the conference for you. Juergen […]
https://blog.xenproject.org/2018/03/30/join-us-at-root-linux-conference-happening-in-kyiv-ukraine-this-april/
Root Linux Conference is coming to Kyiv, Ukraine on April 14th. The conference is the biggest Linux and embedded conference in Eastern Europe with presenters exploring topics like: Linux in mobile devices, wearables, medical equipment, vehicles, and more. Want to learn about the next generation of embedded solutions? This is the conference for you. Juergen […]