Contributing to hardening AppVMs templates

[Hugus Maximus]

Hi all,

I just published  document discussing some well known security limitations of Qubes OS:

https://www.pentest.es/Demystifying_QubesOS_Security.pdf

there are some suggestions at the end of the document. I'm aware you have your own roadmap so I would like to contribute in some design changes that may be helpful and aligned -not intrusive- with your current architecture. The first thing I would like to:

1) Switch from single user (web browser with root user capabilities) to multi user. The idea is to hard code a random password and allow sudo only via Dom0 confirmation

 

2) Adding Firejail to default templates.

3) Jailing by default the Firefox browser

Having Firejail installed by default on templates will allow to add new/more apps.

Also this can open the door to integrate Fireinvoke/Firewarden in the future so directly opening a a malicious file (like the .tar of my "Demystifying_QubesOS_Security.pdf" report) can not be a problem anymore in the future without requiring to open disposable VM's all the time (so, saving computing resources).

Would anyone kindly give me some hint about were I can start to achieve this?

Thanks,

Hugo

[Manuel Amador (Rudd-O)]

On December 16, 2021 8:25:19 AM GMT+01:00, Hugus Maximus <skydi...@gmail.com> wrote:
>
>Hi all,
>
>I just published document discussing some well known security limitations
>of Qubes OS:
>
>https://www.pentest.es/Demystifying_QubesOS_Security.pdf

I will review it.

That said, the security model of Qubes is single user in each VM because it is assumed that the kernel is not trustworthy. So some of your suggested measures, given the official postulates of the Qubes project, are pointless.

I personally think that higher security and performance can perhaps be achieved by using stuff like unikernels running stripped-down apps or services (single-process VMs which start in milliseconds). Genode is making headway in that direction without the need for unikernels or virtualization.

Question: why publish a PDF? It's not linkable, hard to quote... Why not a post on a blog?

[Hugo V.C.]

"is single user in each VM because it is assumed that the kernel is not trustworthy."

Can you elaborate it a bit? I don't get what you mean. Are you assuming that compromising a jailed an unprivileged web browser is the same as running it as root? 

"higher security and performance can perhaps be achieved by using stuff like unikernels running stripped-down apps or services"

100% agree. 

"why publish a PDF?  It's not linkable, hard to quote... Why not a post on a blog?"

Not linkable...? I don't have a blog. Maybe I should start one. Thanks for the suggestion.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Dec 15, 2021 at 11:25:19PM -0800, Hugus Maximus wrote:
>
> Hi all,
>
> I just published document discussing some well known security limitations
> of Qubes OS:
>
> https://www.pentest.es/Demystifying_QubesOS_Security.pdf
>
> there are some suggestions at the end of the document. I'm aware you have
> your own roadmap so I would like to contribute in some design changes that
> may be helpful and aligned -not intrusive- with your current architecture.
> The first thing I would like to:
>
> 1) Switch from single user (web browser with root user capabilities) to
> multi user. The idea is to hard code a random password and allow sudo only
> via Dom0 confirmation

You can configure VM to require dom0 confirmation for sudo access, see:
https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt

At the top of this page you can also find reasoning why it isn't this
way by default. There is also obligatory XKCD: https://xkcd.com/1200/

Generally, if someone gets arbitrary code execution inside a VM (outside
of any application-specific sandbox, if any), then already has access to
most of the stuff that VM has (user data, applications state etc). There
is very little point in guarding root access, as it doesn't give you
much more. This all is written in the above link already, so I'm not
going to repeat it here.

But ...

> 2) Adding Firejail to default templates.
>
> 3) Jailing by default the Firefox browser

... having individual applications in additional sandboxes, very much
makes sense. That's why we are working on un-breaking SELinux[1], enable
Apparmor in Debian[2], (slowly) migrating to Wayland[3] (as otherwise
X11 gives trivial bypass of a lot of sandboxes) and few more.

Firejail for Firefox makes sense too, although we try to stick with
distributions defaults as much as reasonably possible[4] - we let users
use Fedora/Debian/etc, not QFedora/QDebian/etc (see reasoning at [4]).
But there are exceptions, where we do apply some extra hardening -
for example most of the network/firewall configuration is custom.

