Maybe a provocative question

135 views
Skip to first unread message

QubesOS User

unread,
Oct 15, 2016, 5:09:46 PM10/15/16
to qubes...@googlegroups.com
Hello everyone,

I could imagine that this question has been discussed before already, and if this should be the case, then I'm very sorry for posting this (I'd be thankful for an according link if so though).


I think that I've gained quite much knowledge about possible attack surfaces provided on hardware and software level during the last 15 years, trying to keep up-to-date and often doing research on new approaches in this field. First of all, I'd like to stress that the 'objection' (which I don't mean as such) I may raise by this post does not have any intention of criticizing the great work and effort done by the QubesOS developers and the community (it's not meant as an unhelpful 'critique' at all). Much rather I have a huge respect for the commitment shown by everyone involved in the development of QubesOS.


Having compared various approaches in this field (e. g. OpenBSD, Linux using a hardened security kernel, GNU Hurd), I'd basically come to the conclusion that QubesOS is the most promising approach, especially if VT-d isolation is available.


However, the main points I'd like to address are:

1) XEN is developed by people working for a company based in the U.S. (I know the difference between open-source and proprietary software, but still they belong to the same team/company). If even developers of TrueCrypt received one of those 'blue letters' - What is the reason to assume that the XEN developers didn't receive one of those as well? Seen from the perspective of the NSA it looks totally odd and irrational to me if they would not to so, since they can do so, and it's their task to thwart any efforts which might hinder them from collecting data. I don't regard those people as being 'evil' or anything like that (nor do I regard this as being positive, which should go without saying), I just look at things in a rational way: If QubesOS is a great approach to ensure security, then one must be naive to assume that this won't automatically lead to classifiying this as a 'high priority target' - With all the consequences.

1.2) Since this looks so obvious to me: Why isn't it a top priority for QubesOS developers to make use of a supervisor (or develop an independent one, which would surely need endless efforts, but wouldn't it be worth it?), which is not subjected to the objections I tried to express?

2) QubesOS totally relies on 2.1) trusting XEN developers to completely understand the more than just complex x64 architecture being used today and 2.2) on trusting Intel's VT technology.
Regarding 2.2): Just assuming Intel would have received some kind of 'advice' (they may even find motivation without getting such - I certainly don't think that Intel is an 'NSA subcontractor', but they are simply a big and profit-orientated company, not an idealistic open-source community like the QubesOS developers etc.) - Then how realistic is it that an absolutely professionally designed and implemented backdoor etc. as the result of sheer endless human, technological and financial ressources gets discovered by people like the QubesOS community, no matter how enthusiastic, intelligent, cautious and sceptical those are?

Referring once again to 2.1) I'd like to point to and quote from a highly interesting Qubes Security Bulletin (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-018-2015.txt):
"2) We are not entirely convinced if the way Xen Security Team decided to address this vulnerability is really optimal, security wise. It seems like a more defensive approach would be to get rid of this
dangerous construct of reusing the same memory for both an internal pointer and VM-provided data. Apparently Xen developers believe that they can fully understand the code, with all its execution paths, for decoding x86 operands. This optimistic attitude seems surprising, given the very bug we're discussing today."
[One should read the whole bulletin to know the context, but I didn't want this to become too long.]

One might also like to take a look at this bulletin, which gives me, among other XEN-related informations and facts, the strong impression that seeking an alternative hyperadvisor should have higest priority for the QubesOS development (believe me, I'd more than like to contribute to doing so by myself, too, and if I shold be able to aquire the necessary skills, I'll definitely try to do so):
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
"A more radical reader might be of the opinion that we should completely replace Xen with some other hypervisor. Such an opinion is surely not unfounded, as we have previously expressed our disappointment in the Xen security process [5]. Sadly, not much has improved over the past several months. Moreover, even though Qubes is now based on a hypervisor-abstracting architecture ("Odyssey"), which should make switching to a different VMM a relatively easy task, the primary problem that remains is the lack of a good alternative hypervisor to which we could move [6]."


Hopefully my post won't get misunderstood or even discourage people (if so, I'd really regret having written this) - I'm just worried regarding those points, and I believe that nothing is more dangerous than thinking one would have ensured security and therefore feeling even more motivated to rely on this (imaginary) security with all the consequences (to express this using quite harsh words: In the worst case users of QubesOS might be enticed to step into a huge honeypot, and I'd be pretty sure that - if this should be true - won't become known for many years, allowing the NSA etc. to collect petabytes of data in the meantime).


