One offline qube for writing. It runs only LibreOffice Writer. This is
where Bob does all of his writing. This window is usually open side-by-side
with another window containing research or material from a source.
Multiple email qubes. One is for receiving emails from the general
public. Another is for emailing his editor and colleagues. Both are based on
a minimal template (https://www.qubes-os.org/doc/templates/minimal/) with Thunderbird installed.
He’s configured both to open all attachments in
disposables (https://www.qubes-os.org/doc/how-to-use-disposables/) that are offline in case an
attachment contains a beacon that tries to phone home.
Whonix qubes. He has the standard sys-whonix service qube for providing
Torified network access, and he uses disposable anon-workstation app qubes
for using Tor Browser to do research on stories he’s writing. Since the topic
is often of a sensitive nature and might implicate powerful individuals, it’s
important that he be able to conduct this research with a degree of
anonymity. He doesn’t want the subjects of his investigation to know that
he’s looking into them. He also doesn’t want his network requests being
traced back to his work or home IP addresses. Whonix helps with both of these
concerns. He also has another Whonix-based disposable template for receiving
tips anonymously via Tor, since some high-risk whistleblowers he’s interacted
with have said that they can’t take a chance with any other form of
communication.
Two qubes for
Signal (https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/signal.md).
Bob has two Signal app qubes (both on the same template in which the Signal
desktop app is installed). One is linked to his own mobile number for
communicating with co-workers and other known, trusted contacts. The other is
a public number that serves as an additional way for sources to reach him
confidentially. This is especially useful for individuals who don’t use Tor
but for whom unencrypted communication could be dangerous.
Several data vaults. When someone sends Bob material that turns out to be
useful, or when he comes across useful material while doing his own research,
he stores a copy in a completely offline, network-isolated vault qube. Most
of these files are PDFs and images, though some are audio files, videos, and
text files. Since most of them are from unknown or untrusted sources, Bob
isn’t sure if it would be safe to put them all in the same vault, so he makes
different vaults (usually one for each story or topic) just in case. This has
the side benefit of helping to keep things organized.
A VPN
qube (https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md)
and associated qubes for accessing work resources. The servers at work can
only be accessed from the organization’s network, so Bob has certain qubes
that are connected to a VPN qube so that he can upload his work and access
anything he needs on the local network when he’s not physically there.
A password manager vault. Bob stores all of his login credentials in the
default password manager that came with his offline vault qube. He securely
copies and pastes (https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) them into other qubes as
needed.
A colleague helped Bob set up his Qubes system initially and showed him how to
use it. Since Bob’s workflow is pretty consistent and straightforward, the way
his qubes are organized doesn’t change much, and this is just fine by him. His
colleague told him to remember a few simple rules: Don’t copy or move
text (https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) or
files (https://www.qubes-os.org/doc/how-to-copy-and-move-files/) from less trusted to more trusted
qubes; update (https://www.qubes-os.org/doc/how-to-update/) your system when prompted; and make
regular backups (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/). Bob doesn’t have
where Bob does all of his writing. This window is usually open side-by-side
with another window containing research or material from a source.
Multiple email qubes. One is for receiving emails from the general
public. Another is for emailing his editor and colleagues. Both are based on
a minimal template (https://www.qubes-os.org/doc/templates/minimal/) with Thunderbird installed.
He’s configured both to open all attachments in
disposables (https://www.qubes-os.org/doc/how-to-use-disposables/) that are offline in case an
attachment contains a beacon that tries to phone home.
Whonix qubes. He has the standard sys-whonix service qube for providing
Torified network access, and he uses disposable anon-workstation app qubes
for using Tor Browser to do research on stories he’s writing. Since the topic
is often of a sensitive nature and might implicate powerful individuals, it’s
important that he be able to conduct this research with a degree of
anonymity. He doesn’t want the subjects of his investigation to know that
he’s looking into them. He also doesn’t want his network requests being
traced back to his work or home IP addresses. Whonix helps with both of these
concerns. He also has another Whonix-based disposable template for receiving
tips anonymously via Tor, since some high-risk whistleblowers he’s interacted
with have said that they can’t take a chance with any other form of
communication.
Two qubes for
Signal (https://github.com/Qubes-Community/Contents/blob/master/docs/privacy/signal.md).
Bob has two Signal app qubes (both on the same template in which the Signal
desktop app is installed). One is linked to his own mobile number for
communicating with co-workers and other known, trusted contacts. The other is
a public number that serves as an additional way for sources to reach him
confidentially. This is especially useful for individuals who don’t use Tor
but for whom unencrypted communication could be dangerous.
Several data vaults. When someone sends Bob material that turns out to be
useful, or when he comes across useful material while doing his own research,
he stores a copy in a completely offline, network-isolated vault qube. Most
of these files are PDFs and images, though some are audio files, videos, and
text files. Since most of them are from unknown or untrusted sources, Bob
isn’t sure if it would be safe to put them all in the same vault, so he makes
different vaults (usually one for each story or topic) just in case. This has
the side benefit of helping to keep things organized.
A VPN
qube (https://github.com/Qubes-Community/Contents/blob/master/docs/configuration/vpn.md)
and associated qubes for accessing work resources. The servers at work can
only be accessed from the organization’s network, so Bob has certain qubes
that are connected to a VPN qube so that he can upload his work and access
anything he needs on the local network when he’s not physically there.
A password manager vault. Bob stores all of his login credentials in the
default password manager that came with his offline vault qube. He securely
copies and pastes (https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) them into other qubes as
needed.
A colleague helped Bob set up his Qubes system initially and showed him how to
use it. Since Bob’s workflow is pretty consistent and straightforward, the way
his qubes are organized doesn’t change much, and this is just fine by him. His
colleague told him to remember a few simple rules: Don’t copy or move
text (https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) or
files (https://www.qubes-os.org/doc/how-to-copy-and-move-files/) from less trusted to more trusted
qubes; update (https://www.qubes-os.org/doc/how-to-update/) your system when prompted; and make
regular backups (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/). Bob doesn’t have
the need to try out new software or tweak any settings, so he can do everything
he needs to do on a daily basis without having to interact with the command
line.
Carol, the investor
Carol works hard and lives below her means so that she can save money and
invest it for her future. She hopes to become financially independent and maybe
even retire early someday, and she’s decided that her best bet for achieving
this is by investing for the long term and allow compounding to do its work.
However, after doing some research into her country’s consumer financial
protection laws, she learned that there’s no legal guarantee that customers
will be made whole in the event of theft or fraud. The various insurance and
protection organizations only guarantee recovery in the case of a financial
institution failing, which is quite different from an individual customer
being hacked. Moreover, even though many financial institutions have their own
cybercrime policies, rarely, if ever, do they explicitly guarantee
reimbursement in the event that a customer gets hacked (rather than the
institution itself).
Carol looked into how thieves might actually try to steal her hard-earned
wealth and was surprised to learn that they have all sorts of ploys that she
had never even considered. For example, she had assumed that any theft would,
at the bare minimum, have to involve transferring money out of her account.
That seems like a safe assumption. But then she read about "pump and dump"
attacks, where thieves buy up some penny stock, hack into innocent people's
brokerage accounts, then use the victims' funds to buy that same penny stock,
"pumping" up its price so that the thieves can "dump" their shares on the
market, leaving the victims with worthless shares. No money is ever
transferred into or out of the victims' account; it's just used to buy and
sell securities. So, all the safeguards preventing new bank accounts from
being added or requiring extra approval for outbound transfers do nothing to
protect victims' funds in cases like these. And this is just one example!
Carol realized that she couldn't assume that existing safeguards against
specific, known attacks were enough. She had to think about security at a
more fundamental level and design it into her digital life from the ground
up.
After learning about all this, Carol decided that it was ultimately up to her
to take care of her own cybersecurity. She couldn’t rely on anyone else to do
it for her. Sure, most people just use regular consumer tech and will probably
end up fine, but, she reminded herself, most people also don’t have as much to
lose. It’s not a risk that she was willing to take with her future, especially
knowing that there’s probably no government bailout waiting for her and that
all the brokerage firms’ vaguely reassuring marketing language about
cybersecurity isn’t legally binding. So, Carol started reading more about
computer security and eventually stumbled upon Qubes OS after searching the web
for “most secure operating system.” She read about how it’s designed and why.
Although she didn’t immediately understand all of the technical details, the
fundamental principle of security-by-compartmentalization (https://www.qubes-os.org/doc/architecture/)
made intuitive sense to her, and the more she learned about the technical
aspects, the more she realized that this is what she’d been looking for. Today,
her setup looks like this:
he needs to do on a daily basis without having to interact with the command
line.
Carol, the investor
Carol works hard and lives below her means so that she can save money and
invest it for her future. She hopes to become financially independent and maybe
even retire early someday, and she’s decided that her best bet for achieving
this is by investing for the long term and allow compounding to do its work.
However, after doing some research into her country’s consumer financial
protection laws, she learned that there’s no legal guarantee that customers
will be made whole in the event of theft or fraud. The various insurance and
protection organizations only guarantee recovery in the case of a financial
institution failing, which is quite different from an individual customer
being hacked. Moreover, even though many financial institutions have their own
cybercrime policies, rarely, if ever, do they explicitly guarantee
reimbursement in the event that a customer gets hacked (rather than the
institution itself).
Carol looked into how thieves might actually try to steal her hard-earned
wealth and was surprised to learn that they have all sorts of ploys that she
had never even considered. For example, she had assumed that any theft would,
at the bare minimum, have to involve transferring money out of her account.
That seems like a safe assumption. But then she read about "pump and dump"
attacks, where thieves buy up some penny stock, hack into innocent people's
brokerage accounts, then use the victims' funds to buy that same penny stock,
"pumping" up its price so that the thieves can "dump" their shares on the
market, leaving the victims with worthless shares. No money is ever
transferred into or out of the victims' account; it's just used to buy and
sell securities. So, all the safeguards preventing new bank accounts from
being added or requiring extra approval for outbound transfers do nothing to
protect victims' funds in cases like these. And this is just one example!
Carol realized that she couldn't assume that existing safeguards against
specific, known attacks were enough. She had to think about security at a
more fundamental level and design it into her digital life from the ground
up.
After learning about all this, Carol decided that it was ultimately up to her
to take care of her own cybersecurity. She couldn’t rely on anyone else to do
it for her. Sure, most people just use regular consumer tech and will probably
end up fine, but, she reminded herself, most people also don’t have as much to
lose. It’s not a risk that she was willing to take with her future, especially
knowing that there’s probably no government bailout waiting for her and that
all the brokerage firms’ vaguely reassuring marketing language about
cybersecurity isn’t legally binding. So, Carol started reading more about
computer security and eventually stumbled upon Qubes OS after searching the web
for “most secure operating system.” She read about how it’s designed and why.
Although she didn’t immediately understand all of the technical details, the
fundamental principle of security-by-compartmentalization (https://www.qubes-os.org/doc/architecture/)
made intuitive sense to her, and the more she learned about the technical
aspects, the more she realized that this is what she’d been looking for. Today,
her setup looks like this:
One qube for each investment firm and bank. Carol has a few different
retirement accounts, brokerage accounts, and bank accounts. She treats each
qube like a “secure terminal” for accessing only that one institution’s
website. She makes her transactions and saves any statements and
confirmations she downloads in that qube. She uses the Qubes
firewall (https://www.qubes-os.org/doc/firewall/) to enable access only to that institution’s website
in that qube so that she doesn’t accidentally visit any others. Since most of
what she does involves using websites and PDFs, most of Carol’s app qubes are
based on a minimal template (https://www.qubes-os.org/doc/templates/minimal/) with just a web
browser (which doubles as a PDF viewer) and a file manager installed.
One qube for all her credit card accounts. Carol started to make a
separate qube for each credit card account but ultimately decided against it.
For one thing, the consumer protections for credit card fraud in her country
are much better than for losing assets to theft or fraud in a bank or
brokerage account, so the security risk isn’t as high. Second, there’s
actually not a whole lot that an attacker could do with access to her credit
cards’ online accounts or her old credit card statements, since online access
to these generally doesn’t allow spending or withdrawing any money. So, even
the worst case scenario here wouldn’t be catastrophic, unlike with her bank
and brokerage accounts. Third, she’s not too worried about any of her credit
card company websites being used to attach each other or her qube (As long as
it’s contained to a single qube, she’s fine with that level of risk.) Last,
but not least: She has way too many credit cards! While Carol is very frugal,
she likes to collect the sign-up bonuses that are offered for opening new
cards, so she’s accumulated quite a few of them. (However, she’s always
careful to pay off her balance each month, so she never pays interest. She’s
also pretty disciplined about only spending what she would have spent
anyway and not being tempted to spend more just to meet a spending
requirement or because she can.) At any rate, Carol has decided that the tiny
benefit she stands to gain from having a separate qube for every credit card
website wouldn’t be worth the hassle of having to manage so many extra qubes.
A qube for credit monitoring, credit reports, and credit history
services. Carol has worked hard to build up a good credit score, and she’s
concerned about identity theft, so she has one qube dedicated to managing her
free credit monitoring services and downloading her free annual credit
reports.
Two qubes for taxes. Carol has a Windows
qube (https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows.md)
for running her Windows-only tax software. She also has an offline vault
where she stores all of her tax-related forms and documents, organized by
year.
A qube for financial planning and tracking. Carol loves spreadsheets, so
this offline qube is where she maintains a master spreadsheet to track all of
her investments and her savings rate. She also keeps her budgeting
spreadsheet, insurance spreadsheet, and written investment policy statement
here. This qube is based on a template with some additional productivity
software, like LibreOffice and Gnumeric (so that Carol can run her own Monte
Carlo simulations).
Various email qubes. Carol likes to have one email qube for her most
important financial accounts; a separate one for her credit cards accounts,
online shopping accounts, and insurance companies; and another one for
personal email. They’re all based on the same template with Thunderbird
installed.
A password manager vault. A network-isolated qube where Carol stores all
of her account usernames and passwords in KeePassXC. She uses the Qubes
global clipboard (https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) to copy and paste them
retirement accounts, brokerage accounts, and bank accounts. She treats each
qube like a “secure terminal” for accessing only that one institution’s
website. She makes her transactions and saves any statements and
confirmations she downloads in that qube. She uses the Qubes
firewall (https://www.qubes-os.org/doc/firewall/) to enable access only to that institution’s website
in that qube so that she doesn’t accidentally visit any others. Since most of
what she does involves using websites and PDFs, most of Carol’s app qubes are
based on a minimal template (https://www.qubes-os.org/doc/templates/minimal/) with just a web
browser (which doubles as a PDF viewer) and a file manager installed.
One qube for all her credit card accounts. Carol started to make a
separate qube for each credit card account but ultimately decided against it.
For one thing, the consumer protections for credit card fraud in her country
are much better than for losing assets to theft or fraud in a bank or
brokerage account, so the security risk isn’t as high. Second, there’s
actually not a whole lot that an attacker could do with access to her credit
cards’ online accounts or her old credit card statements, since online access
to these generally doesn’t allow spending or withdrawing any money. So, even
the worst case scenario here wouldn’t be catastrophic, unlike with her bank
and brokerage accounts. Third, she’s not too worried about any of her credit
card company websites being used to attach each other or her qube (As long as
it’s contained to a single qube, she’s fine with that level of risk.) Last,
but not least: She has way too many credit cards! While Carol is very frugal,
she likes to collect the sign-up bonuses that are offered for opening new
cards, so she’s accumulated quite a few of them. (However, she’s always
careful to pay off her balance each month, so she never pays interest. She’s
also pretty disciplined about only spending what she would have spent
anyway and not being tempted to spend more just to meet a spending
requirement or because she can.) At any rate, Carol has decided that the tiny
benefit she stands to gain from having a separate qube for every credit card
website wouldn’t be worth the hassle of having to manage so many extra qubes.
A qube for credit monitoring, credit reports, and credit history
services. Carol has worked hard to build up a good credit score, and she’s
concerned about identity theft, so she has one qube dedicated to managing her
free credit monitoring services and downloading her free annual credit
reports.
Two qubes for taxes. Carol has a Windows
qube (https://github.com/Qubes-Community/Contents/blob/master/docs/os/windows/windows.md)
for running her Windows-only tax software. She also has an offline vault
where she stores all of her tax-related forms and documents, organized by
year.
A qube for financial planning and tracking. Carol loves spreadsheets, so
this offline qube is where she maintains a master spreadsheet to track all of
her investments and her savings rate. She also keeps her budgeting
spreadsheet, insurance spreadsheet, and written investment policy statement
here. This qube is based on a template with some additional productivity
software, like LibreOffice and Gnumeric (so that Carol can run her own Monte
Carlo simulations).
Various email qubes. Carol likes to have one email qube for her most
important financial accounts; a separate one for her credit cards accounts,
online shopping accounts, and insurance companies; and another one for
personal email. They’re all based on the same template with Thunderbird
installed.
A password manager vault. A network-isolated qube where Carol stores all
of her account usernames and passwords in KeePassXC. She uses the Qubes
global clipboard (https://www.qubes-os.org/doc/how-to-copy-and-paste-text/) to copy and paste them
into her other qubes when she needs to log into her accounts.
Bonus: Carol explores new financial technology
The vast majority of Carol’s assets are in broad-based, low-cost,
passively-managed indexed funds. Lately, however, she’s started getting
interested in cryptocurrency. She’s still committed to staying the course with
her tried-and-true investments, and she’s always been skeptical of new asset
classes, especially those that don’t generate cash flows or that often seem to
be associated with scams or wild speculation. However, she finds the ability to
self-custody a portion of her assets appealing from a long-term risk management
perspective, particularly as a hedge against certain types of political risk.
Some of Carol's friends warned her that cryptocurrency is extremely volatile
and that hacking and theft are common occurrences. Carol agreed and reassured
them that she's educated herself about the risks and will make sure she never
invests more than she can afford to lose.
Carol has added the following to her Qubes setup:
A standalone qube for running Bitcoin Core and an offline wallet vault.
Carol finds the design and security properties of Bitcoin very interesting,
so she’s experimenting with running a full node. She also created a
network-isolated vault in order to try running a copy of Bitcoin Core
completely offline as a “cold storage” wallet. She’s still trying to figure
out how this compares to an actual hardware wallet, paper wallet, or
physically air-gapped machine, but she’s figures they all have different
security properties. She also recently heard about using Electrum as a
“split” wallet in
Qubes (https://github.com/Qubes-Community/Contents/blob/master/docs/security/split-bitcoin.md)
and is interested in exploring that further.
Whonix qubes. Carol read somewhere that Bitcoin nodes should be run over
Tor for privacy and security. She found it very convenient that Whonix is
already integrated into Qubes, so she simply set her Bitcoin Core “full node”
qube to use sys-whonix as its networking qube.
Various qubes for DeFi and web3. Carol has also started getting into DeFi
(decentralized finance) and web3 on Ethereum and other smart contract
blockchains, so a friend recommended that she get a Ledger hardware wallet.
She downloaded the Ledger Live software in an app qube and set up her system
to recognize the
Ledger (https://www.kicksecure.com/wiki/Ledger_Hardware_Wallet). She can now
start her USB qube (https://www.qubes-os.org/doc/usb-qubes/), plug her Ledger into it into a USB
port, use the Qubes Devices widget to attach it (https://www.qubes-os.org/doc/how-to-use-devices/)
to her Ledger Live qube, and from there she can interact with the software.
She has a separate qube with the Metamask extension installed in a web
browser. She can also use the Qubes Devices widget to attach her Ledger to
this qube so she can use Metamask in conjunction with her Ledger to interact
with smart contracts and decentralized exchanges.
Various qubes for research and centralized exchanges. Carol uses these
when she wants to check block explorer websites, coin listing and market cap
sites, aggregation tools, or just to see what the latest buzz is on Crypto
Twitter.
Carol makes sure to back up all of her qubes that contain important account
statements, confirmations, spreadsheets, cryptocurrency wallets, and her
password manager vault. If she has extra storage space, she’ll also back up her
templates and even her Bitcoin full node qube, but she’ll skip them if she
doesn’t have time or space, since she knows she can always recreate them again
later and download what she needs from the Internet.
Conclusion
The characters we’ve met today may be fictional, but they represent the needs
of real users like you. You may find that your own needs overlap with more than
one of them, in which case you may find it useful to model certain subsets of
Bonus: Carol explores new financial technology
The vast majority of Carol’s assets are in broad-based, low-cost,
passively-managed indexed funds. Lately, however, she’s started getting
interested in cryptocurrency. She’s still committed to staying the course with
her tried-and-true investments, and she’s always been skeptical of new asset
classes, especially those that don’t generate cash flows or that often seem to
be associated with scams or wild speculation. However, she finds the ability to
self-custody a portion of her assets appealing from a long-term risk management
perspective, particularly as a hedge against certain types of political risk.
Some of Carol's friends warned her that cryptocurrency is extremely volatile
and that hacking and theft are common occurrences. Carol agreed and reassured
them that she's educated herself about the risks and will make sure she never
invests more than she can afford to lose.
Carol has added the following to her Qubes setup:
A standalone qube for running Bitcoin Core and an offline wallet vault.
Carol finds the design and security properties of Bitcoin very interesting,
so she’s experimenting with running a full node. She also created a
network-isolated vault in order to try running a copy of Bitcoin Core
completely offline as a “cold storage” wallet. She’s still trying to figure
out how this compares to an actual hardware wallet, paper wallet, or
physically air-gapped machine, but she’s figures they all have different
security properties. She also recently heard about using Electrum as a
“split” wallet in
Qubes (https://github.com/Qubes-Community/Contents/blob/master/docs/security/split-bitcoin.md)
and is interested in exploring that further.
Whonix qubes. Carol read somewhere that Bitcoin nodes should be run over
Tor for privacy and security. She found it very convenient that Whonix is
already integrated into Qubes, so she simply set her Bitcoin Core “full node”
qube to use sys-whonix as its networking qube.
Various qubes for DeFi and web3. Carol has also started getting into DeFi
(decentralized finance) and web3 on Ethereum and other smart contract
blockchains, so a friend recommended that she get a Ledger hardware wallet.
She downloaded the Ledger Live software in an app qube and set up her system
to recognize the
Ledger (https://www.kicksecure.com/wiki/Ledger_Hardware_Wallet). She can now
start her USB qube (https://www.qubes-os.org/doc/usb-qubes/), plug her Ledger into it into a USB
port, use the Qubes Devices widget to attach it (https://www.qubes-os.org/doc/how-to-use-devices/)
to her Ledger Live qube, and from there she can interact with the software.
She has a separate qube with the Metamask extension installed in a web
browser. She can also use the Qubes Devices widget to attach her Ledger to
this qube so she can use Metamask in conjunction with her Ledger to interact
with smart contracts and decentralized exchanges.
Various qubes for research and centralized exchanges. Carol uses these
when she wants to check block explorer websites, coin listing and market cap
sites, aggregation tools, or just to see what the latest buzz is on Crypto
Twitter.
Carol makes sure to back up all of her qubes that contain important account
statements, confirmations, spreadsheets, cryptocurrency wallets, and her
password manager vault. If she has extra storage space, she’ll also back up her
templates and even her Bitcoin full node qube, but she’ll skip them if she
doesn’t have time or space, since she knows she can always recreate them again
later and download what she needs from the Internet.
Conclusion
The characters we’ve met today may be fictional, but they represent the needs
of real users like you. You may find that your own needs overlap with more than
one of them, in which case you may find it useful to model certain subsets of
your overall Qubes system on different examples. You probably also noticed that
there are commonalities among them. Most people need to use email, for example,
so most people will need at least one email qube and a suitable template to
base it on. But not everyone will need Split GPG (https://www.qubes-os.org/doc/split-gpg/), and not
everyone will want to use the same email client. On the other hand, almost
everyone will need a password manager, and it pretty much always makes sense to
keep it in an offline, network-isolated vault.
As you gain experience with Qubes, you may find yourself disagreeing with
some of the decisions our fictional friends made. That's okay! There are many
different ways to organize a Qubes system, and the most important criterion
is that it serves the needs of its owner. Since everyone's needs are
different, it's perfectly normal to find yourself doing things a bit
differently. Nonetheless, there are some general principles that almost all
users find helpful, especially when they're first starting out.
As you’re designing your own Qubes system, keep in mind some of the following
lessons from our case studies:
You’ll probably change your mind as you go. You’ll realize that one qube
should really be split into two, or you’ll realize that it doesn’t really
make sense for two qubes to be separate and that they should instead be
merged into one. That’s okay. Qubes OS supports your ability to adapt and
make changes as you go. Try to maintain a flexible mindset. Things will
eventually settle down, and you’ll find your groove. Changes to the way you
organize your qubes will become less drastic and less frequent over time.
Make frequent backups. (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) Losing
data is never fun, whether it’s from an accidental deletion, a system crash,
buggy software, or a hardware failure. By getting into the habit of making
frequent backups now, you’ll save yourself from a lot of pain in the future.
Many people never take backups seriously until they suffer catastrophic data
loss. That’s human nature. If you’ve experienced that before, then you know
the pain. Resolve now never to let it happen again. If you’ve never
experienced it, count yourself lucky and try to learn from the hard-won
experience of others. Keeping good backups also allows you to be a bit more
free with reorganizations. You can delete qubes that you think you won’t need
anymore without having to worry that you might need them again someday, since
you know you can always restore them from a backup.
Think about which programs you want to run and where you want to store
data. In some cases, it makes sense to run programs and store data in the
same qube, for example, if the data is generated by that program. In other
cases, it makes sense to have qubes that are exclusively for storing data
(e.g., offline data storage vaults) and other qubes that are exclusively for
running programs (e.g., web browser-only qubes). Remember that when you make
backups, it’s only essential to back up data that can’t be replaced. This can
allow you to achieve minimal backups that are quite small compared to the
total size of your installation. Templates, service qubes, and qubes that are
used exclusively for running programs and that contain no data don’t
necessarily have to be backed up as long as you’re confident that you can
recreate them if needed. This is why it’s a good practice to keep notes on
which packages you installed in which templates and which customizations and
configurations you made. Then you can refer to your notes the next time you
need to recreate those qubes. Of course, backing up everything is not a bad
idea either. It may require a bit more time and disk space upfront, but for
some people, it can be just as important as backing up their irreplaceable
data. If your system is mission-critical, and you can’t afford more than a
there are commonalities among them. Most people need to use email, for example,
so most people will need at least one email qube and a suitable template to
base it on. But not everyone will need Split GPG (https://www.qubes-os.org/doc/split-gpg/), and not
everyone will want to use the same email client. On the other hand, almost
everyone will need a password manager, and it pretty much always makes sense to
keep it in an offline, network-isolated vault.
As you gain experience with Qubes, you may find yourself disagreeing with
some of the decisions our fictional friends made. That's okay! There are many
different ways to organize a Qubes system, and the most important criterion
is that it serves the needs of its owner. Since everyone's needs are
different, it's perfectly normal to find yourself doing things a bit
differently. Nonetheless, there are some general principles that almost all
users find helpful, especially when they're first starting out.
As you’re designing your own Qubes system, keep in mind some of the following
lessons from our case studies:
You’ll probably change your mind as you go. You’ll realize that one qube
should really be split into two, or you’ll realize that it doesn’t really
make sense for two qubes to be separate and that they should instead be
merged into one. That’s okay. Qubes OS supports your ability to adapt and
make changes as you go. Try to maintain a flexible mindset. Things will
eventually settle down, and you’ll find your groove. Changes to the way you
organize your qubes will become less drastic and less frequent over time.
Make frequent backups. (https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/) Losing
data is never fun, whether it’s from an accidental deletion, a system crash,
buggy software, or a hardware failure. By getting into the habit of making
frequent backups now, you’ll save yourself from a lot of pain in the future.
Many people never take backups seriously until they suffer catastrophic data
loss. That’s human nature. If you’ve experienced that before, then you know
the pain. Resolve now never to let it happen again. If you’ve never
experienced it, count yourself lucky and try to learn from the hard-won
experience of others. Keeping good backups also allows you to be a bit more
free with reorganizations. You can delete qubes that you think you won’t need
anymore without having to worry that you might need them again someday, since
you know you can always restore them from a backup.
Think about which programs you want to run and where you want to store
data. In some cases, it makes sense to run programs and store data in the
same qube, for example, if the data is generated by that program. In other
cases, it makes sense to have qubes that are exclusively for storing data
(e.g., offline data storage vaults) and other qubes that are exclusively for
running programs (e.g., web browser-only qubes). Remember that when you make
backups, it’s only essential to back up data that can’t be replaced. This can
allow you to achieve minimal backups that are quite small compared to the
total size of your installation. Templates, service qubes, and qubes that are
used exclusively for running programs and that contain no data don’t
necessarily have to be backed up as long as you’re confident that you can
recreate them if needed. This is why it’s a good practice to keep notes on
which packages you installed in which templates and which customizations and
configurations you made. Then you can refer to your notes the next time you
need to recreate those qubes. Of course, backing up everything is not a bad
idea either. It may require a bit more time and disk space upfront, but for
some people, it can be just as important as backing up their irreplaceable
data. If your system is mission-critical, and you can’t afford more than a
certain amount of downtime, then by all means, back everything up!
Introspect on your own behavior. For example, if you find yourself
wanting to find some way to get two qubes to share the same storage space,
then this is probably a sign that those two qubes shouldn’t be separate in
the first place. Sharing storage with each other largely breaks down the
secure wall between them, making the separation somewhat pointless. But you
probably had a good reason for wanting to make them two separate qubes
instead of one to begin with. What exactly was that reason? If it has to do
with security, then why are you okay with them freely sharing data that could
allow one to infect the other? If you’re sure sharing the data wouldn’t cause
one to infect the other, then what’s the security rationale for keeping them
separate? By critically examining your own thought process in this way, you
can uncover inconsistencies and contradictions that allow you to better
refine your system, resulting in a more logical organization that serves your
needs better and better over time.
Don’t assume that just because you can’t find a way to attack your
system, an adversary wouldn’t be able to. When you’re thinking about
whether it’s a good idea to combine different activities or data in a single
qube, for example, you might think, “Well, I can’t really see how these pose
a risk to each other.” The problem is that we often miss attack vectors that
sophisticated adversaries spot and can use against us. After all, most people
don’t think that using a conventional monolithic operating system is risky,
when in reality their entire digital life can be taken down in one fell
swoop. That’s why a good rule of thumb is: When in doubt, compartmentalize.
But remember that compartmentalization — like everything else — can be
taken to an extreme. The appropriate amount depends on your temperament,
time, patience, experience, risk tolerance, and expertise. In short, there
can be such a thing as too much compartmentalization! You also have to be
able to actually use your computer efficiently to do the things you need to
do. For example, if you immediately try to jump into doing everything in
disposables (https://www.qubes-os.org/doc/how-to-use-disposables/) and find yourself constantly
losing working (e.g., because you forget to transfer it out before the
disposable self-destructs), then that’s a big problem! Your extra
self-imposed security measures are interfering with the very thing they’re
designed to protect. At times like these, take a deep breath and remember
that you’ve already reaped the vast majority of the security benefit simply
by using Qubes OS in the first place and performing basic
compartmentalization (e.g., no random web browsing in templates). Each
further step of hardening and compartmentalization beyond that represents an
incremental gain with diminishing marginal utility. Try not to allow the
perfect to be the enemy of the good!
Introspect on your own behavior. For example, if you find yourself
wanting to find some way to get two qubes to share the same storage space,
then this is probably a sign that those two qubes shouldn’t be separate in
the first place. Sharing storage with each other largely breaks down the
secure wall between them, making the separation somewhat pointless. But you
probably had a good reason for wanting to make them two separate qubes
instead of one to begin with. What exactly was that reason? If it has to do
with security, then why are you okay with them freely sharing data that could
allow one to infect the other? If you’re sure sharing the data wouldn’t cause
one to infect the other, then what’s the security rationale for keeping them
separate? By critically examining your own thought process in this way, you
can uncover inconsistencies and contradictions that allow you to better
refine your system, resulting in a more logical organization that serves your
needs better and better over time.
Don’t assume that just because you can’t find a way to attack your
system, an adversary wouldn’t be able to. When you’re thinking about
whether it’s a good idea to combine different activities or data in a single
qube, for example, you might think, “Well, I can’t really see how these pose
a risk to each other.” The problem is that we often miss attack vectors that
sophisticated adversaries spot and can use against us. After all, most people
don’t think that using a conventional monolithic operating system is risky,
when in reality their entire digital life can be taken down in one fell
swoop. That’s why a good rule of thumb is: When in doubt, compartmentalize.
But remember that compartmentalization — like everything else — can be
taken to an extreme. The appropriate amount depends on your temperament,
time, patience, experience, risk tolerance, and expertise. In short, there
can be such a thing as too much compartmentalization! You also have to be
able to actually use your computer efficiently to do the things you need to
do. For example, if you immediately try to jump into doing everything in
disposables (https://www.qubes-os.org/doc/how-to-use-disposables/) and find yourself constantly
losing working (e.g., because you forget to transfer it out before the
disposable self-destructs), then that’s a big problem! Your extra
self-imposed security measures are interfering with the very thing they’re
designed to protect. At times like these, take a deep breath and remember
that you’ve already reaped the vast majority of the security benefit simply
by using Qubes OS in the first place and performing basic
compartmentalization (e.g., no random web browsing in templates). Each
further step of hardening and compartmentalization beyond that represents an
incremental gain with diminishing marginal utility. Try not to allow the
perfect to be the enemy of the good!
🔥3
XSAs released on 2022-11-01
https://www.qubes-os.org/news/2022/11/01/xsas-released-on-2022-11-01/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
XSA-414
Please see QSB-085 (https://www.qubes-os.org/news/2022/11/01/qsb-085/) for further details.
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-326 (denial-of-service only)
XSA-412 (affects only version 4.16)
XSA-415 (denial-of-service only)
XSA-416 (denial-of-service only)
XSA-417 (domid is never reused)
XSA-418 (denial-of-service only)
XSA-419 (denial-of-service only)
XSA-420 (oxenstored is not used in Qubes OS)
XSA-421 (denial-of-service only)
Related links
Xen XSA list (https://xenbits.xen.org/xsa/)
Qubes XSA tracker (https://www.qubes-os.org/security/xsa/)
Qubes security pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes security bulletins (QSBs) (https://www.qubes-os.org/security/qsb/)
https://www.qubes-os.org/news/2022/11/01/xsas-released-on-2022-11-01/
The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
XSA-414
Please see QSB-085 (https://www.qubes-os.org/news/2022/11/01/qsb-085/) for further details.
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-326 (denial-of-service only)
XSA-412 (affects only version 4.16)
XSA-415 (denial-of-service only)
XSA-416 (denial-of-service only)
XSA-417 (domid is never reused)
XSA-418 (denial-of-service only)
XSA-419 (denial-of-service only)
XSA-420 (oxenstored is not used in Qubes OS)
XSA-421 (denial-of-service only)
Related links
Xen XSA list (https://xenbits.xen.org/xsa/)
Qubes XSA tracker (https://www.qubes-os.org/security/xsa/)
Qubes security pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes security bulletins (QSBs) (https://www.qubes-os.org/security/qsb/)
QSB-085: Xenstore: Guests can crash xenstored (XSA-414)
https://www.qubes-os.org/news/2022/11/01/qsb-085/
We have just published Qubes Security Bulletin (QSB) 085: Xenstore: Guests can crash xenstored (XSA-414) (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-085-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 085 ]===---
2022-11-01
Xenstore: Guests can crash xenstored (XSA-414)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-12
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
--------
On 2022-11-01, the Xen Project published XSA-414, "Xenstore: Guests
can crash xenstored" [3]:
| Due to a bug in the fix of XSA-115 a malicious guest can cause
| xenstored to use a wrong pointer during node creation in an error
| path, resulting in a crash of xenstored or a memory corruption in
| xenstored causing further damage.
|
| Entering the error path can be controlled by the guest e.g. by
| exceeding the quota value of maximum nodes per domain.
Impact
-------
The Xen Project's impact denoscription also applies to Qubes OS:
| A malicious guest can cause xenstored to crash, resulting in the
| inability to create new guests or to change the configuration of
| running guests.
|
| Memory corruption in xenstored or privilege escalation of a guest
| can't be ruled out.
(Note: In Qubes terminology, a Xen guest is referred to as a "qube.")
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-414.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2022/11/01/qsb-085/
We have just published Qubes Security Bulletin (QSB) 085: Xenstore: Guests can crash xenstored (XSA-414) (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-085-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 085 ]===---
2022-11-01
Xenstore: Guests can crash xenstored (XSA-414)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-12
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
--------
On 2022-11-01, the Xen Project published XSA-414, "Xenstore: Guests
can crash xenstored" [3]:
| Due to a bug in the fix of XSA-115 a malicious guest can cause
| xenstored to use a wrong pointer during node creation in an error
| path, resulting in a crash of xenstored or a memory corruption in
| xenstored causing further damage.
|
| Entering the error path can be controlled by the guest e.g. by
| exceeding the quota value of maximum nodes per domain.
Impact
-------
The Xen Project's impact denoscription also applies to Qubes OS:
| A malicious guest can cause xenstored to crash, resulting in the
| inability to create new guests or to change the configuration of
| running guests.
|
| Memory corruption in xenstored or privilege escalation of a guest
| can't be ruled out.
(Note: In Qubes terminology, a Xen guest is referred to as a "qube.")
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-414.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Charles Hoskinson - Cardano founder $ADA (ex co-founder of $ETH & $ETC) mentions QubesOS! 💪
https://m.youtube.com/watch?v=oH5AZ5f43Qo
https://m.youtube.com/watch?v=oH5AZ5f43Qo
YouTube
Musings on Cryptocurrency Infrastructure
🔥2
The QubesOS chat will be unlinked from this channel within a few mins. That means you won't be able to make comments anymore until Telegram adds the feature to link to topic groups. The group is getting converted into a topics group meaning there will be multiple chats in the group (check out @TheForum)
If you haven't yet joined the group, I recommend doing so now. You'll be able to participate in many different topics about QubesOS that peeks your interest. This is a community where everyone helps everyone. New topic ideas are always welcomed.
Here's the group link. Conversation will happen soon!
https://news.1rj.ru/str/+QROgxw4yJttXvDNF
If you haven't yet joined the group, I recommend doing so now. You'll be able to participate in many different topics about QubesOS that peeks your interest. This is a community where everyone helps everyone. New topic ideas are always welcomed.
Here's the group link. Conversation will happen soon!
https://news.1rj.ru/str/+QROgxw4yJttXvDNF
Telegram
QubesOS Chat
(Community Support)
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
Alternative community instead of online forum and discord.
@QubesOS
>No spam/ads/NSFW/shit posts/spam bots
>Respect others
>Stay on topic
>Be transparent
If you need help ask!
Rules are enforced with ban or restrictions.
❤1
Qubes OS
The QubesOS chat will be unlinked from this channel within a few mins. That means you won't be able to make comments anymore until Telegram adds the feature to link to topic groups. The group is getting converted into a topics group meaning there will be multiple…
If you are unable to chat, you will have to update Telegram. Old Telegram clients can only reply to messages, they can not send messages without replying.
I decided to make the QubesOS chat public (@QubesChat) so people can easily join. If you haven't yet, feel free to join and participate in discussions or start a discussion!
👍1
XSAs released on 2022-11-08
https://www.qubes-os.org/news/2022/11/08/xsas-released-on-2022-11-08/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
XSA-422
Please see QSB-086 (https://www.qubes-os.org/news/2022/11/08/qsb-086/) for further details.
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
https://www.qubes-os.org/news/2022/11/08/xsas-released-on-2022-11-08/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is affected.
Therefore, user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
XSA-422
Please see QSB-086 (https://www.qubes-os.org/news/2022/11/08/qsb-086/) for further details.
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
(none)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
QSB-086: Speculative security issues on AMD CPUs (XSA-422)
https://www.qubes-os.org/news/2022/11/08/qsb-086/
We have just published Qubes Security Bulletin (QSB) 086: Speculative security issues on AMD CPUs (XSA-422) (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 086 ]===---
2022-11-08
Speculative security issues on AMD CPUs (XSA-422)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-13
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
--------
On 2022-11-08, the Xen Project published XSA-422, "x86: Multiple
speculative security issues" [3]:
| Researchers have discovered that on some AMD CPUs, the
| implementation of IBPB (Indirect Branch Prediction Barrier) does not
| behave according to the specification.
|
| Specifically, IBPB fails to properly flush the RAS (Return Address
| Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
| the hardware prediction structures), allowing attacker controlled
| values to survive across a deliberate attempt to purge said values.
|
| AMD have allocated CVE-2022-23824.
XSA-422 also describes a second AMD vulnerability. However, since it
is believed not to affect Xen, and therefore not to affect Qubes OS,
it is omitted here.
Impact
-------
On Qubes OS installations with affected CPUs, a VM running in PV mode
may be capable of inferring the memory contents of other running VMs,
including dom0. In the default Qubes OS configuration, only the
stubdomains for HVMs are in a position to exploit this vulnerability
in order to attack other VMs. (Dom0 also runs in PV mode, but it is
fully trusted.)
Only certain AMD CPUs are affected. Please see AMD-SB-1040 [4] for the
official list of affected models.
(Note: XSA-422 states that Xen versions prior to 4.16 are not affected
by this vulnerability. While Qubes OS uses a Xen version prior to
4.16, we have backported a Xen performance optimization [5] that
assumes that IBPB works as previously specified. Therefore, the
version of Xen used in Qubes is affected by this vulnerability even
though its version numbers is lower than 4.16.)
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-422.html
[4] https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040
[5] https://github.com/QubesOS/qubes-vmm-xen/blob/v4.14.5-12/patch-0001-x86-spec-ctrl-Skip-RSB-overwriting-when-safe-to-do-s.patch
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2022/11/08/qsb-086/
We have just published Qubes Security Bulletin (QSB) 086: Speculative security issues on AMD CPUs (XSA-422) (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-086-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 086 ]===---
2022-11-08
Speculative security issues on AMD CPUs (XSA-422)
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in dom0:
- Xen packages, version 4.14.5-13
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Dom0 must be restarted afterward in order for the updates to take
effect.
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.
Summary
--------
On 2022-11-08, the Xen Project published XSA-422, "x86: Multiple
speculative security issues" [3]:
| Researchers have discovered that on some AMD CPUs, the
| implementation of IBPB (Indirect Branch Prediction Barrier) does not
| behave according to the specification.
|
| Specifically, IBPB fails to properly flush the RAS (Return Address
| Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
| the hardware prediction structures), allowing attacker controlled
| values to survive across a deliberate attempt to purge said values.
|
| AMD have allocated CVE-2022-23824.
XSA-422 also describes a second AMD vulnerability. However, since it
is believed not to affect Xen, and therefore not to affect Qubes OS,
it is omitted here.
Impact
-------
On Qubes OS installations with affected CPUs, a VM running in PV mode
may be capable of inferring the memory contents of other running VMs,
including dom0. In the default Qubes OS configuration, only the
stubdomains for HVMs are in a position to exploit this vulnerability
in order to attack other VMs. (Dom0 also runs in PV mode, but it is
fully trusted.)
Only certain AMD CPUs are affected. Please see AMD-SB-1040 [4] for the
official list of affected models.
(Note: XSA-422 states that Xen versions prior to 4.16 are not affected
by this vulnerability. While Qubes OS uses a Xen version prior to
4.16, we have backported a Xen performance optimization [5] that
assumes that IBPB works as previously specified. Therefore, the
version of Xen used in Qubes is affected by this vulnerability even
though its version numbers is lower than 4.16.)
Credits
--------
See the original Xen Security Advisory.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://xenbits.xen.org/xsa/advisory-422.html
[4] https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040
[5] https://github.com/QubesOS/qubes-vmm-xen/blob/v4.14.5-12/patch-0001-x86-spec-ctrl-Skip-RSB-overwriting-when-safe-to-do-s.patch
--
The Qubes Security Team
https://www.qubes-os.org/security/
QSB-087: Qrexec: Injection of unsanitized data into log output
https://www.qubes-os.org/news/2022/11/23/qsb-087/
We have just published Qubes Security Bulletin (QSB) 087: Qrexec: Injection of unsanitized data into log output (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-087-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 087 ]===---
2022-11-23
Qrexec: Injection of unsanitized data into log output
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in templates, standalones and dom0:
- qrexec packages version 4.1.19
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Summary
--------
Due to a bug in qrexec [3], a malicious qube that is allowed to call a
qrexec service inside of another qube can inject unsanitized data into
the log output of a process that handles incoming qrexec calls in the
receiving qube. This log output may end up in
`/var/log/qubes/qrexec.*.log`, `~/.xsession-errors`, or systemd's
journal.
Impact
-------
An attacker could use this vulnerability in order to inject malicious
data, such as terminal control codes, into log output in the hope that
this data will be processed in a unsafe way, for example, by writing it
directly to a potentially-vulnerable terminal emulator.
In the default Qubes OS configuration, for example, there are qrexec
services like `qubes.WindowIconUpdater` that any qube can call in dom0.
An attacker who gains control of an untrusted qube could inject data
containing malicious terminal control sequences into
`/var/log/qubes/qrexec.*.log` in dom0. If the user views that log in a
terminal emulator in a way that doesn't filter terminal escape codes (by
simply using `cat` on the file, for example), the malicious data might
then exploit a hypothetical bug in the terminal emulator.
Note that this attack scenario, as described, has several layered
requirements:
1. The user must voluntarily open a log file containing malicious data
(or otherwise take action that causes the log file data to be
parsed).
2. There must exist an independent vulnerability in the user's terminal
emulator or in whichever program parses the log. (In other words, the
attacker must chain independent vulnerabilities together.)
3. If using a terminal emulator, a command-line tool that does not
filter control codes must be used. (`journalctl` prevents the display
of unsafe sequences by default, but many other tools do not.)
To be clear, the scenario in which the attacker uses the
`qubes.WindowIconUpdater` service in order to exploit a hypothetical bug
in a terminal emulator is just one conceivable scenario for how an
attacker might exploit the vulnerability described in this bulletin. It
is not the only way in which this vulnerability could be exploited, and
the requirements listed for this scenario may not necessarily apply to
other scenarios featuring different types of attacks (for example, using
other qrexec services and exploiting other software that handles log
output). Rather, this example is merely intended as an aid for
understanding the nature of the vulnerability.
Discussion
-----------
Qubes OS features a framework known as "qrexec," which allows different
qubes to communicate with each other in a controlled manner. [3][4]
https://www.qubes-os.org/news/2022/11/23/qsb-087/
We have just published Qubes Security Bulletin (QSB) 087: Qrexec: Injection of unsanitized data into log output (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-087-2022.txt). 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) (https://www.qubes-os.org/security/pack/). More information about QSBs, including a complete historical list, is available here (https://www.qubes-os.org/security/qsb/).
---===[ Qubes Security Bulletin 087 ]===---
2022-11-23
Qrexec: Injection of unsanitized data into log output
User action required
---------------------
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.1, in templates, standalones and dom0:
- qrexec packages version 4.1.19
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. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]
Summary
--------
Due to a bug in qrexec [3], a malicious qube that is allowed to call a
qrexec service inside of another qube can inject unsanitized data into
the log output of a process that handles incoming qrexec calls in the
receiving qube. This log output may end up in
`/var/log/qubes/qrexec.*.log`, `~/.xsession-errors`, or systemd's
journal.
Impact
-------
An attacker could use this vulnerability in order to inject malicious
data, such as terminal control codes, into log output in the hope that
this data will be processed in a unsafe way, for example, by writing it
directly to a potentially-vulnerable terminal emulator.
In the default Qubes OS configuration, for example, there are qrexec
services like `qubes.WindowIconUpdater` that any qube can call in dom0.
An attacker who gains control of an untrusted qube could inject data
containing malicious terminal control sequences into
`/var/log/qubes/qrexec.*.log` in dom0. If the user views that log in a
terminal emulator in a way that doesn't filter terminal escape codes (by
simply using `cat` on the file, for example), the malicious data might
then exploit a hypothetical bug in the terminal emulator.
Note that this attack scenario, as described, has several layered
requirements:
1. The user must voluntarily open a log file containing malicious data
(or otherwise take action that causes the log file data to be
parsed).
2. There must exist an independent vulnerability in the user's terminal
emulator or in whichever program parses the log. (In other words, the
attacker must chain independent vulnerabilities together.)
3. If using a terminal emulator, a command-line tool that does not
filter control codes must be used. (`journalctl` prevents the display
of unsafe sequences by default, but many other tools do not.)
To be clear, the scenario in which the attacker uses the
`qubes.WindowIconUpdater` service in order to exploit a hypothetical bug
in a terminal emulator is just one conceivable scenario for how an
attacker might exploit the vulnerability described in this bulletin. It
is not the only way in which this vulnerability could be exploited, and
the requirements listed for this scenario may not necessarily apply to
other scenarios featuring different types of attacks (for example, using
other qrexec services and exploiting other software that handles log
output). Rather, this example is merely intended as an aid for
understanding the nature of the vulnerability.
Discussion
-----------
Qubes OS features a framework known as "qrexec," which allows different
qubes to communicate with each other in a controlled manner. [3][4]
👍3
These interactions are restricted by the system's RPC policies. [5] In
particular, qrexec can be used to allow less trusted qubes to
communicate with more trusted qubes, including dom0.
Normally, the calling side can send data to the remote services'
standard input and receive its standard output, standard error, and exit
code data. Since it handles untrusted data flows, qrexec is designed
under the assumption that an adversary will use it in order to launch an
attack against one qube from another qube. Therefore, qrexec treats
incoming data as untrusted and carefully sanitizes it. For example, when
qrexec output is connected to a terminal, `qrexec-client` and
`qrexec-client-vm` remove terminal control sequences.
However, due to a mistake in qrexec message type handling, the calling
side can send data marked as "standard error" (`MSG_DATA_STDERR`), and
the remote side will print it to the standard error of the process
handling incoming qrexec connections. This data flow was not expected.
Such messages should be rejected, as they are expected only in the other
direction. Consequently, this data is not appropriately sanitized, and
potentially-malicious data may end up in log output.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/qrexec/
[4] https://www.qubes-os.org/doc/qrexec-internals/
[5] https://www.qubes-os.org/doc/rpc-policy/
--
The Qubes Security Team
https://www.qubes-os.org/security/
particular, qrexec can be used to allow less trusted qubes to
communicate with more trusted qubes, including dom0.
Normally, the calling side can send data to the remote services'
standard input and receive its standard output, standard error, and exit
code data. Since it handles untrusted data flows, qrexec is designed
under the assumption that an adversary will use it in order to launch an
attack against one qube from another qube. Therefore, qrexec treats
incoming data as untrusted and carefully sanitizes it. For example, when
qrexec output is connected to a terminal, `qrexec-client` and
`qrexec-client-vm` remove terminal control sequences.
However, due to a mistake in qrexec message type handling, the calling
side can send data marked as "standard error" (`MSG_DATA_STDERR`), and
the remote side will print it to the standard error of the process
handling incoming qrexec connections. This data flow was not expected.
Such messages should be rejected, as they are expected only in the other
direction. Consequently, this data is not appropriately sanitized, and
potentially-malicious data may end up in log output.
Credits
--------
This issue was discovered by Demi Marie Obenour.
References
-----------
[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/qrexec/
[4] https://www.qubes-os.org/doc/qrexec-internals/
[5] https://www.qubes-os.org/doc/rpc-policy/
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍5
Qubes Canary 033
https://www.qubes-os.org/news/2022/12/04/canary-033/
We have published Qubes Canary 033. 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 033 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-033-2022.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 033 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 04, 2022.
2. There have been 87 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
fourteen days of March 2023. 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 proof of freshness provided below 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
-------------------
Sun, 04 Dec 2022 03:11:56 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Friends or Frenemies?: Significant Trans-Atlantic Divides Emerge in Global Chip War
The Russian Mobilization: One Soldier's Effort to Avoid the War
Tragedy in Mariupol: The Boy Who Lost His Family But Not His Hope
A Year with Angela Merkel: "You're Done with Power Politics"
Fears of Chinese Aggression Grow in Taiwan: "Where Are We Supposed to Go?"
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
He Returned a Dazed Soldier to the Russians. Ukraine Calls It Treason.
Landslide Tragedy Turns Italy’s Focus to Illegal Construction
Why Is Rahul Gandhi Walking 2,000 Miles Across India?
How China’s Police Used Phones and Faces to Track Protesters
Ukraine Calls for Evacuations From a Russian-Controlled Area
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Cyril Ramaphosa: South Africa leader won't resign, says spokesman
Ukraine war: Zelensky calls West's Russian oil cap 'weak'
Ukraine war: New images show Russian army base built in occupied Mariupol
Elnaz Rekabi: Family home of Iranian climber demolished
Columbia peace talks with leftist ELN rebels make progress
Source: Blockchain.info
00000000000000000000955f2976b1fbff0d0c47c262ea3ae6410e43f8218fb7
Footnotes
----------
https://www.qubes-os.org/news/2022/12/04/canary-033/
We have published Qubes Canary 033. 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 033 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-033-2022.txt
Learn how to obtain and authenticate the qubes-secpack and all the
signatures it contains:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canary/
---===[ Qubes Canary 033 ]===---
Statements
-----------
The Qubes security team members who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is December 04, 2022.
2. There have been 87 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
fourteen days of March 2023. 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 proof of freshness provided below 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
-------------------
Sun, 04 Dec 2022 03:11:56 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Friends or Frenemies?: Significant Trans-Atlantic Divides Emerge in Global Chip War
The Russian Mobilization: One Soldier's Effort to Avoid the War
Tragedy in Mariupol: The Boy Who Lost His Family But Not His Hope
A Year with Angela Merkel: "You're Done with Power Politics"
Fears of Chinese Aggression Grow in Taiwan: "Where Are We Supposed to Go?"
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
He Returned a Dazed Soldier to the Russians. Ukraine Calls It Treason.
Landslide Tragedy Turns Italy’s Focus to Illegal Construction
Why Is Rahul Gandhi Walking 2,000 Miles Across India?
How China’s Police Used Phones and Faces to Track Protesters
Ukraine Calls for Evacuations From a Russian-Controlled Area
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Cyril Ramaphosa: South Africa leader won't resign, says spokesman
Ukraine war: Zelensky calls West's Russian oil cap 'weak'
Ukraine war: New images show Russian army base built in occupied Mariupol
Elnaz Rekabi: Family home of Iranian climber demolished
Columbia peace talks with leftist ELN rebels make progress
Source: Blockchain.info
00000000000000000000955f2976b1fbff0d0c47c262ea3ae6410e43f8218fb7
Footnotes
----------
👍1
[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! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
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! Instructions for doing so are documented here:
https://www.qubes-os.org/security/pack/
--
The Qubes Security Team
https://www.qubes-os.org/security/
👍1
XSAs released on 2022-12-06
https://www.qubes-os.org/news/2022/12/06/xsas-released-on-2022-12-06/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-423 (denial-of-service only)
XSA-424 (denial-of-service only)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.
https://www.qubes-os.org/news/2022/12/06/xsas-released-on-2022-12-06/
The Xen Project (https://xenproject.org/) has released one or more Xen security advisories (XSAs) (https://xenbits.xen.org/xsa/).
The security of Qubes OS is not affected.
Therefore, no user action is required.
XSAs that DO affect the security of Qubes OS
The following XSAs do affect the security of Qubes OS:
(none)
XSAs that DO NOT affect the security of Qubes OS
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-423 (denial-of-service only)
XSA-424 (denial-of-service only)
About this announcement
Qubes OS uses the Xen hypervisor (https://wiki.xenproject.org/wiki/Xen_Project_Software_Overview) as part of its architecture (https://www.qubes-os.org/doc/architecture/). When the Xen Project (https://xenproject.org/) publicly discloses a vulnerability in the Xen hypervisor, they issue a notice called a Xen security advisory (XSA) (https://xenproject.org/developers/security-policy/). Vulnerabilities in the Xen hypervisor sometimes have security implications for Qubes OS. When they do, we issue a notice called a Qubes security bulletin (QSB) (https://www.qubes-os.org/security/qsb/). (QSBs are also issued for non-Xen vulnerabilities.) However, QSBs can provide only positive confirmation that certain XSAs do affect the security of Qubes OS. QSBs cannot provide negative confirmation that other XSAs do not affect the security of Qubes OS. Therefore, we also maintain an XSA tracker (https://www.qubes-os.org/security/xsa/), which is a comprehensive list of all XSAs publicly disclosed to date, including whether each one affects the security of Qubes OS. When new XSAs are published, we add them to the XSA tracker and publish a notice like this one in order to inform Qubes users that a new batch of XSAs has been released and whether each one affects the security of Qubes OS.