Earlier quoted context omitted.
But, and this is the important part, is he wrong?
This community lives on not understanding that...form over function always...
Can I insult you and then complain that you focus too much on form?
Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
51–60 of 104 posts
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#52Earlier quoted context omitted.
But, and this is the important part, is he wrong?
Being right is not the most important part. If you're right but don't convince anyone, you've made no difference. Theo was right that virtualization is a comparatively shoddy security boundary. At the same time, it's flexible and capable in ways that now define the shape of modern IT. Could we have replicated that by other means? If yes, then it's on Theo and other knee-jerk critics that they never proposed a better…
LLM slop account. Admittedly this one was harder to spot.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#53Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#54Mini tangent: Could someone explain to me why Qubes is used for security, when (from what I understand) Jails on BSD is significantly more robust/safe/has a much smaller exposed area? Is it just "everyone's using linux already; here's a safer linux"?
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#55Earlier quoted context omitted.
It has? News to me. Go on any major thread on this page, you’ll witness similarly strong pushback visa-vi buying into corporate backed hype, akin to the overconfidence in virt security he pointed at back then.
Vi doesn't require a visa but the trip is one way only. (Vis-a-vis)
You know, given my French grades, I really should stop using such phrases…
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#56Wow, this is serious. Makes you think, that even though QubesOS attack surface is so tiny (well-designed to be secure) there are still vulnerabilities to be found. Worth noting that (as I understand) this vulnerability occurs only when doing copy-to-VM from Dom0: >Note that the VM variant of `qvm-copy-to-vm` is not affected, as its version of the error reporting function does not use `system()`: Since you should not…
You are right, copying to dom0 is not best practices and warned against since anno dazumal, but given the user groups I remember not always being technically minded (journalists, dissidents, etc.) and ensuring qubeses isolation holds even when users do things they are discouraged from has always been part of the philosophy. Don’t trust users, don’t trust userland, don’t trust software and all that yazz.
I believe this is a vulnerability that occurs when copying data from dom0, which is a more common task. Generally the Qubes model recommends copying data from more trusted VMs to less trusted VMs, and dom0 still runs some system-wide processes in many default configurations.
For example when you take a screenshot with xfce4-screenshooter, the file is saved to dom0, and you have to use qvm-copy-to-vm to move it to a (less trusted) qube to do something with it. That's the most frequent use case, at least for me.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#57Mini tangent: Could someone explain to me why Qubes is used for security, when (from what I understand) Jails on BSD is significantly more robust/safe/has a much smaller exposed area? Is it just "everyone's using linux already; here's a safer linux"?
Qubes can be viewed as a Xen distribution, rather than a Linux distribution [1]. You may find the Qubes FAQ a good starting point (I'm reading it now because of your question, so thanks).
[1] https://doc.qubes-os.org/en/latest/introduction/faq.html#is-...
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#58The worst part is that in 2020 they explicitly documented that the remote filename is attacker controlled,but still allowed it to reach system() This is C security 101: never pass untrusted input through a shell. This should have been caught in the review!
This should be made structurally impossible through type safety rather relying on code review.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#59Earlier quoted context omitted.
I feel that, in fairness, one should at least read Adam’s response, though ideally all subsequent mails: https://marc.info/?l=openbsd-misc&m=119320496730314&w=2 Theos is a very opinionated and not necessarily wrong position, but I feel also a bit too reductive given we are eternally having to deal with compromises of some form. Also, lest we forget, it has been two decades in the interim and oh so much has changed. I…
In all fairness also read this: https://taviso.decsystem.org/virtsec.pdf
Yeah, I'm with Theo on this one. Conventional OS security between Ring-0 and everything else is well understood; the problem has become too much code in Ring-0, a great fraction of which has its own interfaces across the security boundary, and the Unix security model just doesn't scale.
No capabilities, or even a sane and useful way of adding capabilities with everything in ring 0, and the flat integer namespacing of users and groups just doesn't work for what userspace needs to do today - hence namespaces, which have introduced their own problems, because (no surprise) trying to graft a tree structure onto a flat integer namespace after the fact is a mess.
Virtualization tried to sidestep all that, but to make it fast the cost has been more driver interfaces to host ring-0 - remember what the original was? - and screwing around a whole bunch with particularly arcane facets of the core ring-0 security boundary, e.g. page tables.
It is a mess.
Re: Arbitrary code execution in QubesOS via copy-to-VM error reporting backchannel
#60I do really like the following in the bulletin: > Important: At this point, you still don’t know whether the key you just imported is the genuine QMSK or a forgery. In order for this entire procedure to provide meaningful security benefits, you must authenticate the QMSK out-of-band. Do not skip this step! The standard method is to obtain the QMSK fingerprint from multiple independent sources in several different way…
I own a Qubes T-shirt which I bought in person at FOSDEM. The design on the T-shirt consists of many copies of the QMSK in hexadecimal. All of their merch is like this.