Finally, I don't think (this might sound even more provocative to many people) that organisations like the NSA etc. are 'useless' or 'to be abolished by all means' - This is similar to a simple but fundamental problem like "Well, complete disarment would surely be a great thing, but we'll run into big trouble if other nations won't think so", and of course I don't feel sorry at all for any terrorist etc. who gets prevented from killing other people because of getting caught before he can do that (or for criminals being caught). But nonetheless everyone knows where mass surveilance can lead to, and I think governments should generally respect people's privacy unless they have good reasons to watch them (and this should not be determined by computer algorithms) - But that's not what I wanted to address here, and I think it also doesn't belong here at all.


I'd be very curious to hear other people's opinions regarding the issues I addressed above.


Kind regards and all the best to everyone

Andrew David Wong

unread,
Oct 15, 2016, 5:52:34 PM10/15/16
to QubesOS User, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
If I've understood you correctly, your main thesis is that the security of Qubes depends directly on several factors that are outside of our control, in particular on Xen and Intel not having been strong-armed by the US government. I think it's safe to say that the Qubes team fundamentally agrees with you. Joanna has written about this topic in several of her blog posts and papers, so please take a look if you haven't already:

http://blog.invisiblethings.org/

On Intel x86 specifically, make sure to read this:

http://blog.invisiblethings.org/2015/10/27/x86_harmful.html

Finally, note that the future isn't necessarily hopeless:

http://blog.invisiblethings.org/2015/12/23/state_harmful.html

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYAqUUAAoJENtN07w5UDAwGKgP/1kWUXvlgttMQDIpcob8avNx
x7JgCsXxkBD37NkvG9vPIEdSmGTLwQAeon/4/roWyXpz2h1rkws9+2saF6YdGsJW
F5G+M2RpbnSOvClbqAWt1EEvW5yiPdRrLiM/GW3AVyTnnc0CJcZXDWgyNkX2vruL
y0nPlWupfhI2ioXp8DaAv2Naj3Z2sXdiPgCSkhTRywM8+zg72lZXiKR7U35RfA44
U4mFHvaVVYH1B3CJJUSDBhNDcPfivijC4QWn3buyXfUWZiWeEe2gopn1oaA7Vr3N
2MEBwPm9iv7Vd+VJJZle7j8LJN7uQ0nn5G6NXWjQmU5P16RMyS7Gu3fyTCfxqPF6
gkA+IXaO/afCxmbmPjYfA3HgZzjq5Jm7QFI6QXnYO8ZiYSpsTyPSMuoA8WraCSSc
b0Ak71e2pJ3KM3t5RU7bnwMKwnA5fQDRobeDkbLQIHZAH/DCKIlJiUd6O6SXgiiF
5qi7kqlg+6VyKnvLvJKw9LFApKdcZenLt/NbUJ8EJfu6wn3o2O6TlQ+xdA2hwbZx
VD5phSa/kUi0M2ALSLLIHxWVzDCZ5WBwK9r7nS3eCfbGnCwuBHgwLAItuXdXRk+H
9VNugRjuxhmUC0HDQ57kZoj6tKdHv/KQztvRcfpn7REsTJQY/kWIVOqa8B/LGbQJ
eElHY+EK+vGKN9Bqm23+
=4sWU
-----END PGP SIGNATURE-----

raah...@gmail.com

unread,
Oct 15, 2016, 7:03:43 PM10/15/16
to qubes-users, qubeso...@yandex.com

