On Saturday, October 15, 2016 at 9:16:52 PM UTC-4, QubesOS User wrote:
> 16.10.2016, 01:03, "raahe...@gmail.com" <raahe...@gmail.com>:
> > On Saturday, October 15, 2016 at 5:09:46 PM UTC-4, QubesOS User wrote:
> >> 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 . 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 ."
> >> 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
> > 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.
> 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.
> Kind regards and all the best
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.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.