On Saturday, October 15, 2016 at 10:28:24 PM UTC-4, QubesOS User wrote:
> 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, "raahe...@gmail.com" <raahe...@gmail.com>:
> > 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 [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.
> >>
> >>  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.

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.

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to