Qubes Security Bulletin #28
138 views
Skip to first unread message
Marek Marczykowski-Górecki
Dec 20, 2016, 5:48:53 AM12/20/16
to qubes-announce, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Dear Qubes community,
We have just published Qubes Security Bulletin (QSB) #28: Debian update
mechanism vulnerability.
The current text of this QSB is reproduced below. The latest version,
including any future corrections, will always be available in the Qubes
Security Pack (qubes-secpack).
View QSB #28 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-028-2016.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/doc/security-pack/
View all past QSBs:
https://www.qubes-os.org/doc/security-bulletins/
- --------------------------------------------------------------------------------
---===[ Qubes Security Bulletin #28 ]===---
December 19, 2016
Debian update mechanism vulnerability
Quick Summary
==============
The Debian Security Team has announced a security bug (DSA-3733-1) in
the signature verification of repository metadata, which could lead to
privilege escalation [1] within a Debian-based VM. This bug does _not_
allow escape from any VM or enable any attacks on other parts of the
Qubes system. In particular, this bug does _not_ affect dom0, the Xen
hypervisor, and non-Debian-based VMs. Nevertheless, we have decided to
release this bulletin, because if a TemplateVM is affected, then every
VM based on that template is affected.
Description of the bug
=======================
As described in [1]:
| Jann Horn of Google Project Zero discovered that APT, the high level
| package manager, does not properly handle errors when validating
| signatures on InRelease files. An attacker able to man-in-the-middle
| HTTP requests to an apt repository that uses InRelease files
| (clearsigned Release files), can take advantage of this flaw to
| circumvent the signature of the InRelease file, leading to arbitrary
| code execution.
The Debian APT repository format includes the InRelease file, which is
a clearsigned Release file. APT, while verifying the file, splits it
into two files, `Release` and `Release.gpg`, in order to verify the
signature. However, it then splits the initial `InRelease` file again
in order to strip the signature (along with any potential leading or
trailing garbage) to get the actual `Release` file. Jann Horn
discovered that even though APT uses exactly the same code to split the
file in both cases, it can be tricked into outputting different results
in those two calls. The loop processing input looks like this:
bool SplitClearSignedFile(std::string const &InFile, FileFd * const ContentFile,
std::vector<std::string> * const ContentHeader, FileFd * const SignatureFile)
{
FILE *in = fopen(InFile.c_str(), "r");
if (in == NULL)
return _error->Errno("fopen", "can not open %s", InFile.c_str());
(...)
char *buf = NULL;
size_t buf_size = 0;
while (getline(&buf, &buf_size, in) != -1)
{
(...)
According to the getline documentation, it may return -1 only in the
case of:
- invalid arguments
- end of file
Authors believe that arguments are correct, so the only other case
considered is end of file. It turns out, however, that '-1' can also be
triggered by an out-of-memory error. This will result in the output
file being truncated. If this happens during the second InRelease
split, before APT finds the beginning of the signed data (the part
which would normally be discarded), then APT will use the found
(unverified) data as the Release file directly.
An attacker controlling a repository (by performing a man-in-the-middle
attack, breaking into the server, or simply being the server
administrator) could try to exploit this vulnerability in order to
substitute a normal package with a malicious one. Since a package can
contain post-installation scripts that APT will run automatically,
a malicious package can compromise the operating system into which it
is installed. In the case of Qubes OS, an attacker could try to use
this method to compromise a Debian-based TemplateVM (and, consequently,
all VMs based on it).
To trigger an out-of-memory condition during one call but not the
other, the discoverer used [2] very long lines, which may not fit into
the limited address space on a 32-bit system, additionally constrained
by ASLR. This attack vector allows successful exploitation in about one
out of four attempts.
The same attack vector isn't feasible for 64-bit systems (such as
Qubes VMs), because the address space is much larger. In particular,
it's larger than the available memory. But an attacker may try to hit a
real out-of-memory condition. This is a much less reliable approach and
should be easy to spot by the user, since the operation will likely
take a very long time and disk use will be very high (due to writing
data to swap).
Impact
=======
In theory, this bug allows an attacker to take over any Debian 8 or
Debian 9 template (which includes Whonix templates [3]) and,
consequently, any VMs based on those templates. However, for the
reasons explained above, the configuration used in Qubes OS happens to
makes this bug hard to exploit. Nevertheless, one should never
underestimate the creativity of exploit authors, and thus one should
assume that the bug is exploitable and patch immediately, just to stay
on the safe side.
Additional discussion
======================
Normally, we do not release Qubes Security Bulletins (QSBs) to address
vulnerabilities that only affect VMs internally without affecting
the rest of the Qubes system, i.e. vulnerabilities that do not
undermine the Qubes security model.
For example, we do not release QSBs to address bugs in Firefox or
Linux kernel USB stacks, because Qubes OS has been designed under the
primary assumption that in a typical desktop OS there will be countless
such bugs and that humankind will never be able to patch all of them
promptly (before developers introduce new bugs). This is, in fact, the
very reason we designed Qubes OS as an implementation of the Security
by Compartmentalization approach.
The Debian updater bug discussed today is, however, somewhat special.
While it is indeed a bug that only affects VMs internally, it could
allow an attacker to compromise TemplateVMs, which are used as a
basis for creating other VMs, such as AppVMs and ServiceVMs. If a
TemplateVM is compromised, then all the VMs based on that TemplateVM
will be compromised. Since AppVMs operate directly on user data, and
since ServiceVMs can be critical to user privacy (especially in the
case of Whonix and VPN ProxyVMs), this is a serious matter.
In Qubes OS, we take special precautions to make TemplateVMs difficult
to compromise. For example, we use the FirewallVM to block all network
connections to and from templates, with one exception: We allow
templates to connect to the so-called "Update Proxy" (which runs in the
Firewall VM). This allows the TemplateVM to retrieve updates while
protecting users from accidentally using TemplateVMs to perform risky
activities, such as browsing the web.
Since the bug under discussion has the potential to subvert this very
protection mechanism, we've decided to issue this QSB.
We would like to point out, however, that Qubes OS does a good job of
mitigating this kind of a vulnerability. Instead of having to reinstall
the whole operating system from scratch, Qubes users need only to
reinstall the affected template(s).
If users are concerned that potential attackers may have compromised
not only the root filesystem of the template, but also attempted to
infect user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser
profile directory), Qubes allows for mounting each of the suspected
AppVM private images into a different, trusted VM, based on a trusted
template, for "offline" analysis and cleanup, allowing users to
preserve their data.
Patching
=========
The specific packages that resolve the problem discussed in this
bulletin have been released by the Debian Security Team to the
appropriate repository. See the upstream advisory [1] for more details.
As the bug affects Debian-based templates themselves, just applying
updates may not be enough, if those VMs are already compromised. Users,
especially those using Debian-based VMs for sensitive tasks, should
remove all affected templates and install fresh ones. This also applies
to any customized Debian-based templates. Users with customized Debian-
based templates should first note their customizations, remove the
potentially compromised templates, install fresh templates, clone
them, and reapply their customizations to the cloned templates.
The procedure for removing affected templates and installing fresh ones
is documented as the "Manual Reinstallation Method" in the Qubes
documentation on reinstalling TemplateVMs [5]. (Please note that the
simplified template reinstallation method described in the
documentation, which uses `--action=reinstall`, is not sufficient,
since it will download the old, vulnerable template.)
Fixed APT packages are included in templates listed below:
For Qubes 3.2:
* qubes-template-debian-8-3.0.6-201612171620
* qubes-template-whonix-gw-3.0.6-201612182342
* qubes-template-whonix-ws-3.0.6-201612190628
For Qubes 3.1:
* qubes-template-debian-8-3.0.6-201612171837
* qubes-template-whonix-gw-3.0.6-201612190009
* qubes-template-whonix-ws-3.0.6-201612190633
Alternative patching, for non-critical TemplateVMs
===================================================
Users who do not rely on Debian-based VMs for any critical tasks may
instead opt just to install fixed APT packages. As the bug is present
in the update mechanism itself, special care should be taken while
performing the update:
1. Open a terminal in the affected TemplateVM.
2. Download repository metadata:
sudo apt-get update
3. Check whether any of the downloaded `InRelease` files contain lines
longer than 1024 characters [4]:
wc -L /var/lib/apt/lists/*InRelease
4. If no lines are longer than 1024 characters, continue with the
update:
sudo apt-get dist-upgrade
Repeat this procedure for every non-critical affected TemplateVM.
Credits
========
This bug was found by Jonn Horn of Google Project Zero and
reported to the Debian Security Team.
Discussion of the bug and exploitation provided by Marek
Marczykowski-Górecki of the Qubes OS project.
Additional discussion of the bug's importance for Qubes OS
by Joanna Rutkowska of the Qubes OS project.
Revision and editing of this bulletin by Andrew David Wong
of the Qubes OS project.
References
===========
[1] https://www.debian.org/security/2016/dsa-3733
[2] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
[3] https://www.whonix.org/wiki/CVE-2016-1252
[4] https://lists.debian.org/debian-security/2016/12/msg00010.html
[5]
https://www.qubes-os.org/doc/reinstall-template/#manual-reinstallation-method
- --
The Qubes Security Team
https://www.qubes-os.org/security/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYWQyWAAoJENuP0xzK19csPP8H/iQ3HlIoL262L/xytkdKEYtF
+dHaxAovFpOQ6Ixs9zokR0r2q0JAJDg/QC3qgSlr8c3fkJ5reOTa8JcVrZNJFbKX
hZz7nRyzmw67y2H2SY0liC1kIYJ2idfBJsFSAT8ImrDNqi30cj7mDBKpCjeRXGDH
1hzlDWrALUJrP5V9qIgIQ3FmotXUSMxvq8OO7ammJtgN+QqHfYSYNjL2Wf22BC4t
ZNTYxeIr//uYCmsI4oi8x/qwBk8KhWCGncQBLsVt9TzYwwccTx5fEPFlmOIp8c1w
qt90IoT1nrEOxSHkUKjTYee5YGZoRjOnHd2hzrLgoDfH5TVpDz2GDWVtPcRt65I=
=snpd
-----END PGP SIGNATURE-----
Hash: SHA256
Dear Qubes community,
We have just published Qubes Security Bulletin (QSB) #28: Debian update
mechanism vulnerability.
The current text of this QSB is reproduced below. The latest version,
including any future corrections, will always be available in the Qubes
Security Pack (qubes-secpack).
View QSB #28 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-028-2016.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/doc/security-pack/
View all past QSBs:
https://www.qubes-os.org/doc/security-bulletins/
- --------------------------------------------------------------------------------
---===[ Qubes Security Bulletin #28 ]===---
December 19, 2016
Debian update mechanism vulnerability
Quick Summary
==============
The Debian Security Team has announced a security bug (DSA-3733-1) in
the signature verification of repository metadata, which could lead to
privilege escalation [1] within a Debian-based VM. This bug does _not_
allow escape from any VM or enable any attacks on other parts of the
Qubes system. In particular, this bug does _not_ affect dom0, the Xen
hypervisor, and non-Debian-based VMs. Nevertheless, we have decided to
release this bulletin, because if a TemplateVM is affected, then every
VM based on that template is affected.
Description of the bug
=======================
As described in [1]:
| Jann Horn of Google Project Zero discovered that APT, the high level
| package manager, does not properly handle errors when validating
| signatures on InRelease files. An attacker able to man-in-the-middle
| HTTP requests to an apt repository that uses InRelease files
| (clearsigned Release files), can take advantage of this flaw to
| circumvent the signature of the InRelease file, leading to arbitrary
| code execution.
The Debian APT repository format includes the InRelease file, which is
a clearsigned Release file. APT, while verifying the file, splits it
into two files, `Release` and `Release.gpg`, in order to verify the
signature. However, it then splits the initial `InRelease` file again
in order to strip the signature (along with any potential leading or
trailing garbage) to get the actual `Release` file. Jann Horn
discovered that even though APT uses exactly the same code to split the
file in both cases, it can be tricked into outputting different results
in those two calls. The loop processing input looks like this:
bool SplitClearSignedFile(std::string const &InFile, FileFd * const ContentFile,
std::vector<std::string> * const ContentHeader, FileFd * const SignatureFile)
{
FILE *in = fopen(InFile.c_str(), "r");
if (in == NULL)
return _error->Errno("fopen", "can not open %s", InFile.c_str());
(...)
char *buf = NULL;
size_t buf_size = 0;
while (getline(&buf, &buf_size, in) != -1)
{
(...)
According to the getline documentation, it may return -1 only in the
case of:
- invalid arguments
- end of file
Authors believe that arguments are correct, so the only other case
considered is end of file. It turns out, however, that '-1' can also be
triggered by an out-of-memory error. This will result in the output
file being truncated. If this happens during the second InRelease
split, before APT finds the beginning of the signed data (the part
which would normally be discarded), then APT will use the found
(unverified) data as the Release file directly.
An attacker controlling a repository (by performing a man-in-the-middle
attack, breaking into the server, or simply being the server
administrator) could try to exploit this vulnerability in order to
substitute a normal package with a malicious one. Since a package can
contain post-installation scripts that APT will run automatically,
a malicious package can compromise the operating system into which it
is installed. In the case of Qubes OS, an attacker could try to use
this method to compromise a Debian-based TemplateVM (and, consequently,
all VMs based on it).
To trigger an out-of-memory condition during one call but not the
other, the discoverer used [2] very long lines, which may not fit into
the limited address space on a 32-bit system, additionally constrained
by ASLR. This attack vector allows successful exploitation in about one
out of four attempts.
The same attack vector isn't feasible for 64-bit systems (such as
Qubes VMs), because the address space is much larger. In particular,
it's larger than the available memory. But an attacker may try to hit a
real out-of-memory condition. This is a much less reliable approach and
should be easy to spot by the user, since the operation will likely
take a very long time and disk use will be very high (due to writing
data to swap).
Impact
=======
In theory, this bug allows an attacker to take over any Debian 8 or
Debian 9 template (which includes Whonix templates [3]) and,
consequently, any VMs based on those templates. However, for the
reasons explained above, the configuration used in Qubes OS happens to
makes this bug hard to exploit. Nevertheless, one should never
underestimate the creativity of exploit authors, and thus one should
assume that the bug is exploitable and patch immediately, just to stay
on the safe side.
Additional discussion
======================
Normally, we do not release Qubes Security Bulletins (QSBs) to address
vulnerabilities that only affect VMs internally without affecting
the rest of the Qubes system, i.e. vulnerabilities that do not
undermine the Qubes security model.
For example, we do not release QSBs to address bugs in Firefox or
Linux kernel USB stacks, because Qubes OS has been designed under the
primary assumption that in a typical desktop OS there will be countless
such bugs and that humankind will never be able to patch all of them
promptly (before developers introduce new bugs). This is, in fact, the
very reason we designed Qubes OS as an implementation of the Security
by Compartmentalization approach.
The Debian updater bug discussed today is, however, somewhat special.
While it is indeed a bug that only affects VMs internally, it could
allow an attacker to compromise TemplateVMs, which are used as a
basis for creating other VMs, such as AppVMs and ServiceVMs. If a
TemplateVM is compromised, then all the VMs based on that TemplateVM
will be compromised. Since AppVMs operate directly on user data, and
since ServiceVMs can be critical to user privacy (especially in the
case of Whonix and VPN ProxyVMs), this is a serious matter.
In Qubes OS, we take special precautions to make TemplateVMs difficult
to compromise. For example, we use the FirewallVM to block all network
connections to and from templates, with one exception: We allow
templates to connect to the so-called "Update Proxy" (which runs in the
Firewall VM). This allows the TemplateVM to retrieve updates while
protecting users from accidentally using TemplateVMs to perform risky
activities, such as browsing the web.
Since the bug under discussion has the potential to subvert this very
protection mechanism, we've decided to issue this QSB.
We would like to point out, however, that Qubes OS does a good job of
mitigating this kind of a vulnerability. Instead of having to reinstall
the whole operating system from scratch, Qubes users need only to
reinstall the affected template(s).
If users are concerned that potential attackers may have compromised
not only the root filesystem of the template, but also attempted to
infect user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser
profile directory), Qubes allows for mounting each of the suspected
AppVM private images into a different, trusted VM, based on a trusted
template, for "offline" analysis and cleanup, allowing users to
preserve their data.
Patching
=========
The specific packages that resolve the problem discussed in this
bulletin have been released by the Debian Security Team to the
appropriate repository. See the upstream advisory [1] for more details.
As the bug affects Debian-based templates themselves, just applying
updates may not be enough, if those VMs are already compromised. Users,
especially those using Debian-based VMs for sensitive tasks, should
remove all affected templates and install fresh ones. This also applies
to any customized Debian-based templates. Users with customized Debian-
based templates should first note their customizations, remove the
potentially compromised templates, install fresh templates, clone
them, and reapply their customizations to the cloned templates.
The procedure for removing affected templates and installing fresh ones
is documented as the "Manual Reinstallation Method" in the Qubes
documentation on reinstalling TemplateVMs [5]. (Please note that the
simplified template reinstallation method described in the
documentation, which uses `--action=reinstall`, is not sufficient,
since it will download the old, vulnerable template.)
Fixed APT packages are included in templates listed below:
For Qubes 3.2:
* qubes-template-debian-8-3.0.6-201612171620
* qubes-template-whonix-gw-3.0.6-201612182342
* qubes-template-whonix-ws-3.0.6-201612190628
For Qubes 3.1:
* qubes-template-debian-8-3.0.6-201612171837
* qubes-template-whonix-gw-3.0.6-201612190009
* qubes-template-whonix-ws-3.0.6-201612190633
Alternative patching, for non-critical TemplateVMs
===================================================
Users who do not rely on Debian-based VMs for any critical tasks may
instead opt just to install fixed APT packages. As the bug is present
in the update mechanism itself, special care should be taken while
performing the update:
1. Open a terminal in the affected TemplateVM.
2. Download repository metadata:
sudo apt-get update
3. Check whether any of the downloaded `InRelease` files contain lines
longer than 1024 characters [4]:
wc -L /var/lib/apt/lists/*InRelease
4. If no lines are longer than 1024 characters, continue with the
update:
sudo apt-get dist-upgrade
Repeat this procedure for every non-critical affected TemplateVM.
Credits
========
This bug was found by Jonn Horn of Google Project Zero and
reported to the Debian Security Team.
Discussion of the bug and exploitation provided by Marek
Marczykowski-Górecki of the Qubes OS project.
Additional discussion of the bug's importance for Qubes OS
by Joanna Rutkowska of the Qubes OS project.
Revision and editing of this bulletin by Andrew David Wong
of the Qubes OS project.
References
===========
[1] https://www.debian.org/security/2016/dsa-3733
[2] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
[3] https://www.whonix.org/wiki/CVE-2016-1252
[4] https://lists.debian.org/debian-security/2016/12/msg00010.html
[5]
https://www.qubes-os.org/doc/reinstall-template/#manual-reinstallation-method
- --
The Qubes Security Team
https://www.qubes-os.org/security/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYWQyWAAoJENuP0xzK19csPP8H/iQ3HlIoL262L/xytkdKEYtF
+dHaxAovFpOQ6Ixs9zokR0r2q0JAJDg/QC3qgSlr8c3fkJ5reOTa8JcVrZNJFbKX
hZz7nRyzmw67y2H2SY0liC1kIYJ2idfBJsFSAT8ImrDNqi30cj7mDBKpCjeRXGDH
1hzlDWrALUJrP5V9qIgIQ3FmotXUSMxvq8OO7ammJtgN+QqHfYSYNjL2Wf22BC4t
ZNTYxeIr//uYCmsI4oi8x/qwBk8KhWCGncQBLsVt9TzYwwccTx5fEPFlmOIp8c1w
qt90IoT1nrEOxSHkUKjTYee5YGZoRjOnHd2hzrLgoDfH5TVpDz2GDWVtPcRt65I=
=snpd
-----END PGP SIGNATURE-----
Chris Laprise
Dec 20, 2016, 12:37:32 PM12/20/16
to qubes-users, qubes-announce
Regarding the "Alternate Patching Method" using normal apt update: Its
possible the template was attacked via updates even before the bug was
announced, or sometime between the Debian announcement and now. The
"check InRelease" only helps if the attack occurs only during the next
update and not before. Otherwise, the user has no way of knowing if
their template has been compromised before doing this special update
procedure.
Replacing the template as described in "Patching" section provides much
more certainty.
Chris
possible the template was attacked via updates even before the bug was
announced, or sometime between the Debian announcement and now. The
"check InRelease" only helps if the attack occurs only during the next
update and not before. Otherwise, the user has no way of knowing if
their template has been compromised before doing this special update
procedure.
Replacing the template as described in "Patching" section provides much
more certainty.
Chris
Marek Marczykowski-Górecki
Dec 20, 2016, 12:49:18 PM12/20/16
to Chris Laprise, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
is recommended to replace them. And why this method is the primary one.
But for less trusted (like those you may assume being compromised
anyway) it's ok to ust "alternative" method. For example I have one
template which I use only for stuff distributed as not signed tarballs
only. I'm fairly sure there were far easier methods to compromise this
template in the past. And I use it only for some testing VMs.
- --
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-----
Version: GnuPG v2
iQEcBAEBCAAGBQJYWW8gAAoJENuP0xzK19csR10H/jAKT5S3yS5b5hMZZ7DbFWYK
Version: GnuPG v2
3OncMxl+Tcca336Xn96ekP2othIWgpLfqaRgrSr9wtAIlZST9/97Wf/4jI8OcIFy
2KHR4CfUb/hAhG8nfEGdBrSc103l8/YVDuOMQYY7ndUxX8SKCB45278VBiCAXtNH
xp7rVxwfIM8+g+HOIdqTdBXudjtGFcHP5RSVBwzmUU2KCXAuTtYLyWkmZLRLGg5A
zi9QaWbvvwD/Kpxo0vuljW26JS3FoB+9/pxgawcFRWk+A263enV9K2/6tL5cJaQP
SoxRzGhsYUQwJf8lqTrlUAEgVmB0rs6nrDBQPNQz85cCRWDg5D/tpxYcLH/sOkI=
=jh0W
-----END PGP SIGNATURE-----
'091348'0194328'0913284'09418
Dec 24, 2016, 3:15:44 AM12/24/16
to qubes-users
Hello,
so I must consider that all VM updates are corrupt also?
I should consider that all data, which get processed are corrupt also?
I should consider, if I transferred this data into other VM's, these VM's like a "storage VM" is corrupt also and if the files get executed in this VM or other ones, all data in might be compromised also?
Is there some efficient way to see this network of tasks and how to clean the system/data efficient and complete?
Perhaps some extra encryption would help to protect data inside compromised VM's, so this will minimize these effects...
How I can integrate some file/folder encryption command direct into the context menu of the Qubes Filemanager to increase the usability a little bit?
Kind Regards
Andrew David Wong
Dec 24, 2016, 7:01:41 AM12/24/16
to '091348'0194328'0913284'09418, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 2016-12-24 00:15, '091348'0194328'0913284'09418 wrote:
> Hello,
>
> so I must consider that all VM updates are corrupt also?
>
> I should consider that all data, which get processed are corrupt
> also?
>
> I should consider, if I transferred this data into other VM's,
> these VM's like a "storage VM" is corrupt also and if the files get
> executed in this VM or other ones, all data in might be compromised
> also?
>
Potentially, yes.
> Is there some efficient way to see this network of tasks and how to
> clean the system/data efficient and complete?
>
Not that I'm aware of.
> Perhaps some extra encryption would help to protect data inside
> compromised VM's, so this will minimize these effects...
>
Per-VM encryption is planned, but it wouldn't necessarily protect data
inside compromised VMs if you decrypt the VM while it's compromised.
In general, nothing can guarantee protection of data inside
compromised VMs, since a compromised VM has potentially complete
control over what goes on inside of itself. (However, it's possible
for you to mount a VM offline for forensic analysis, and certain kinds
of hypervisor-based VM introspection are possible. But such features
are not natively supported by Qubes, the latter for security reasons.)
> How I can integrate some file/folder encryption command direct into
> the context menu of the Qubes Filemanager to increase the usability
> a little bit?
>
It depends on what you mean, but if it's an app inside of a VM, then
you would do this in the usual way -- the same as for every other
application in an AppVM.
If it's a custom menu entry you seek, then try searching the recent
threads. There have been many requests for this lately. It would be
great if we could get some better documentation on it.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJYXmNyAAoJENtN07w5UDAwOY8QAM21bsOu85OYiyeTrp672Vey
tmDPt8/NuCW/GcUxFkwIDAXbYlpeYhCm1SvCJJ0ZzSSaf0LA29/8qVb+v5Gr8+no
iJYDOL8eQCyLS/eSdMPQky2XhGMNPuAmzfQcnft7N+M7qxqKxRF6c4oFn0TA9bOZ
t7dVtGlkl+RNt9mrzLfON0KF/OZSX593dFArxMiiKyro4PKNy5cFsriRbMTd9ob3
qK1JjOICwj3s/pJBWzzPz44Kmmnj+IpIFtGnW65FR0WHCeYA7BZKFBjYm+JUTSH6
E8M2gRubFEEJY/w+k6upiJ6jC2pYZhg0eUNsuQc0LADQTMss0ca7jPa3fHcEQ37f
XYKFjuhQeyU7XsoGxvVeIJQCrVwB0ivHtEMLBNeHP+Q2TaVgr+1gwuv2fUfXj1U2
qUV8Sk1Z418Q7FSs1VxLPJRNJvv3vS/ACcDJNy2FjBAXUYvM5v7ZQ6tjPZu3o0EM
Vc7PAG6fDm4RiWHG8ZL3Xv+1ulwStCgLO0Bk5c1KCAhFpMoll6WFG/WF7X9WKPBa
Bc+zli43RD6yRb/flqXpsP8az+HdAt56f+G1AJao7yPowIpfgfZJ3UWhBv0fEkKw
+gQiiNvMQ2GfQXrOGjuKJMzAXYsUkTs4O9d0hJRazGM7n+1HIPt4dhl02FNff50q
XVfpL4xXMw4+9iJpl4Ms
=LTPx
-----END PGP SIGNATURE-----
Hash: SHA512
On 2016-12-24 00:15, '091348'0194328'0913284'09418 wrote:
> Hello,
>
> so I must consider that all VM updates are corrupt also?
>
> I should consider that all data, which get processed are corrupt
> also?
>
> I should consider, if I transferred this data into other VM's,
> these VM's like a "storage VM" is corrupt also and if the files get
> executed in this VM or other ones, all data in might be compromised
> also?
>
> Is there some efficient way to see this network of tasks and how to
> clean the system/data efficient and complete?
>
> Perhaps some extra encryption would help to protect data inside
> compromised VM's, so this will minimize these effects...
>
inside compromised VMs if you decrypt the VM while it's compromised.
In general, nothing can guarantee protection of data inside
compromised VMs, since a compromised VM has potentially complete
control over what goes on inside of itself. (However, it's possible
for you to mount a VM offline for forensic analysis, and certain kinds
of hypervisor-based VM introspection are possible. But such features
are not natively supported by Qubes, the latter for security reasons.)
> How I can integrate some file/folder encryption command direct into
> the context menu of the Qubes Filemanager to increase the usability
> a little bit?
>
you would do this in the usual way -- the same as for every other
application in an AppVM.
If it's a custom menu entry you seek, then try searching the recent
threads. There have been many requests for this lately. It would be
great if we could get some better documentation on it.
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJYXmNyAAoJENtN07w5UDAwOY8QAM21bsOu85OYiyeTrp672Vey
tmDPt8/NuCW/GcUxFkwIDAXbYlpeYhCm1SvCJJ0ZzSSaf0LA29/8qVb+v5Gr8+no
iJYDOL8eQCyLS/eSdMPQky2XhGMNPuAmzfQcnft7N+M7qxqKxRF6c4oFn0TA9bOZ
t7dVtGlkl+RNt9mrzLfON0KF/OZSX593dFArxMiiKyro4PKNy5cFsriRbMTd9ob3
qK1JjOICwj3s/pJBWzzPz44Kmmnj+IpIFtGnW65FR0WHCeYA7BZKFBjYm+JUTSH6
E8M2gRubFEEJY/w+k6upiJ6jC2pYZhg0eUNsuQc0LADQTMss0ca7jPa3fHcEQ37f
XYKFjuhQeyU7XsoGxvVeIJQCrVwB0ivHtEMLBNeHP+Q2TaVgr+1gwuv2fUfXj1U2
qUV8Sk1Z418Q7FSs1VxLPJRNJvv3vS/ACcDJNy2FjBAXUYvM5v7ZQ6tjPZu3o0EM
Vc7PAG6fDm4RiWHG8ZL3Xv+1ulwStCgLO0Bk5c1KCAhFpMoll6WFG/WF7X9WKPBa
Bc+zli43RD6yRb/flqXpsP8az+HdAt56f+G1AJao7yPowIpfgfZJ3UWhBv0fEkKw
+gQiiNvMQ2GfQXrOGjuKJMzAXYsUkTs4O9d0hJRazGM7n+1HIPt4dhl02FNff50q
XVfpL4xXMw4+9iJpl4Ms
=LTPx
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages