Re: [qubes-users] Re: Maybe a provocative question

2016-10-17 Thread johnyjukya
>> 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

-- 
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/31ab8b2a2629b9c5dfb22e8b0eaa4824.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Maybe a provocative question

2016-10-17 Thread Holger Levsen
On Mon, Oct 17, 2016 at 02:12:52PM -, johnyju...@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)

-- 
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/20161017143310.GA22301%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


Re: [qubes-users] Re: Maybe a provocative question

2016-10-17 Thread johnyjukya
>> 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  10239   80906  141593  67142645
4.6  96 30   124035 90299   459 193
4.7  10236   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

-- 
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/6fc41c35e0c90896e50fc5892626c230.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Maybe a provocative question

2016-10-16 Thread raahelps
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" :
> > On Saturday, October 15, 2016 at 9:16:52 PM UTC-4, QubesOS User wrote:
> >>  16.10.2016, 01:03, "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 
> >> 

Re: [qubes-users] Re: Maybe a provocative question

2016-10-15 Thread QubesOS User
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" :
> On Saturday, October 15, 2016 at 9:16:52 PM UTC-4, QubesOS User wrote:
>>  16.10.2016, 01:03, "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 
>> 

Re: [qubes-users] Re: Maybe a provocative question

2016-10-15 Thread QubesOS User


16.10.2016, 01:03, "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 

Re: [qubes-users] Re: Maybe a provocative question

2016-10-15 Thread raahelps
On Saturday, October 15, 2016 at 9:16:52 PM UTC-4, QubesOS User wrote:
> 16.10.2016, 01:03, "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 

[qubes-users] Re: Maybe a provocative question

2016-10-15 Thread raahelps
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 

[qubes-users] Re: Maybe a provocative question

2016-10-15 Thread raahelps
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