> Having Firejail installed by default on templates will allow to add
> new/more apps.
>
> Also this can open the door to integrate Fireinvoke/Firewarden in the
> future so directly opening a a malicious file (like the .tar of my
> "Demystifying_QubesOS_Security.pdf" report) can not be a problem anymore in
> the future without requiring to open disposable VM's all the time (so,
> saving computing resources).

Generally, "the qubes way" is to use disposable qubes, but as you
(rightfully) noted, it does require resources and isn't always
convenient. While in-VM sandboxes are useful defense in depth, I'd
rather avoid them being the primary one. Opening a file coming from
untrusted world isolated "just" by Linux-based sandbox is not something
I'd like to rely on. One of the things we will focus on in short-medium
term is to make VMs (especially disposable ones) lighter - both lower
RAM usage, and make them quicker to start. This will make more
disaggregated setups (like, opening files in disposable qubes by
default) less painful to use.

As you noted in your article, Qubes provides a lot of tools that can
greatly improve user security, but they do rely on the user using them
correctly. This is a major obstacle for mass adoption (although probably
not the biggest one...). We have some ideas about that (like, providing
pre-made configurations for few common tasks, including stricter
policies), but this is a tricky trade-off between
convenience/flexibility and security.

One recent feature that you may find especially interesting, is
configuring selected applications to open _all_ files in disposable
qubes by default[5]. This a new, experimental thing in Qubes 4.1, and
sadly doesn't work with all the applications yet (especially those using
dbus-activation). Unfortunately GUI[6] for it didn't make it to R4.1,
and the non-GUI method is not documented yet[7]. But the core part is
there.

I'd like to answer to few points of your article directly too:

> The hypervisor domain must NOT be updated/manipulated by the end user (see
> below Dom0 design and update strategy)

Yes, that's very much on the roadmap. Moving GUI outside of dom0[8] is one
of the steps towards this goal. This way, we get rid of the one thing that
users like to customize - desktop environment. And removing this massive
pile of software from dom0 will make it _much_ smaller, which will make
updating as a whole more realistic scenario. Having exactly the same
dom0 fs content everywhere will also allow much stricter integrity
protection, and verification.

> EASY: just forget about doing those operations from the
> AppVM/VMs side, just transfer all the responsibility to Dom0. It looks to me very
> feasible to create a file system accessible by both Dom0 and the AppVM where
> AppVMs can transfer the files to be manipulated and then execute those actions
> from Dom0, not only the confirmation step.

No, that's backward. Filesystem-level sharing is rather complex thing,
with a huge attack surface, we definitely don't want to expose dom0 to
such attacks.
When you design your data flow, you (currently, unfortunately) need to
think how do you trust components involved. Making transfer
trusted->untrusted->trusted slightly(*) less risky is not very useful.
If you need such transfer (assuming here you trust the "original"
content of downloaded data), simply use appropriate VM to download the
file. If in doubt, use (fresh) disposable one. If you don't trust the
original content, there are still few things you can do:
- for pdf and images, we have tool to "clean" them up[9]
- for others, you can always open them in disposable qube, including
extracting the data you actually need there (in your very example -
open such tar in a disposable qube, and qvm-copy only the content you
need - and still treat it as untrusted)

(*) Your solution is only about ensuring the file that is sent is the
one that got written. But does not cover several other parts:
- is correct data actually written (substitute file at download stage,
instead of qvm-copy)
- is the tool used to preview the file actually showing you really the
right content (substitute file at preview stage)
and probably few more.

> Would anyone kindly give me some hint about were I can start to achieve
> this?

You can start by checking https://www.qubes-os.org/doc/contributing/.
Things like wrapping Firefox (and possibly others) with firejail sounds
like a good idea for the start. To keep things nicely organized, IMO it
should be a separate repository (and separate rpm/deb/... package). You
can use for example
https://github.com/QubesOS/qubes-app-linux-snapd-helper as a skeleton.

BTW, your appendix A is rather complex, there are much simpler ways.
Hint: qvm-run --localcmd. The lack of network in dom0 (and templates)
have two purposes:
1. Make it harder to get _into_ dom0.
2. Avoid _accidental_ untrusted data download (like, your favorite desktop
configuring tool trying to download you a wallpaper from
http://some.random.website/).
If you are in dom0 already, your options are rather limitless. Breaking
naive connect-back shells is rather poor consolation.

[1] https://github.com/QubesOS/qubes-issues/issues/4239
[2] https://github.com/QubesOS/qubes-issues/issues/4088
[3] https://github.com/orgs/QubesOS/projects/5
[4] https://www.qubes-os.org/faq/#what-is-qubes-attitude-toward-changing-guest-distros
[5] https://github.com/QubesOS/qubes-issues/issues/6877
[6] https://github.com/QubesOS/qubes-issues/issues/6366#issuecomment-767635670
[7] https://github.com/QubesOS/qubes-issues/issues/7130
[8] https://www.qubes-os.org/news/2020/03/18/gui-domain/
[9] http://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG8B84ACgkQ24/THMrX
1yxjiAf8Day2jC1Mq6i6WVsvUUPe2m3q0e/StY+5QJDSRk7k0RLx9XZYgd85S0NP
+eCq7WtRo0KCBidVm8rIl20f3cPzTdORNM2MwaSqcMqy3562NzEXbNJT3mj3lb4O
euf1ICMFY+AGnq0SvIkNAszFG0WljfjcxlQpVeHT112hct8hsFhwgFdngbvI/Ueq
pFsdHnDFTBbmvkA/x4AjmP+urE5E+z9ZM1KsAuUQx53q/9uXK+vW1IZeiIHGA9Cl
jqDsSDAN0YTNii4FldQFBGLlVSUTJcojbM4bW2TtOOLZUDKX21FdcVooB7sARZXz
zhzyjWjvUUSKahSiC8nXjo6/lXy0yg==
=uvJs
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 16/12/2021 23.54, Hugo V.C. wrote:

"is single user in each VM because it is assumed that the kernel is not trustworthy."

Can you elaborate it a bit? I don't get what you mean. Are you assuming that compromising a jailed an unprivileged web browser is the same as running it as root?

In the Qubes model, yes.  Also has proven true in every single PwnToOwn to date.

"higher security and performance can perhaps be achieved by using stuff like unikernels running stripped-down apps or services"

100% agree. 

"why publish a PDF?  It's not linkable, hard to quote... Why not a post on a blog?"

Not linkable...? I don't have a blog. Maybe I should start one. Thanks for the suggestion.

You have a Web site, don't you?

---------------------------

OK.  I went through the PDF.  The one attack you discovered is interesting, and the vuln you discovered should be fixed.

That said...

On page 25, you present the following suggestions (none of which address any of the flaws you discovered) under the section Hardening of AppVMs:

1. Making AppVMs multiuser.  On what grounds?  They are intended as single-purpose single-user environments; they could even be running all their processes as root (they don't, simply because of the practical reason that some GUI apps refuse).  Implementing this suggestion would not fix the problems you outlined earlier.  This suggestion is 100% a non-sequitur.
   
2. Sandbox the browser.  Could be helpful — anything exposed to the Internet should probably be sandboxed or containerized, just to make an attacker's attempt to compromise the compartment harder.  I wonder what level of effort pays off there.
3. Do not regard the AppVM and its tools at the same level of criticality.  Again, this is a non-sequitur — if you use Qubes, it is already postulated as true and well documented that you assume the AppVM shares its criticality level, no matter what user or tool you are running.  If you want to avoid compromise by using vulnerable tools, you are to run them in a disposable VM.
4. "EASY: just forget about doing those operations from the AppVM/VMs side, just transfer all the responsibility to Dom0" — lol what.  In Qubes OS, dom0 is explicitly forbidden (unless the user deliberately breaks the model) from seeing or manipulating any data from AppVMs.  dom0 is the minimum trusted computing base — if any malicious data infiltrates dom0, it's game over and you might as well be running MS-DOS instead.
   

Honestly, I think you have fundamentally misunderstood the design of Qubes OS, or you are still stuck in the old mental model of the UNIX security model, and your critiques stem from this misunderstanding / fixation.  If you want to critique a system of ideas that starts with postulate X, and your critique's argument starts with "I postulate not-X", then your argument is not at all critiquing that system.

I'm saying all of the above as someone experienced with Qubes OS, who has written several third-party utilities specifically for the Qubes OS environment — I even wrote a utility to share entire file systems conveniently between VMs, so I did basically what you suggested in point (4).  At no point in the development of this utility did it even occur to me "You know what would be a swell idea?  To pass these shared files through dom0."  That seems to me like an extreme error of judgment.

On page 26, you present the section Hardening of the whole solution:

1. Qubes OS places all its eggs in one basket — the Xen hypervisor.  This is partially true, from the perspective that the Xen hypervisor is one of the few trusted components of the system (arguably, the entirety of dom0 is).  The rest of the opinion is flat out against the facts.  The Qubes OS developers have put enormous amounts of effort in integration work to make the whole ensemble work well.  This effort shows — all you managed to chain in order to compromise another VM were components that the Qubes OS developers did not develop, and even then, your sole compromise scenario only works under highly specific and unlikely circumstances.  There have been very few vulnerabilities published against this integration work.
2. Qubes OS lets the user decide what trustworthiness level to place on data / data flows.  This is correct.  You call this "crazy".  How exactly would you do this otherwise?  No suggestions there.

The section File transfer solution suggests that file integrity must be checked.  You propose no mechanism to do this.  What you propose is to download files to a "secure and inalterable compartment" — and then what?  Leave the data there?  How does the user use the data then?  You also propose involving dom0 in said downloaded data flow — which would basically guarantee compromise of dom0, id est, MS-DOS security.  It's like your mental image of what the Qubes OS security model is, is the exact opposite of how the Qubes OS security model is implemented.  dom0 never touches untrusted data.

The section Hypervisor and subsequent section dom0 design and update strategy suggest:

1. Switch to seL4 and "forget about security".  Not a bad suggestion — perhaps seL4 is more secure (patches welcome).  But "formally verified" means nothing in the context of code executing in formally not verified hardware.  In fact, many Xen vulnerabilities stem from interplay between Xen code and microprocessors, and most major general security vulnerabilities are 100% entirely hardware-based (Spectre and Meltdown come to mind).  That opens up the sentence "forget about security" to the worst possible interpretation.
2. Don't let the user tamper with dom0.  Reasonable, but implementation details lack.  If I had a magic wand, dom0 would update using a system of A/B partitions stored on dm-verity volumes.  Unfortunately, implementing this without any mechanism for extensibility has the disadvantage that the user can then not extend dom0 with additional functionality — as a writer of such additional functionality, I would resent that.  This suggestion is also nonsequitorial from the perspective of the hypothetical attacks you discussed.  Finally, it is worth mentioning that dom0 executes most of its update routine in a separate VM, and packages are signed once that part of the routine is done.
3. Use a separate VM for updates.  This makes sense — if a downloaded package is compromised in a way that vulnerates dnf or RPM, that would leave the current default sys-firewall VM in a compromised state.
   

Not to say that I don't sympathize with these suggestions.  If I had the time, I would probably reimplement Qubes OS atop Genode with the L4 kernel or some other separation kernel.

Finally, on page 30, you present a "qubes trojan"... that requires execution in dom0.  That's not a trojan, that's a self-own.  If your "trojan" needs to run from the very compartment that the "trojan" is supposed to first break into, then I am not entirely sure what to make of your "trojan".

My rough conclusion is that the vast majority of the paper has little merit / is critiquing something not well understood by the author.

I hope to see the next edition of the paper soon.

[Hugo V.C.]

You can configure VM to require dom0 confirmation for sudo access, see:
https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt

Thank you Marek, I was not aware of that. I will activate it right now every where, of course.

 

At the top of this page you can also find reasoning why it isn't this
way by default.

I have read it and deeply disagree with some of the statements. I'll rebate all of them here:

"if somebody could find and exploit a bug in the Xen hypervisor -- as of 2016, there have been only three publicly disclosed exploitable bugs in the Xen hypervisor from a VM -- then it would be highly unlikely if that person couldn't also found a user-to-root escalation in VM (which as we know from history of UNIX/Linux happens all the time)."

Your statement "only three bugs since 2016" sounds a bit like marketing... (please don't get offended).  The reality is there have been 203 vulnerabilities in Xen since 2016 (https://www.cvedetails.com/vulnerability-list.php?vendor_id=6276). I bet that chaining some of them cat get more than three working exploits to escape Xen VM. The fact criticality is low in a vulnerability it doesn't mean too much nowadays. CVSS scoring is a joke. I have been reporting vulnerabilities since 90s and most of the time vendors rarely correctly understand the underlying problem. Here a funny example of a remote vulnerability that gave me Level 15 access on most routers of the Globe that was first scored as "Low" (2.6):

https://www.cvedetails.com/vulnerability-list.php?vendor_id=6276

but after the vendor (Cisco) changed the scoring to "High"... (Breaking
naive connect-back shells is rather poor consolation.)

Wow, what a jump. Why? I guess that the first guy reviewing it didn't realized that the attack, even if requiring user interaction (otherwise would have been directly scored 10) could be remotely exploited reliably and... anonymously (UDP ip spoofing is trivial) and massively. That is, an attacker could infect millions of routers all around the Globe anonymously and just wait. As the exploit was not version dependant (not low level payload OS dependant) then reliability was 100% in ALL versions of Cisco. So, at some point, someone probably said: "uuups.... this is bigger issue than we said". So, I guess that with 203 (just the public ones) Xen vulnerabilities, if you still think you have only three exploitable scenarios I will simply (respectfully) LoL (again, don't get offended). 

There is also obligatory XKCD: https://xkcd.com/1200/

Yes, very funny :) I agree 100%. Anyway, I'm not a supporter of this kind of mindset. I firmly believe in data (but also privileves) separation. Moreover, I see some parallelism between XKCD and what lloks to be a mantra like "we do not believe in ring 3 user rights separation as everybody can escalate to root easily". Not sure where it comes from, but I'll discuss later.

 

Generally, if someone gets arbitrary code execution inside a VM (outside
of any application-specific sandbox, if any), then already has access to
most of the stuff that VM has (user data, applications state etc). There
is very little point in guarding root access, as it doesn't give you
much more.

 

Sorry, but I do not agree here. I think this is a very simplistic way of describing the threats we are exposed as you are assuming VM's only goal is to use an app to access data (personal/work/whatever). For reasons that may be beyond your/my understanding, some organizations/people may want to have data in the VM that is not directly accessible to the browser. If you want to have such a very simple monolithic design of VM's where compromise-browser-compromise-ALLtheVM  just works, then I would move from a full OS that consumes a minimum of 400MB of RAM to something else (maybe your suggestion of unikernels may fit here), and then, you can run the browser in Ring0 if you want :) .Anyway, this approach does not look convenient to me, let me explain below.