you are going to have select someone to trust no matter what man. Imo, ITL team seems more trustworthy then most. They never trying to hustle anybody, are not very politically correct, may be boring for some but they just about the work they aint a marketing team lol. Another distro I loved is trisquel ran by a couple fsf guys I hope they stick around too. Are you going to stop the nsa? no man just don't use a computer then if its that serious... but you at least want to be able to stop random people and not install shady software. so gotta just decide who to go with.

raah...@gmail.com

unread,
Oct 15, 2016, 7:04:46 PM10/15/16
to qubes-users, qubeso...@yandex.com, raah...@gmail.com

while at the same time having the freedom to do what you want and install what you want.

raah...@gmail.com

unread,
Oct 15, 2016, 7:13:24 PM10/15/16
to qubes-users, qubeso...@yandex.com, raah...@gmail.com

but again i believe we just stopping randoms, not some high lvl actor who infatuated with you. but still safer then anyone not using qubes. Just learning about low lvl hardware protections I didn't knew existed was enough to make me wanna support the ITL team.

QubesOS User

unread,
Oct 15, 2016, 9:16:52 PM10/15/16
to raah...@gmail.com, qubes-users


16.10.2016, 01:03, "raah...@gmail.com" <raah...@gmail.com>:
But for that purpose you most definitely don't use QubesOS, and that's quite a point. You can achieve that with any Linux distro, you just need to configure it the right way, which is pretty easy.


By the way: I'd still doubt that you could stop the NSA from spying on you if they'd want to, but 1) developing an independet supervisor from the scratch, 2) finally moving away from x64 architecture (see the security bulletins) [or at least using open hardware] and 3) running QubesOS behind a router like Turris Omnia would make it quite difficult for the NSA to watch/attack you.


And you might have misunderstood me: I certainly trust ITL, in fact they're one of the very few people involved in IT security I trust - Joanna Rutkowska's warnings against XEN are the best prove for this.


I'd be curious how much effort and time would be needed to write a supervisor from the scratch.

raah...@gmail.com

unread,
Oct 15, 2016, 9:47:06 PM10/15/16
to qubes-users, raah...@gmail.com, qubeso...@yandex.com
yes but most linux distros would consume more resources meaning you won't get as many vms running for as much isolation. You won't get any isolation at the hardware level for pci devices. And qubes makes it much easier to recover from or mitigate damage from a compromise compared to a normal linux distro, when you think how easy it is to delete and recreate and appvm for example. So when you accept the fact that getting compromised somewhere is probably inevitable, especially for a paranoid person, Qubes is the perfect os.

And who is to say how sophisticated bots and low level actors are becoming, so much so that Qubes might be nescessary for everyone in the future. Nowadays low level actors and nsa have basically same abilities. NSA just has built in shortcuts in the infrastructure itself.

QubesOS User

