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

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.

-- 
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/d852a837-8426-455f-b3fb-9ff5c306a019%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to