Let's be serious, we are talking about millions of lines of not formally verified code when it comes to general purpose OS. All this is just a crazy. There are two basic ways in secure computing: either you build a formally verified solution and just forget (99.99% time is too expensive) or you use unverified code (general purpose OS). In this second case then you need to put as much security layers as you can. Of course there will be bugs there, but, believe me, it's more than 20 years exploiting stuff, and it is not the same to just exploit a 0day and break just one barrier than having to bypass several barriers that usually mean chaining many different exploits. That's why the most valued 0days in the black market are just chained exploits. And this is really effective as it reduces the amount of people able to achieve this task, which at the end, is the real goal as a defender as you will never have 100% security. You physically put a computer on the Moon and there are few organizations in the World that can hack it. It is not the same that putting in in surface of the Earth. The difficulty to reach the Moon is a security layer. Thus, LAYERS, of security work the same way. For educative purposes, you can read:

https://www.pentest.es/checkpoint_hack.pdf

it took me six months to bypass several security industry well known and reputed protections (see page 210). It was painful and will not do it again unless I get payed. But if I just need to exploit a simple bug and get root... then maybe it is worth dedicating a weekend and some pop corns... Did you see the .tar exploit to get root in any Qubes OS VM? I'm talking about this. It was too easy. If you really don't care about letting root access on the VMs why don't you directly set up an ssh root shell listenting on the VMs? Because you don't want anyone to mess with VM OS. That's a fact.

Also, the statement "There is very little point in guarding root access, as it doesn't give you much more".

is out of my understanding. So..., you can play with low level stuff in the VM with a standard non privileged user in Ring 3? I know DAC is far from perfect, but still it adds a layer and makes things muuuuch easier to manage in security. In a decent Linux system, a standard user (no need to use SELinux, secomp, etc) can't do some things. If you can, please report it to kernel.org or to the affected app or just patch your solution. Of course SELinux, secomp and more advanced protection systems like Grsecurity patches, make security serious, but still removing roo/user separation is a big mistake. 

... having individual applications in additional sandboxes, very much
makes sense. That's why we are working on un-breaking SELinux[1], enable
Apparmor in Debian[2], (slowly) migrating to Wayland[3] (as otherwise
X11 gives trivial bypass of a lot of sandboxes) and few more.

"X11 gives trivial bypass of a lot of sandboxes"

I agree. But it depends on your definition of sandboxes. It is not the same a chroot (useless) than secomp, SELinux, etc.

To me a sandbox is something from where there's no known way to escape from and when this happens it is called 0day.

 

Firejail for Firefox makes sense too, although we try to stick with
distributions defaults as much as reasonably possible[4] - we let users
use Fedora/Debian/etc, not QFedora/QDebian/etc (see reasoning at [4]).
But there are exceptions, where we do apply some extra hardening -
for example most of the network/firewall configuration is custom.