unread,
Oct 15, 2016, 10:28:24 PM10/15/16
to raah...@gmail.com, qubes-users
You mentioned some good points about QubesOS. One thing I definitely dislike about QubesOS (and that's no offense of course - it's simply unavoidable, and of course that's not the developers' fault - in contrast I couldn't imagine how they could optimize it even more [maybe one could do so as a user by switching from Fedora to a distro template which needs very few ressources despite having to run multiple VMs]) is that it consumes a really huge amount of CPU and memory, even on modern hardware.

Well, another approach for isolation (not in the way by VMs employed on any Linux distro, it's a totally different approach) is GNU Hurd, but it's still experimental and only works on QEMU as far as I know (didn't follow it for quite a while). However, those guys are really enthusiastic as well and maybe that could be another promising approach someday.


Yes, if the NSA etc. really wouldn't be able to break into your QubesOS system, then they'll certainly have plenty of other means to gain access to your data (refer to the NSA-ANT catalogue, papers about key strokes and radio sginal interception etc.).

No, I don't agree to your last paragraph. Any well-configured Linux distro plus a good firewall (pfsense etc.) / router (like Turris Omnia) will prevent any (super professional) hacker from breaking into your system, if you set up everything in the best possible way AND choose the right (open-source) hardware.


Kind regards and all the best


16.10.2016, 03:47, "raah...@gmail.com" <raah...@gmail.com>:

raah...@gmail.com

unread,
Oct 16, 2016, 11:41:15 PM10/16/16
to qubes-users, raah...@gmail.com, qubeso...@yandex.com
well I use qubes on an old system as well. an amd phenom II x4 and 6 gb ddr3 ram. old 7200 rpm sata drive. I find what makes the biggest diff is the hdd if using ssd. But also I can't have as many vms running at the same time as the 16gb system and I don't get the hardware isolation, but its definitely usable for sure. I play videos on it and everything.

I heard of it but I don't know much about GNU hurd.

Sure plus 0 days.

Well again, you can't stop 0 days or programs designed with malicious intent. And of course I can limit myself to not being able to do what I want on a pc, not visiting websites anymore makes me inherently more secure, but then I wouldn't bother using a computer. This is the whole point of Qubes.

johny...@sigaint.org

unread,
Oct 17, 2016, 10:13:21 AM10/17/16
to qubes-users
>> 1) XEN is developed by people working for a company based in
>> the U.S.

Some fun stats for Xen 4.6 changesets, as used by Cubes:

Lines of Code: ~150,000

This is from

https://wiki.xenproject.org/wiki/Xen_Project_4.6_Acknowledgements

and related pages (and similar pages with 4.6 replaced by 4.x):

Lines of code added/removed:

Vers People Empl Added Rempved NSA-Add NSA-Rem
4.4 81 29 38048 25989 121
4.5 102 39 80906 141593 6714 2645
4.6 96 30 124035 90299 459 193
4.7 102 36 106606 37160 ? ?

Now, about 4.7. Note that the page for only lists individual names, does
not list any company affiliations or employers at all. An odd
change/omission?

So the NSA barely contributed for 4.4, contributed a significant amount
for 4.5, a bit for 4.6, and then either stopped contributing, or are doing
so in a non-transparent way through individuals for 4.7. :(

I can't say that's confidence-inspiring. Xen's change from 4.6 to 4.7 to
not listing employers almost has a slight "warrant canary" feel to it. :S
The source is open, I guess, but still, smart people can sneak in subtle
backdoor bugs. As we have seen.

Also, out of those 100 individuals, what are the odds that the NSA could
sneak in a few apparently unaffiliated "representatives" to submit some
subtle changes.

Now, I'm sure a good many of the people at NSA just want a stable,
reliable, professional operating system to use for their work, and
contribute back to Linux in turn to make it better.

It'd be refreshing and inspiring to see them fixing our critical tech
tools rather than hopelessly busting them. Go America.

But given their history of sneaking in back doors through subtle code
bugs, it does make one a bit, err, cautious.

Xen is a much bigger and faster-moving target than I ever expected for a
hypervisor.

After discovering I was being victimized by some keylogging and some other
covert surveillance hw/sw, I spend a fair bit of time about how to use a
computer with confidence, assuming that you can't necessarily trust the
hardware nor software.

Is it possible to have a secure environment, where you don't fully trust
the hardware/software? And unless you've designed the hardware and
software yourself (or they're both open and heavily and transparently
reviewed), and your never let either out of your sight and protection, how
can you ever fully trust hardware/software?

(For example, things such as a password safe on a memory key can help
partially thwart even a hardware keylogger, since online/etc. passwords
are never typed. Can this type of small success be achieved for a whole
system? It's daunting.)

Related:

http://invisiblethingslab.com/resources/bh08/part2-full.pdf

JJ

Holger Levsen

unread,
Oct 17, 2016, 10:33:16 AM10/17/16
to qubes-users
On Mon, Oct 17, 2016 at 02:12:52PM -0000, johny...@sigaint.org wrote:
> Lines of code added/removed:

interesting numbers, thanks for posting them here.

> Now, about 4.7. Note that the page for only lists individual names, does
> not list any company affiliations or employers at all. An odd
> change/omission?

could there be a simpler explaination?

> Xen is a much bigger and faster-moving target than I ever expected for a
> hypervisor.

indeed, same here.

> Is it possible to have a secure environment, where you don't fully trust
> the hardware/software?

no, especially assuming s#fully## ;-p

> And unless you've designed the hardware and
> software yourself (or they're both open and heavily and transparently
> reviewed), and your never let either out of your sight and protection, how
> can you ever fully trust hardware/software?

you can't.

and yeah, that's sad. luckily the real world is mostly not *that* black
and white.

long story short: I'd argue that *noone* should fully trust computers.
however, this doesn't make them completly useless ;-)


--
cheers,
Holger (SCNR)
signature.asc

johny...@sigaint.org

unread,
Oct 17, 2016, 10:54:26 AM10/17/16
to qubes-users
>> Now, about 4.7. Note that the page for only lists individual names,
>> does
>> not list any company affiliations or employers at all. An odd
>> change/omission?
>
> could there be a simpler explanation?

Certainly. Maybe some intern generating the stats page was too lazy to
summarize it by company. Maybe they stopped tracking company affiliation.
Maybe it's just an oversight.

Given the state of computer/network/software security these days and the
NSA's reputation, I thought it was worth pointing out. :)

>> Xen is a much bigger and faster-moving target than I ever expected for a
>> hypervisor.
>
> indeed, same here.

Wiki on Microkernels is consistent with my understanding:

> In terms of the source code size, as a general rule microkernels tend to
be smaller than monolithic kernels, usually sizing at under 10,000 lines
of code.

Xen's Wiki page states:

> Xen Project is a hypervisor using a microkernel design

It's a bit disingenuous to call Xen a Microkernel, at 150,000+ lines of code.

I hope to dig through the sources a bit tonight, and see how much of that
is truly the core kernel/security bits, and how much of that is qemu
drivers and stuff. Maybe there is a lean, well-reviewed core that we can
all trust, with a lot of supporting drivers and such. Although the fact
that those acknowledgement pages are careful to point out "Microkernel
core" vs. auxiliary stuff.

>> Is it possible to have a secure environment, where you don't fully trust
>> the hardware/software?
>
> no, especially assuming s#fully## ;-p

Not with existing hardware/software/operating systems, but can we get
there? Is there even a path forward? :)

Sadly, there doesn't seem to be any viable Xen alternatives. (I guess one
could always create alternatives from forks of Xen or the various other
hypervisors/kernels out there; although securing/improving/auditing Xen is
probably less work.)

>> And unless you've designed the hardware and
>> software yourself (or they're both open and heavily and transparently
>> reviewed), and your never let either out of your sight and protection,
>> how
>> can you ever fully trust hardware/software?
>
> you can't.
>
> and yeah, that's sad. luckily the real world is mostly not *that* black
> and white.

True, security isn't an on/off binary thing, it's more of a probability to
be combined with your risk profile. Qubes certainly increases your odds
at having some security by a fair bit.

Probably minor in comparison to all the holes, bugs, bad design choices,
and vulnerabilities in PC hardware (and software bugs/backdoors), but
every little bit helps.

> long story short: I'd argue that *noone* should fully trust computers.
> however, this doesn't make them completly useless ;-)

Very good point. I've overly-trusted computers, and have been hacked so
badly in the past few years that computers have basically become useless
to me. But I'm also a pretty low-valued target, lol, so I'm trying to
rebuild my confidence in my setup for work (and personal) sanity and
dignity.

It's awfully hard not to rely upon computers on a daily basis for work,
personal, communications, media purposes.

Stumbled across this, rather interesting:

https://en.wikipedia.org/wiki/Exokernel

JJ

Reply all
Reply to author
Forward
0 new messages