On Saturday, October 15, 2016 at 7:03:43 PM UTC-4, raah...@gmail.com wrote:
> 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 [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
> 
> 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.

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

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7f8aeb02-5376-45d8-8762-ac1b7218a5da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to