It was just an example. It can be whatever of your choice as long does the work.

 

Generally, "the qubes way" is to use disposable qubes, but as you
(rightfully) noted, it does require resources and isn't always
convenient. While in-VM sandboxes are useful defense in depth, I'd
rather avoid them being the primary one. Opening a file coming from
untrusted world isolated "just" by Linux-based sandbox is not something
I'd like to rely on.

Agree 100%.Is not to rely on. But my way of protecting assets is: 1) either I allow something (opening an attachment in a VM) 2) either I do not allow something (opening an attachment automatically in disposable VMs). But if you let users to choose, they will open in VMs many times due to a variety of reasons. So, if that is the case, why not sandboxing it by default? Not even mention to end users as we don't want them to rely on this, still tell them to open in disposable VMs, but whenever a reckless user does it... then at least we have an additional layer of security, which is always better than having nothing.

 

One of the things we will focus on in short-medium
term is to make VMs (especially disposable ones) lighter - both lower
RAM usage, and make them quicker to start. This will make more
disaggregated setups (like, opening files in disposable qubes by
default) less painful to use.

Sounds wonderful.

 

One recent feature that you may find especially interesting, is
configuring selected applications to open _all_ files in disposable
qubes by default[5]. This a new, experimental thing in Qubes 4.1, and
sadly doesn't work with all the applications yet (especially those using
dbus-activation). Unfortunately GUI[6] for it didn't make it to R4.1,
and the non-GUI method is not documented yet[7]. But the core part is
there.

Thank you Marek. I'm not concerned about me, I'm concerned about... in example, my daughters that still do not have the know how to decide when to open in a disposable machine or when it is "safe" to open it directly in the VM. Same could apply to average end user in a company (they still click on weird email links...).

 

I'd like to answer to few points of your article directly too:

> The hypervisor domain must NOT be updated/manipulated by the end user (see
> below Dom0 design and update strategy)

Yes, that's very much on the roadmap. Moving GUI outside of dom0[8] is one
of the steps towards this goal. This way, we get rid of the one thing that
users like to customize - desktop environment. And removing this massive
pile of software from dom0 will make it _much_ smaller, which will make
updating as a whole more realistic scenario. Having exactly the same
dom0 fs content everywhere will also allow much stricter integrity
protection, and verification.

Sounds good.

 

No, that's backward. Filesystem-level sharing is rather complex thing,
with a huge attack surface, we definitely don't want to expose dom0 to
such attacks.
When you design your data flow, you (currently, unfortunately) need to
think how do you trust components involved. Making transfer
trusted->untrusted->trusted slightly(*) less risky is not very useful.
If you need such transfer (assuming here you trust the "original"
content of downloaded data), simply use appropriate VM to download the
file. If in doubt, use (fresh) disposable one. If you don't trust the
original content, there are still few things you can do:
 - for pdf and images, we have tool to "clean" them up[9]
 - for others, you can always open them in disposable qube, including
   extracting the data you actually need there (in your very example -
   open such tar in a disposable qube, and qvm-copy only the content you
   need - and still treat it as untrusted)

No. The problem is complex because you are using complex tools to solve it, in example, a standard OS file system. You did a big step ahead in security by using Xen shared memory (which is also an old "trick" used in microkernel solutions to extract information from guest VMs).

So, I agree you will not solve this by using your current tools. Add some reliable element to the solution, in example, seL4. Think about this scheme of file transfer:

                      

VM <----> seL4 VM <---> VM

                       |

                   Dom0

With this scheme you can use seL4 as a reliable file transfer gateway. You can use PCI bus of seL4 for such operations. Nobody is going to compromise seL4 so as long you take care of the security of the code that does this job  (the VM-to-seL4 and seL4-to-VM memory copy) then you can forget forever. Obviously, achieving this from a Linux kernel is a bad joke...

You can start by checking https://www.qubes-os.org/doc/contributing/.
Things like wrapping Firefox (and possibly others) with firejail sounds
like a good idea for the start. To keep things nicely organized, IMO it
should be a separate repository (and separate rpm/deb/... package). You
can use for example
https://github.com/QubesOS/qubes-app-linux-snapd-helper as a skeleton.

Thank you. I'll give it a try.

 

BTW, your appendix A is rather complex, there are much simpler ways.
Hint: qvm-run --localcmd.

Hehe... I was not aware of that. There are also more elegant ways to do this, in example, a kernel module (maybe now I write it just for fun) that hides all the userland evil action and makes direct system calls. I don't want to see "qvm-run" in the ps... Also this kernel module may be used as implant all VMs as they all use the same kernel...?

 

The lack of network in dom0 (and templates)
have two purposes:
1. Make it harder to get _into_ dom0.
2. Avoid _accidental_ untrusted data download (like, your favorite desktop
   configuring tool trying to download you a wallpaper from
   http://some.random.website/).
If you are in dom0 already, your options are rather limitless. Breaking
naive connect-back shells is rather poor consolation.

"Breaking naive connect-back shells is rather poor consolation."

This is true in your current solution where Dom0 is God. Try to do this in a seL4 where Dom0 is just a VM and segregate critical duties in seL4 native apps and we can come back to this discussion... :)

Last, but not least important, beware of the symlink attack I described in my informal paper to the QubesIncoming attack directory is one of those "irrelevant" downplayed bugs that when chained whith other bugs can allow a full compromise... Also, it is a proof that the do-whatever-you-want model inside a VM does not work in terms of security as you put QubesIncoming directory to avoid files land on arbitrary places of the VM, BUT, then a simple error (lack of check the directory was a symlink) may break your solution (QubesIncoming landing dir). If you use a safe download repository this things do not happen. If you use a sandboxed browser this do not happens too. There are many possibilities here...

Having said all that, guys I still say I love Qubes OS. It is already one of my desktop environments. Now it's time to harden it.

[Hugo V.C.]

Manuel, please, read my answer to Marek, it will solve many of your questions, included the Dom0 holy grail of dealing with file sharing without touching it: just use seL4 gateway. BTW, downplaying seL4 formal verification looks very brave to me. Yes, hardware verification is the ultimate goal but out of your scope (are you going to sell hardware guys???) so having verified software is better than non verified. I hope we agree on that.

And not, I'm not Unix lover. I'm Ring0 enforced security lover, aka LSPP, partitioned kernels, kernel based RBAC, etc. Anyway, browser running as standard user is still better than running it as root ALWAYS. If you don't agree on that then we are on different sides of the security river: as experienced exploit writer I believe in multi layer security. I wonder how many exploits for your own 0days did you wrote in your entire life, and then, chained them together... It's difficult to me to think you are experienced in chaining 0days and still do not believe in multi layer security.

If you don't care about AppVMs levels of criticality I challenge you to run everything as root (with no sandboxing). Please, do it in the next Qubes OS then we will see what happens :-)

For the rest of the doubts you have, I think you didn't understood my suggestions. Every time there's something you misunderstand or is against what you believe then you get a bit aggressive and this is not productive for the goal of the project.

Anyway, I still wiling to help.  If you want.