Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-10 Thread raahelps 
On Sunday, July 10, 2016 at 2:26:59 AM UTC-4, raah...@gmail.com wrote:
> > A lot of people have two GPUs and don't realize it. Even so, its not 
> > like we are talking about great expense here: Even having access to 
> > weaker GPUs could make a big difference in Qubes' power and usability.
> > 
> > Projecting our own personal routines on the issue will probably not be 
> > of much help. And I think I've already made the case against framing 
> > this as a games issue; I'd urge the community not to look down its nose 
> > on graphics in this way or we will find the world of graphics can stare 
> > back at us more sharply. If it gets to the point where OpenBSD is 
> > recommended over Qubes because the latter "can't do much" and "lack of 
> > GPU virtualization sounds pretty insecure" then I think we'll be in real 
> > trouble. :)
> > 
> 
> 
> You are right, happened to me once when I didn't realize I had onboard gpu on 
> my system when I could of used it until it was too late.
> 
> Well I dunno man,  I only would need gpu passthrough for gaming.  Maybe thats 
> my personal reasons,  but I'm sure that is the reason for most people.  Do I 
> really live in a bubble? I'm not so sure.  I guess the only other reason 
> would be now that you mentioned the 3d printing and VR.  Although I don't 
> think many people are doing that even though its always interesting news.   
> And imo, although I'm no expert,   exposing hardware more to do that, even if 
> isolated in some way,  feels like more of a security risk to me.
> 
> I remember the reading the forum arguments pax team had with joanna online, 
> and one was so what if the vm is isolated.  The one actual fact besides 
> spenders usual temper tantrum ranting, for claiming it was false sense of 
> security,   was when he talked about exploiting the gpu for persistent 
> compromise.  That was his only poc example he had.   And thats not even 
> considering the gpu passthrough and 3d rendering you are calling for.  
> 
> And I know i'm very paranoid,  but sometimes I think people ask questions on 
> the forums on how to do things that qubes was not designed to do,  or want 
> certain features added,  to make it easier for them to hack qubes users. 
> LMAO.  I know I will get flamed for saying that,  but its how I feel 
> sometimes.   Maybe because I'm a noob, but I feel like the more abilities and 
> features we give qubes the more attack surface we give it, which defeats the 
> purpose of even using it.  If people can't give up gaming to use qubes,  then 
> they don't care about serious security on the machine anyways, imo.But 
> like i said I don't know the technicals really of how isolation works in 
> qubes and I'm talking out of my ass, so maybe I'm wrong.

This conversation also reminds me of one of the devs that left the qubes-whonix 
team.  Because he said the project "is becoming less about privacy and 
security,  and more just about cool tech"   I think this is thread is an 
example of that.

-- 
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/6c9577c7-3800-4ede-9730-97bd4092e4a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-10 Thread raahelps 
> A lot of people have two GPUs and don't realize it. Even so, its not 
> like we are talking about great expense here: Even having access to 
> weaker GPUs could make a big difference in Qubes' power and usability.
> 
> Projecting our own personal routines on the issue will probably not be 
> of much help. And I think I've already made the case against framing 
> this as a games issue; I'd urge the community not to look down its nose 
> on graphics in this way or we will find the world of graphics can stare 
> back at us more sharply. If it gets to the point where OpenBSD is 
> recommended over Qubes because the latter "can't do much" and "lack of 
> GPU virtualization sounds pretty insecure" then I think we'll be in real 
> trouble. :)
> 


You are right, happened to me once when I didn't realize I had onboard gpu on 
my system when I could of used it until it was too late.

Well I dunno man,  I only would need gpu passthrough for gaming.  Maybe thats 
my personal reasons,  but I'm sure that is the reason for most people.  Do I 
really live in a bubble? I'm not so sure.  I guess the only other reason would 
be now that you mentioned the 3d printing and VR.  Although I don't think many 
people are doing that even though its always interesting news.   And imo, 
although I'm no expert,   exposing hardware more to do that, even if isolated 
in some way,  feels like more of a security risk to me.

I remember the reading the forum arguments pax team had with joanna online, and 
one was so what if the vm is isolated.  The one actual fact besides spenders 
usual temper tantrum ranting, for claiming it was false sense of security,   
was when he talked about exploiting the gpu for persistent compromise.  That 
was his only poc example he had.   And thats not even considering the gpu 
passthrough and 3d rendering you are calling for.  

And I know i'm very paranoid,  but sometimes I think people ask questions on 
the forums on how to do things that qubes was not designed to do,  or want 
certain features added,  to make it easier for them to hack qubes users. LMAO.  
I know I will get flamed for saying that,  but its how I feel sometimes.   
Maybe because I'm a noob, but I feel like the more abilities and features we 
give qubes the more attack surface we give it, which defeats the purpose of 
even using it.  If people can't give up gaming to use qubes,  then they don't 
care about serious security on the machine anyways, imo.But like i said I 
don't know the technicals really of how isolation works in qubes and I'm 
talking out of my ass, so maybe I'm wrong.

-- 
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/7187de3d-6e63-4a4d-a54a-1218ce90b8eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-08 Thread Chris Laprise 

On 07/08/2016 12:27 AM, raahe...@gmail.com wrote:

I'm also confused,  you say gpus are so insecure and that qubes is not doing 
enough to isolate them?
I don't think that's what I implied. But trying to be concise on a 
complex subject can leave some people with the wrong impression, so I 
apologize if I've left out too much.


Two issues with GPUs I'm assuming are that they represent a target for 
malware (being a large computing resource), and also that when we try to 
isolate them most do not respond well to bus commands that enable things 
like passthrough (i.e. they do not 'behave' in IOMMU isolation). 
Passthrough is also clunky, requiring at least another display output. 
GPU virtualization is another way for domU apps to access GPU functions, 
and it shouldn't require separate displays or secondary graphics chips.



Excuse me for being noob but doesn't qubes not allow most gpu functions to go 
past dom0.


AFAIK, Qubes doesn't allow any GPU functions whatsoever from domU into 
dom0. Qubes graphics are virtualized in a 2D, non-accelerated way. 
Having limited developer resources, that is a good first step to making 
the system secure and I'm glad it works that way--for now. But I also 
realize that needs to be a transitional phase and to not remain the 
status quo.


Graphics vendors are currently demonstrating GPU virtualization 
technology that would make GPU utilization safe, inviting developers to 
use it. ITL says this would take a lot of developer effort, however.



And so you would rather have them in domu domains with similar isolation as 
the netcard vm (which has no choice)  and you would feel that more secure?  I'm 
no expert so dont' know if thats true.  If not would even having the ability on 
machine make me more vulnerable even if not applying it myself?  excuse my 
noobness.


Hmmm, no. I think the choice is to either leave the GPU in a privileged 
domain such as dom0 and employ GPU virtualization to allow safe access 
from domUs, or to improve in some way the current (impractical) practice 
of isolating secondary graphics cards in domUs so that they actually 
work when they're properly isolated.



Most people also dont' have two gpus in their machine, which you imply would be 
the most secure way to use this feature?  Only people I know of that do are 
gamers.  If you do graphic designing and need to use special professional 
programs that require gpu processing I would recommend using a separate 
computer.  But it seems this might be a feature in the future on Qubes.  I 
wouldn't call it a priority though.


A lot of people have two GPUs and don't realize it. Even so, its not 
like we are talking about great expense here: Even having access to 
weaker GPUs could make a big difference in Qubes' power and usability.



I think Qubes is fine for normal everyday users doing everyday tasks for home 
and office use.  I can still edit photos, watch movies, create greeting cards, 
view almost any webpage.  Only thing I can't do is play video games.  And thats 
fine I have another machine for that, since i consider playing video games one 
of the most dangerous things you can do online anyways.


Projecting our own personal routines on the issue will probably not be 
of much help. And I think I've already made the case against framing 
this as a games issue; I'd urge the community not to look down its nose 
on graphics in this way or we will find the world of graphics can stare 
back at us more sharply. If it gets to the point where OpenBSD is 
recommended over Qubes because the latter "can't do much" and "lack of 
GPU virtualization sounds pretty insecure" then I think we'll be in real 
trouble. :)



Its nice that you have so much faith in Qubes and that it can stop all attacks, but that 
is unrealistic.  There is still always danger when doing untrusted tasks even when using 
Qubes, even with its hardware isolation.  People should realize what.  Qubes themselves 
describe it as "somewhat" secure, meaning much better then a traditional os,  
but nothing is 100%.


That is always a factor no matter what we do with Qubes. But it seems to 
me that the simple Qubes interfaces have already been used to enable 
some pretty complex functionality "securely". I don't think it follows 
that accessing GPUs through them necessarily incurs unacceptable risk; 
but even if this is a possibility, it requires further investigation. 
Since GPU manufacturers now have an incentive to not appear as an 
element that undermines security (hence, the GPU virtualization 
initiatives they're taking) there is a good chance that some reasonably 
secure accommodation can be made for primary graphics.


The alternative is to endow Qubes systems with secondary graphics that 
work nicely with passthrough. Currently, users can experiment with this 
in a piecemeal fashion and likely meet with failure.


Chris

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Chris Laprise 



On 07/07/2016 12:45 PM, Duncan Guthrie wrote:


On 7 July 2016 16:53:35 BST, Chris Laprise  wrote:

On 07/07/2016 10:40 AM, Duncan Guthrie wrote:

On 7 July 2016 03:28:48 BST, Chris Laprise 

wrote:

On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:

I'm not so adamant about wanting gpu passthrough on qubes,  cause

imo,  gaming online usually means all security is out the window.

Plus

I feel as though gpu is much bigger attack surface for side channel
attacks then net card.  I could be wrong because I have no clue

about

low level stuff, but I feel it would somehow undermine purpose of

using

qubes.  Maybe I'm wrong.

I think this is wrong because many kinds of apps rely on GPUs now:
Media
decoding and creation, 3D design and printing (I would love to have
even
just SketchUp on Qubes!), and any other responsive 3D interface that
app
designers want to offer. This even includes web pages,

crypto-currency,

and many scientific apps. GPUs are now general processing engines

that

embody MOST of a typical computer's processing power.

This is not about games.


I think this is wrong. Most heavy computer users work in offices and

do word processing and spreadsheets, the 'average' casual use is
generally web browsing and light media consumption.

Qubes works fine for using Libreoffice, web applications and social

media, and programming e.g. in Python. Graphics designers can use GIMP
or InkScape, or any of the Windows programs that they commonly use.

It is true that you won't be able to use 3D applications like

SketchUp, but I do not think such tasks constitute most of the average
workload as you say. Perhaps they make up most of your workload, but I
don't think that you speak for everyone here. I have found Qubes works
for me, and people I know do similar tasks on their computers.

Furthermore, there is no getting around the fact that visual

rendering

is integral to security. The GPU can see any private info that you

can,

and if compromised can take steps to trick users into sabotaging

their

own privacy and security. Like the CPU, the GPU must be accepted as

a

core component of trust, and protected as such... at least any GPU

that

operates the admin and trusted domains.

It is fortunate that we at least have a trend of integrated GPUs (in
APUs) where the GPU is manufactured into the same package as the
(implicitly) trusted CPU. For the time being, this is a boost to

Qubes'

compatibility and security even if the GPUs are under-utilized.

For Qubes to either 1) give up on GPU support, or 2) relegate them

to

untrusted status would be an _irretrievable_ error in judgment. It
would
make the OS a 21st century terminal application, because the lions
share
of the power expected by PC users would be missing (as it is
currently).

Chris


I dispute this argument. Dropping "GPU support" (I am not sure where

you get this impression) is hardly going to make Qubes a terminal
application. You can use anything that uses 2D graphics, and can play
music and movies, and do word processing, and email, and software
development, and... The list goes on. Qubes is about security, and
allowing such high level access for the GPU is a terrible compromise.

I am not proposing that domUs have direct access to graphics systems
operating in dom0. GPU access needs to be properly virtualized, and
thankfully some groundwork by Intel (and probably others) has been laid

for it. Alternately, a specification for well-behaving discrete
graphics
could make graphics passthrough a realistic option for many people.

Marek has already stated that any domU used for primary graphics (as
unrealistic as that may be, given the state of passthrough
compatibility) will be a trusted one, and that the purpose of such an
implementation would be to facilitate the use of Linux graphics drivers

while the rest of the OS slims down and experiments with microkernel
admin and storage vms.

The current state is, of course, one of trusting the GPU. That poses a
problem for those who want both discrete graphics and anti-tampering
(AEM) but otherwise? I don't see the compromise you mention.


What are you suggesting then? You are criticising Qubes for not having good GPU 
support, but recognise that you can't have good security when GPU has access to 
hardware? I am sorry but I don't understand your point fully, and would 
appreciate it if you could elaborate further. What is your solution, do you 
want there to be virtualised domains for GPU? If I remember correctly, this is 
a feature being worked on.


Qubes doesn't have good GPU support; It is a work in progress on many 
fronts.


I mentioned that it could go in the direction of GPU virtualization or 
better passthrough support, or both. In either case, there would still 
be a protected primary graphics card that would at least render dom0 and 
other trusted domains. But with the former, the primary graphics can 
also safely process requests

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Duncan Guthrie 


On 7 July 2016 16:53:35 BST, Chris Laprise  wrote:
>On 07/07/2016 10:40 AM, Duncan Guthrie wrote:
>>
>> On 7 July 2016 03:28:48 BST, Chris Laprise 
>wrote:
>>> On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:
 I'm not so adamant about wanting gpu passthrough on qubes,  cause
>>> imo,  gaming online usually means all security is out the window. 
>Plus
>>> I feel as though gpu is much bigger attack surface for side channel
>>> attacks then net card.  I could be wrong because I have no clue
>about
>>> low level stuff, but I feel it would somehow undermine purpose of
>using
>>> qubes.  Maybe I'm wrong.
>>>
>>> I think this is wrong because many kinds of apps rely on GPUs now:
>>> Media
>>> decoding and creation, 3D design and printing (I would love to have
>>> even
>>> just SketchUp on Qubes!), and any other responsive 3D interface that
>>> app
>>> designers want to offer. This even includes web pages,
>crypto-currency,
>>>
>>> and many scientific apps. GPUs are now general processing engines
>that
>>> embody MOST of a typical computer's processing power.
>>>
>>> This is not about games.
>>>
>> I think this is wrong. Most heavy computer users work in offices and
>do word processing and spreadsheets, the 'average' casual use is
>generally web browsing and light media consumption.
>> Qubes works fine for using Libreoffice, web applications and social
>media, and programming e.g. in Python. Graphics designers can use GIMP
>or InkScape, or any of the Windows programs that they commonly use.
>> It is true that you won't be able to use 3D applications like
>SketchUp, but I do not think such tasks constitute most of the average
>workload as you say. Perhaps they make up most of your workload, but I
>don't think that you speak for everyone here. I have found Qubes works
>for me, and people I know do similar tasks on their computers.
>>
>>> Furthermore, there is no getting around the fact that visual
>rendering
>>> is integral to security. The GPU can see any private info that you
>can,
>>>
>>> and if compromised can take steps to trick users into sabotaging
>their
>>> own privacy and security. Like the CPU, the GPU must be accepted as
>a
>>> core component of trust, and protected as such... at least any GPU
>that
>>>
>>> operates the admin and trusted domains.
>>>
>>> It is fortunate that we at least have a trend of integrated GPUs (in
>>> APUs) where the GPU is manufactured into the same package as the
>>> (implicitly) trusted CPU. For the time being, this is a boost to
>Qubes'
>>>
>>> compatibility and security even if the GPUs are under-utilized.
>>>
>>> For Qubes to either 1) give up on GPU support, or 2) relegate them
>to
>>> untrusted status would be an _irretrievable_ error in judgment. It
>>> would
>>> make the OS a 21st century terminal application, because the lions
>>> share
>>> of the power expected by PC users would be missing (as it is
>>> currently).
>>>
>>> Chris
>>>
>> I dispute this argument. Dropping "GPU support" (I am not sure where
>you get this impression) is hardly going to make Qubes a terminal
>application. You can use anything that uses 2D graphics, and can play
>music and movies, and do word processing, and email, and software
>development, and... The list goes on. Qubes is about security, and
>allowing such high level access for the GPU is a terrible compromise.
>
>I am not proposing that domUs have direct access to graphics systems 
>operating in dom0. GPU access needs to be properly virtualized, and 
>thankfully some groundwork by Intel (and probably others) has been laid
>
>for it. Alternately, a specification for well-behaving discrete
>graphics 
>could make graphics passthrough a realistic option for many people.
>
>Marek has already stated that any domU used for primary graphics (as 
>unrealistic as that may be, given the state of passthrough 
>compatibility) will be a trusted one, and that the purpose of such an 
>implementation would be to facilitate the use of Linux graphics drivers
>
>while the rest of the OS slims down and experiments with microkernel 
>admin and storage vms.
>
>The current state is, of course, one of trusting the GPU. That poses a 
>problem for those who want both discrete graphics and anti-tampering 
>(AEM) but otherwise? I don't see the compromise you mention.
>

What are you suggesting then? You are criticising Qubes for not having good GPU 
support, but recognise that you can't have good security when GPU has access to 
hardware? I am sorry but I don't understand your point fully, and would 
appreciate it if you could elaborate further. What is your solution, do you 
want there to be virtualised domains for GPU? If I remember correctly, this is 
a feature being worked on.

>Defining personal computing and what most people want as a list of 
>traditional activities--instead of using examples of innovative apps
>and 
>the kind of directions app developers can go--is a mistake that leads 
>projects into

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Chris Laprise 

On 07/07/2016 10:40 AM, Duncan Guthrie wrote:


On 7 July 2016 03:28:48 BST, Chris Laprise  wrote:

On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:

I'm not so adamant about wanting gpu passthrough on qubes,  cause

imo,  gaming online usually means all security is out the window.  Plus
I feel as though gpu is much bigger attack surface for side channel
attacks then net card.  I could be wrong because I have no clue about
low level stuff, but I feel it would somehow undermine purpose of using
qubes.  Maybe I'm wrong.

I think this is wrong because many kinds of apps rely on GPUs now:
Media
decoding and creation, 3D design and printing (I would love to have
even
just SketchUp on Qubes!), and any other responsive 3D interface that
app
designers want to offer. This even includes web pages, crypto-currency,

and many scientific apps. GPUs are now general processing engines that
embody MOST of a typical computer's processing power.

This is not about games.


I think this is wrong. Most heavy computer users work in offices and do word 
processing and spreadsheets, the 'average' casual use is generally web browsing 
and light media consumption.
Qubes works fine for using Libreoffice, web applications and social media, and 
programming e.g. in Python. Graphics designers can use GIMP or InkScape, or any 
of the Windows programs that they commonly use.
It is true that you won't be able to use 3D applications like SketchUp, but I 
do not think such tasks constitute most of the average workload as you say. 
Perhaps they make up most of your workload, but I don't think that you speak 
for everyone here. I have found Qubes works for me, and people I know do 
similar tasks on their computers.


Furthermore, there is no getting around the fact that visual rendering
is integral to security. The GPU can see any private info that you can,

and if compromised can take steps to trick users into sabotaging their
own privacy and security. Like the CPU, the GPU must be accepted as a
core component of trust, and protected as such... at least any GPU that

operates the admin and trusted domains.

It is fortunate that we at least have a trend of integrated GPUs (in
APUs) where the GPU is manufactured into the same package as the
(implicitly) trusted CPU. For the time being, this is a boost to Qubes'

compatibility and security even if the GPUs are under-utilized.

For Qubes to either 1) give up on GPU support, or 2) relegate them to
untrusted status would be an _irretrievable_ error in judgment. It
would
make the OS a 21st century terminal application, because the lions
share
of the power expected by PC users would be missing (as it is
currently).

Chris


I dispute this argument. Dropping "GPU support" (I am not sure where you get 
this impression) is hardly going to make Qubes a terminal application. You can use 
anything that uses 2D graphics, and can play music and movies, and do word processing, 
and email, and software development, and... The list goes on. Qubes is about security, 
and allowing such high level access for the GPU is a terrible compromise.


I am not proposing that domUs have direct access to graphics systems 
operating in dom0. GPU access needs to be properly virtualized, and 
thankfully some groundwork by Intel (and probably others) has been laid 
for it. Alternately, a specification for well-behaving discrete graphics 
could make graphics passthrough a realistic option for many people.


Marek has already stated that any domU used for primary graphics (as 
unrealistic as that may be, given the state of passthrough 
compatibility) will be a trusted one, and that the purpose of such an 
implementation would be to facilitate the use of Linux graphics drivers 
while the rest of the OS slims down and experiments with microkernel 
admin and storage vms.


The current state is, of course, one of trusting the GPU. That poses a 
problem for those who want both discrete graphics and anti-tampering 
(AEM) but otherwise? I don't see the compromise you mention.


Defining personal computing and what most people want as a list of 
traditional activities--instead of using examples of innovative apps and 
the kind of directions app developers can go--is a mistake that leads 
projects into an unbearable surfeit of unsupported corner cases. And 
seriously-- if that's what it would come to then just develop a 
convenient firmware verification and re-flashing system and run TAILS on 
the hardware; it would save considerable time and effort.


An accurate view of use cases would hardly stop at office software and 
playing music because almost everyone has make-or-break corner cases. 
Teleconferencing and 3D printing, for example, are now SMB and home user 
activities that benefit from GPUs, which become more necessary due to 
the extra CPU overhead of domain isolation.


As for suggesting server-based processing of large jobs to Qubes 
users... I'm not even sure where to start with that one.


Chris

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-07 Thread Duncan Guthrie 


On 7 July 2016 03:28:48 BST, Chris Laprise  wrote:
>On 07/06/2016 09:42 PM, raahe...@gmail.com wrote:
>> I'm not so adamant about wanting gpu passthrough on qubes,  cause
>imo,  gaming online usually means all security is out the window.  Plus
>I feel as though gpu is much bigger attack surface for side channel
>attacks then net card.  I could be wrong because I have no clue about
>low level stuff, but I feel it would somehow undermine purpose of using
>qubes.  Maybe I'm wrong.
>
>I think this is wrong because many kinds of apps rely on GPUs now:
>Media 
>decoding and creation, 3D design and printing (I would love to have
>even 
>just SketchUp on Qubes!), and any other responsive 3D interface that
>app 
>designers want to offer. This even includes web pages, crypto-currency,
>
>and many scientific apps. GPUs are now general processing engines that 
>embody MOST of a typical computer's processing power.
>
>This is not about games.
>
I think this is wrong. Most heavy computer users work in offices and do word 
processing and spreadsheets, the 'average' casual use is generally web browsing 
and light media consumption.
Qubes works fine for using Libreoffice, web applications and social media, and 
programming e.g. in Python. Graphics designers can use GIMP or InkScape, or any 
of the Windows programs that they commonly use.
It is true that you won't be able to use 3D applications like SketchUp, but I 
do not think such tasks constitute most of the average workload as you say. 
Perhaps they make up most of your workload, but I don't think that you speak 
for everyone here. I have found Qubes works for me, and people I know do 
similar tasks on their computers.

>Furthermore, there is no getting around the fact that visual rendering 
>is integral to security. The GPU can see any private info that you can,
>
>and if compromised can take steps to trick users into sabotaging their 
>own privacy and security. Like the CPU, the GPU must be accepted as a 
>core component of trust, and protected as such... at least any GPU that
>
>operates the admin and trusted domains.
>
>It is fortunate that we at least have a trend of integrated GPUs (in 
>APUs) where the GPU is manufactured into the same package as the 
>(implicitly) trusted CPU. For the time being, this is a boost to Qubes'
>
>compatibility and security even if the GPUs are under-utilized.
>
>For Qubes to either 1) give up on GPU support, or 2) relegate them to 
>untrusted status would be an _irretrievable_ error in judgment. It
>would 
>make the OS a 21st century terminal application, because the lions
>share 
>of the power expected by PC users would be missing (as it is
>currently).
>
>Chris
>

I dispute this argument. Dropping "GPU support" (I am not sure where you get 
this impression) is hardly going to make Qubes a terminal application. You can 
use anything that uses 2D graphics, and can play music and movies, and do word 
processing, and email, and software development, and... The list goes on. Qubes 
is about security, and allowing such high level access for the GPU is a 
terrible compromise.

>> Plus as a gamer myself,  I always want the most fps the machine can
>dish,  and that's definitely not by running games in a vm.
>>
>> I have a separate machine for sensitive and daily tasks running
>qubes.  Most people use consoles for gaming now anyways.  Hardware
>industry has been dying for a decade and I never had any reason or
>thought I would ever build a custom pc again,  until qubes!  :)
>>
If you are doing something really heavy like statistical work you often would 
use a dedicated server for this. As far as I know connecting to such servers 
would be possible using Qubes. At any rate you could always use Qubes for 
personal use and then have a dedicated work computer for stats, 3D development, 
etc.

These are just my own observations.
Hope it helps, 
D.

-- 
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/8BF8CE0E-1077-441A-B41C-1D7CE520EF64%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-06 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-06 14:24, juris...@gmail.com wrote:
> Em quarta-feira, 6 de julho de 2016 17:28:49 UTC-3, Andrew David 
> Wong escreveu: On 2016-07-06 12:33, juris...@gmail.com wrote:
 Em quarta-feira, 6 de julho de 2016 12:37:31 UTC-3, Andrew 
 David Wong escreveu: On 2016-07-05 12:35, juris...@gmail.com
  wrote: I mean, what is the default encryption? what are the
  default iteractions? How many bits?
> 
> $ cryptsetup --help cryptsetup 1.6.4 [...] Default compiled-in 
> device cipher paramters: [...] LUKS1: aes-xts-plain64, Key: 256 
> bits, LUKS header hashing: sha1, RNG: /dev/urandom
> 
 Plus, like i said, i am an USER. I am a LAWYER, not a 
 programmer. The system should not be directed for people to,
  without ANYTHING in installer telling me things like i read
  in the link you pointed me like "aes-xts-plain should not
 be used for encrypted container sizes larger than 2TiB. Use 
 aes-xts-plain64 for that" should be automatic warning in a 
 pop up when the person chosing encryption inside the 
 installer is chosing it!
 
> 
> aes-xts-plain64 is already the default, so there's no need for such
> a pop-up warning. That would just unnecessarily confuse users and
> clutter up the installer.
> 
> The same applies for most other settings. Sensible defaults are 
> already in place, and there's a limit to how much information
> users are willing to digest and read through in order to go through
> with the installation. The information presented must be
> prioritized, since users' cognitive resources are limited.
> 
 Still the suggestion remains and with solid reasons:
 
 1) a normal user DO NOT KNOW what WAS USED as encryption 
 inside the installer. When i say that, i say AES? SERPENT? 
 128 bits? 256? Whirlpool? Not if it used LUKS, but even that 
 is something that should be pointed, not just a "chose your 
 password"
 
> 
> A normal user doesn't need to know these details. An advanced user
>  can easily find out, or even configure things themselves:
> 
> https://www.qubes-os.org/doc/encryption-config/
> 
 2) Outside the installer, is sad that is not in qubes faq or
  in the website.
 
> 
> Feel free to help us improve the documentation:
> 
> https://www.qubes-os.org/doc/doc-guidelines/#tocAnchor-1-1-2
> 
 3) And options to chose encryption are still a need. So the 
 user can chose speed/security. For example, i dont trust AES
  intel thing, so i like to use serpent.
> 
> Again, patches are welcome.
> 
 Plus, when i typed wrong FDE password, i could try again
 VERY QUICKLY, so i doubt a good secure iteraction number was
  used.
 
> 
> Again, you can configure this yourself:
> 
> https://www.qubes-os.org/doc/encryption-config/
> 
 Imagine i keep telling my windows friends that knows nothing
  about programming to install QUBES and then when they ask 
 about the encryption i paste a link like that and say STUDY 
 SOME HOURS AND SOLVE THE PROBLEMS EVERY ONE OF YOU. HOURS
 FOR EACH STEP SO YOU DONT MAKE DUMB THINGS. Thats kinda 
 nonsense.
 
> 
> Not necessary. The defaults are fine for most users.
> 
 I mean, a security distro for desktop user, should have like 
 a warning button pop up, "IF YOU USE SSD YOU CAN HAVE THE 
 ISSUES X OR Y WITH ENCRYPTION", or other warnings everyone 
 should know, in the programmer choice.
> 
> Again, too many pop-ups of that sort would create unnecessary 
> cognitive load on users. In cases where something is truly 
> dangerous, either a sensible default is chosen, or if the user must
> make a choice, a warning will be shown. Otherwise, we make sure to
> clearly state such warnings in the documentation.
> 
 For example, after i did read the link you pasted, i tought 
 was VERY IMPORTANT to know that: "CLONING/IMAGING: If you 
 clone or image a LUKS container, you make a copy of the LUKS 
 header and the master key will stay the same! That means that
 if you distribute an image to several machines, the same 
 master key will be used on all of them, regardless of
 whether you change the passphrases. Do NOT do this! If you
 do, a root-user on any of the machines with a mapped
 (decrypted) container or a passphrase on that machine can
 decrypt all other copies, breaking security. See also Item
 6.15." ... So... wth?? If you change the password, anyone
 with any password can read my encryption WITHOUT MY PASSWORD?
 So, whats the point in changing password of a container in
 case was compromised?
 
> 
> I think you're misreading that. That only applies under a very 
> specific set of circumstances (described in the quotation).
> 
 I mean, giving warnings and orientations would be a very
 time consuming thing, i know, i was just mentioning the ideal
  scenario from a security distro installer, but

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-06 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-06 12:33, juris...@gmail.com wrote:
> Em quarta-feira, 6 de julho de 2016 12:37:31 UTC-3, Andrew David
> Wong escreveu: On 2016-07-05 12:35, juris...@gmail.com wrote:
 Em terça-feira, 5 de julho de 2016 06:54:14 UTC-3, Andrew 
 David Wong escreveu: On 2016-07-04 22:46, juris...@gmail.com 
 wrote:
>>> 1) qubes is a system for security and isolation. But
>>> when you install, you have no encryption options.
 
 Qubes uses full disk enryption by default:
 
 https://www.qubes-os.org/doc/user-faq/#does-qubes-use-full- 
 disk-encryption-fde
 
>>> distros thinks that if a user wants some strong crypto 
>>> thing, they must research themselves and do all
>>> manually. We dont even find nothing about qubes
>>> encryption in docs. That is wrong.
 
 I added this page to our docs a week ago:
 
 https://www.qubes-os.org/doc/encryption-config/
 
>>> [...]
>>> 
>>> 5) i will use this post to state that tor behaves 
>>> differently to connect in windows tor browser, or
>>> linux tor browser, compared to whonix, and i dont know
>>> why. Whonix gets always same speed, 250 to 500 Kbps,
>>> (not KBps) with speed of 30 to 60 kB/s of downloads,
>>> and in tor browser outside whonix, i get 500 to 1 Mb
>>> kB/s downloads. Thats really strange and wasn`t
>>> expected. I get this behavior for almost 2 years, and i
>>> dont have the expertize to know why. after some
>>> googling, i saw i am not the only one getting different
>>> special routes in tor using whonix.
>>> 
 
 This sounds like something that should be reported to the Tor
  project or Whonix.
 
 
 Thanks, Andrew. But still... I did not find wich encryption
 is used by default in qubes documentation.
> 
> Well, Qubes just uses cryptsetup/LUKS/dm-crypt from upstream, so
> you should really be looking for that in the cryptsetup
> documentation (FAQ):
> 
> https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestion
s
>
>
> 
 And people still has to do it manually. Plus, when i went to 
 the advanced partitioning, there were lots of bugs. We need
 to be able to chose serpent, aes, cascade, iteractions, etc.
 
> 
> Patches welcome!
> 
> 
> I mean, what is the default encryption? what are the default 
> iteractions? How many bits?

$ cryptsetup --help
cryptsetup 1.6.4
[...]
Default compiled-in device cipher paramters:
[...]
LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing:
sha1, RNG: /dev/urandom

> Plus, like i said, i am an USER. I am a LAWYER, not a programmer.
> The system should not be directed for people to, without ANYTHING
> in installer telling me things like i read in the link you pointed
> me like "aes-xts-plain should not be used for encrypted container
> sizes larger than 2TiB. Use aes-xts-plain64 for that" should be
> automatic warning in a pop up when the person chosing encryption
> inside the installer is chosing it!
> 

aes-xts-plain64 is already the default, so there's no need for such a
pop-up warning. That would just unnecessarily confuse users and
clutter up the installer.

The same applies for most other settings. Sensible defaults are
already in place, and there's a limit to how much information users
are willing to digest and read through in order to go through with the
installation. The information presented must be prioritized, since
users' cognitive resources are limited.

> Still the suggestion remains and with solid reasons:
> 
> 1) a normal user DO NOT KNOW what WAS USED as encryption inside
> the installer. When i say that, i say AES? SERPENT? 128 bits? 256? 
> Whirlpool? Not if it used LUKS, but even that is something that 
> should be pointed, not just a "chose your password"
> 

A normal user doesn't need to know these details. An advanced user can
easily find out, or even configure things themselves:

https://www.qubes-os.org/doc/encryption-config/

> 2) Outside the installer, is sad that is not in qubes faq or in
> the website.
> 

Feel free to help us improve the documentation:

https://www.qubes-os.org/doc/doc-guidelines/#tocAnchor-1-1-2

> 3) And options to chose encryption are still a need. So the user
> can chose speed/security. For example, i dont trust AES intel
> thing, so i like to use serpent.

Again, patches are welcome.

> Plus, when i typed wrong FDE password, i could try again VERY
> QUICKLY, so i doubt a good secure iteraction number was used.
> 

Again, you can configure this yourself:

https://www.qubes-os.org/doc/encryption-config/

> Imagine i keep telling my windows friends that knows nothing about 
> programming to install QUBES and then when they ask about the 
> encryption i paste a link like that and say STUDY SOME HOURS AND 
> SOLVE THE PROBLEMS EVERY ONE OF YOU. HOURS FOR EACH STEP SO YOU
> DONT MAKE DUMB THINGS. Thats kinda nonsense.
>

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-06 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-05 12:35, juris...@gmail.com wrote:
> Em terça-feira, 5 de julho de 2016 06:54:14 UTC-3, Andrew David
> Wong escreveu: On 2016-07-04 22:46, juris...@gmail.com wrote:
 1) qubes is a system for security and isolation. But when you
  install, you have no encryption options.
> 
> Qubes uses full disk enryption by default:
> 
> https://www.qubes-os.org/doc/user-faq/#does-qubes-use-full- 
> disk-encryption-fde
> 
 distros thinks that if a user wants some strong crypto thing,
  they must research themselves and do all manually. We dont 
 even find nothing about qubes encryption in docs. That is 
 wrong.
> 
> I added this page to our docs a week ago:
> 
> https://www.qubes-os.org/doc/encryption-config/
> 
 [...]
 
 5) i will use this post to state that tor behaves differently
  to connect in windows tor browser, or linux tor browser, 
 compared to whonix, and i dont know why. Whonix gets always 
 same speed, 250 to 500 Kbps, (not KBps) with speed of 30 to
 60 kB/s of downloads, and in tor browser outside whonix, i
 get 500 to 1 Mb kB/s downloads. Thats really strange and
 wasn`t expected. I get this behavior for almost 2 years, and
 i dont have the expertize to know why. after some googling, i
 saw i am not the only one getting different special routes in
 tor using whonix.
 
> 
> This sounds like something that should be reported to the Tor
> project or Whonix.
> 
> 
> Thanks, Andrew. But still... I did not find wich encryption is used
>  by default in qubes documentation.

Well, Qubes just uses cryptsetup/LUKS/dm-crypt from upstream, so you
should really be looking for that in the cryptsetup documentation (FAQ):

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

> And people still has to do it manually. Plus, when i went to the 
> advanced partitioning, there were lots of bugs. We need to be able
> to chose serpent, aes, cascade, iteractions, etc.
> 

Patches welcome!

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXfSWyAAoJENtN07w5UDAw3C4QAMA/sIgs5nXL6TJN/kyLslkK
vycm0sed8mLJy9caFbh1N2rgo6COaMD4ql6UHFast9JYpwugZ0ld6u0za2Nx7eoh
XPiuUpHY4r745UEz7VhAHEkJZtNXnPlzmcJlb7r79lq35Ck/oHlvbrUBGXfzRctJ
FYNK7CSoWqy385hFSNcH5EHrlySmwIpxFjs7zLYegN3MyBTjqmXlTex8whyiV7o7
zSdvsZsawKcB172LUbwxCcKTc33a7uFsFRsDpcdDjIlkoSBjKFfQVQovcXMLzxFU
dv7Sse3j6cmeV7MbegD9zYRNC4/KIE5rIva0bWM8rDwLhgIdpWyrdZyEl5PQf4Zz
prFRE8c0+6CCSAxFLVcK8GVtWmjHPN5IjeFDV/qNpL8/hRBI9B8U2liDaC+6XQhM
CEo7Cqx98ciOz+pP7Rq3PsArWmi57J/ZgjPtU/5ITDkuiU6MzIMuzVnhiQVMMV+p
VztfM4239yDQGc/Xh+lTRKeFqebFW7w4+02nm0VFslIYbmmkzvKcwkv2Zd6vTAGw
WfGnf5aTf0SdILL7QZ1gVHoPq6bPIM3Bxg9Bs1JhLACcRT18JJotCBnAmttcCUxJ
MDuBTkXPB5H27oWybgyv0KPnNFFLCjwWmU1vcMB9p426CGiOSdzoEemj4TdF1OvZ
6yl1Ymih9pRVSb6y/r88
=qvTi
-END PGP SIGNATURE-

-- 
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/c42f20ef-3647-5e91-186d-b9c0371aa716%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-05 Thread jurisdan 
Em terça-feira, 5 de julho de 2016 06:54:14 UTC-3, Andrew David Wong  escreveu:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-07-04 22:46, juris...@gmail.com wrote:
> > 1) qubes is a system for security and isolation. But when you 
> > install, you have no encryption options.
> 
> Qubes uses full disk enryption by default:
> 
> https://www.qubes-os.org/doc/user-faq/#does-qubes-use-full-
> disk-encryption-fde
> 
> > distros thinks that if a user wants some strong crypto thing, they 
> > must research themselves and do all manually. We dont even find 
> > nothing about qubes encryption in docs. That is wrong.
> 
> I added this page to our docs a week ago:
> 
> https://www.qubes-os.org/doc/encryption-config/
> 
> > [...]
> > 
> > 5) i will use this post to state that tor behaves differently to 
> > connect in windows tor browser, or linux tor browser, compared to 
> > whonix, and i dont know why. Whonix gets always same speed, 250 to 
> > 500 Kbps, (not KBps) with speed of 30 to 60 kB/s of downloads, and 
> > in tor browser outside whonix, i get 500 to 1 Mb kB/s downloads. 
> > Thats really strange and wasn`t expected. I get this behavior for 
> > almost 2 years, and i dont have the expertize to know why. after 
> > some googling, i saw i am not the only one getting different 
> > special routes in tor using whonix.
> > 
> 
> This sounds like something that should be reported to the Tor project
> or Whonix.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJXe4O8AAoJENtN07w5UDAwVKgP/i1oNbYm7iPRscBw6bk+m5VC
> QJvwPbvXefMq2TBRMCI+J/K/pviRl+OKTXtpEuurq6HOg2fIlGx8H25H4JGIcf0W
> rFREbHo4SLiDIDH3fySzaRGp8SawTwf4ejIlMajRjbBIUzbUhveXC1o3n6jJP9s/
> UkuH34xT0cUIitfhMIXlgLmZsDrConvkm+0ExCTFVXZnUS4Jz96tTkCVerTBuVei
> C85OsqqJBN7guTq79iqMq/XE1r6kho0qF5qaX02MN6/M9NLRslGNI9AXjKoBKxAr
> YPi6t3S2BbglCJuMzQvABNu2UXaTr3k8qSZI/sLbYf+XbIRSeiD21dDEKkLPoW12
> MHrU1GwIex6SDlMfPDlxJ9FLNKDgDHr+LfF7yAOHKWEzoNjChcJtKutLK7zh28MG
> 3ab+0Ahwt/9MY8I/WFUX4eKVxbVLnFMFzMU6AfcxxgU1WdgEATbrUzIt5+vH6YKQ
> 6Mx0+utRDWz/ieE/SdKy02bCRkxVMMHZbcuUXFER27VgSPHh9uXYBtIt90ym6Qzp
> fMQZIhhumbnglCgiS11T5rRal6urw7yAyQCdkLy1p/uOBKnWEnO96Gmuswmet5z3
> x5mSJwDHBXYOx+Qqcnc+4vYFKiABfei1QVORv1h7LAOkGKXd7he3qqakKD6A4xUq
> 8oE0xfcW8xDdDkhaFivx
> =eoZp
> -END PGP SIGNATURE-

Thanks, Andrew. But still... I did not find wich encryption is used by default 
in qubes documentation. And people still has to do it manually. Plus, when i 
went to the advanced partitioning, there were lots of bugs. We need to be able 
to chose serpent, aes, cascade, iteractions, etc. 

-- 
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/768abc8f-ac79-4b68-b97c-abbb3b6d7f77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-05 Thread Chris Laprise 



On 07/05/2016 04:43 AM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 04, 2016 at 10:46:52PM -0700, juris...@gmail.com wrote:

1) qubes is a system for security and isolation. But when you install, you have 
no encryption options.

Full disk encryption is enabled in default installation option.


2) Qubes face 2 problems nowadays for engaging new users with real security.

a) Qubes is a system for HIGH END computers with lots of RAM. Usually if for 
people that has WINDOWS and GAMES also, a good GPU, and wont waste their 
machine on a UNIQUE linux system at least without dual boot.

b) Nvidia spy on people, with their streaming @!^@^% they put in new gpus, 
network, etc, and people are suspicious amd too. But most consumers are from 
nvidia. nvidia now spy on hardware level. Does not matter the system security.

The solution? REAL windows virtualization with GPU PASSTROUGH. So, the high end 
computers can use windows for what they need and even play games. Plus, if you 
do use nvidia in dom-0, they WILL capture the screen on hardware level. Nouveau 
is not working right for a long time. Onboard or gpu 1 for dom-0 and nvidia or 
amd high end for windows VM. If the person doesnt have 2 monitors, it can 
change the vga adapter from 1 to other to use windows after starting the vm. 
that would be perfect.

So we give a finger to nvidia and the drivers problems they cause, and we 
isolate their spying inside windows vm, plus eliminating the need for a dual 
boot and for everyone not using their gaming gpus.

This was discussed many times, so search the archive for more detailed
answer. In short: GPU will always be able to see the screen content -
this is what GPU does. Having GPU passthrough done securely (for example
without increasing dom0 attack surface by launching qemu there) is quite
hard because GPUs use a lot of non standard tricks and hacks in addition
to standard PCI operation.

Implementing this is on our roadmap, but it is hard and will take time.


I must ask: Does ITL have a list of well-behaved hardware on which this 
can be accomplished? If there are any laptops out there with the kind of 
workstation-class GPUs that would respond to passthrough predictably and 
reliably--even just one model--then maybe it should be plastered on the 
front page of qubes-os.org.


Beyond that, I think you know my views about Qubes needing more 
comprehensive hardware focus--even design. From here, Qubes with 
designed-for-Windows PCs looks like a strained marriage that's getting 
worse, and the latter was never the kind of blank canvas that many 
considered it to be.


BTW, I think jurisdan does have an excellent point on #4. It would be 
prudent to flag anon proxy vms (the way rpm-sourced templates are 
flagged) so that QM and tools can take preventative action under some 
circumstances: Switching any appvm away from an anon-flagged proxy 
should result in a warning dialog.


Chris

--
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/16b80eaa-5d05-fb82-87bc-b0d72d09a0f1%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-05 Thread Zrubi 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/05/2016 10:38 AM, Franz wrote:

> I fully agree with the idea of respecting user needs, but why do
> you think gamers are really interested in strong security? Only
> because they spend money for expensive computers?  It seems a poor
> motivation for me.

I'm playing games - while interested in strong security.
That's why I using Qubes on my laptop and running windows (as a gaming
platform) on my "gamer" desktop :)

But I would never ever mix the two. Not even with dual boot.


- -- 
Zrubi
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXe4n2AAoJEC3TtYFBiXSvRuwP/A637kHTTdnY7gkuJ2IIStNC
DJ+c5rav6BzMgfCZlPJsE0bkOOTYp6h/aHzhE3f+d8fQTEINkWmclp1xjVK2hp32
X36GoadmErrt94jticCtKWZzEVQhCtE32xBKONsRgl6uc2Ig6R76bMreBj7R1JcH
GEGC4fY0DiF5MTedHkaULpKgNvdt8ayIAdtqWvOZT/rNoHpUVImUb7SVNh5AtmiL
9q+vpc1bORnRZy/BlENayeW3wzWzhsfurYUXXAzG69aPQXDf+wZgOpjRF1wLSpHt
IQ5yigOawq7Rk+FpLsgChvRDcu9PZmcuv6JtBUlaw4o32y0Ghq1ILtbszm1+4XtT
NnliW+t1Cay/4MBIyXbnsWVEG2kzVpJx6UglpzhqIVK5jUUnb5dUHYPcP1c90/tr
UYk3zyeA8fXhhNhkdlJJR6XPY4TslcK9Ne/uK95JtXWq6QgdPyoYDKVCuVYo5hpJ
JdHOtYrZlXFyzRtx9ly2e1EzPvNlZaeszthyU+No3lAh3rUIF1ni0TErzKXGB1Bq
NmhkjbFCISvMdaoxeV9zc+ZYnXRSluJq9gyv3XL2fkeoQy3tnKSI1SPXQlvMTRkx
AvHxaWKryICXW9w9n7XMGB7Dcvc1LPNV/BAf73uUlafsx7h+XfxE8kTqY8/lWTrv
Nejzf4uerTet73dzugGI
=V20z
-END PGP SIGNATURE-

-- 
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/e3309f91-d2ad-a517-b3e4-089ec1a93f62%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-05 Thread Andrew David Wong 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-04 22:46, juris...@gmail.com wrote:
> 1) qubes is a system for security and isolation. But when you 
> install, you have no encryption options.

Qubes uses full disk enryption by default:

https://www.qubes-os.org/doc/user-faq/#does-qubes-use-full-
disk-encryption-fde

> distros thinks that if a user wants some strong crypto thing, they 
> must research themselves and do all manually. We dont even find 
> nothing about qubes encryption in docs. That is wrong.

I added this page to our docs a week ago:

https://www.qubes-os.org/doc/encryption-config/

> [...]
> 
> 5) i will use this post to state that tor behaves differently to 
> connect in windows tor browser, or linux tor browser, compared to 
> whonix, and i dont know why. Whonix gets always same speed, 250 to 
> 500 Kbps, (not KBps) with speed of 30 to 60 kB/s of downloads, and 
> in tor browser outside whonix, i get 500 to 1 Mb kB/s downloads. 
> Thats really strange and wasn`t expected. I get this behavior for 
> almost 2 years, and i dont have the expertize to know why. after 
> some googling, i saw i am not the only one getting different 
> special routes in tor using whonix.
> 

This sounds like something that should be reported to the Tor project
or Whonix.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXe4O8AAoJENtN07w5UDAwVKgP/i1oNbYm7iPRscBw6bk+m5VC
QJvwPbvXefMq2TBRMCI+J/K/pviRl+OKTXtpEuurq6HOg2fIlGx8H25H4JGIcf0W
rFREbHo4SLiDIDH3fySzaRGp8SawTwf4ejIlMajRjbBIUzbUhveXC1o3n6jJP9s/
UkuH34xT0cUIitfhMIXlgLmZsDrConvkm+0ExCTFVXZnUS4Jz96tTkCVerTBuVei
C85OsqqJBN7guTq79iqMq/XE1r6kho0qF5qaX02MN6/M9NLRslGNI9AXjKoBKxAr
YPi6t3S2BbglCJuMzQvABNu2UXaTr3k8qSZI/sLbYf+XbIRSeiD21dDEKkLPoW12
MHrU1GwIex6SDlMfPDlxJ9FLNKDgDHr+LfF7yAOHKWEzoNjChcJtKutLK7zh28MG
3ab+0Ahwt/9MY8I/WFUX4eKVxbVLnFMFzMU6AfcxxgU1WdgEATbrUzIt5+vH6YKQ
6Mx0+utRDWz/ieE/SdKy02bCRkxVMMHZbcuUXFER27VgSPHh9uXYBtIt90ym6Qzp
fMQZIhhumbnglCgiS11T5rRal6urw7yAyQCdkLy1p/uOBKnWEnO96Gmuswmet5z3
x5mSJwDHBXYOx+Qqcnc+4vYFKiABfei1QVORv1h7LAOkGKXd7he3qqakKD6A4xUq
8oE0xfcW8xDdDkhaFivx
=eoZp
-END PGP SIGNATURE-

-- 
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/fc9f9e2e-6b97-36ef-4d35-badb9644677c%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-05 Thread Marek Marczykowski-Górecki 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 04, 2016 at 10:46:52PM -0700, juris...@gmail.com wrote:
> 1) qubes is a system for security and isolation. But when you install, you 
> have no encryption options.

Full disk encryption is enabled in default installation option.

> 2) Qubes face 2 problems nowadays for engaging new users with real security.
> 
> a) Qubes is a system for HIGH END computers with lots of RAM. Usually if for 
> people that has WINDOWS and GAMES also, a good GPU, and wont waste their 
> machine on a UNIQUE linux system at least without dual boot. 
> 
> b) Nvidia spy on people, with their streaming @!^@^% they put in new gpus, 
> network, etc, and people are suspicious amd too. But most consumers are from 
> nvidia. nvidia now spy on hardware level. Does not matter the system 
> security. 
> 
> The solution? REAL windows virtualization with GPU PASSTROUGH. So, the high 
> end computers can use windows for what they need and even play games. Plus, 
> if you do use nvidia in dom-0, they WILL capture the screen on hardware 
> level. Nouveau is not working right for a long time. Onboard or gpu 1 for 
> dom-0 and nvidia or amd high end for windows VM. If the person doesnt have 2 
> monitors, it can change the vga adapter from 1 to other to use windows after 
> starting the vm. that would be perfect.
> 
> So we give a finger to nvidia and the drivers problems they cause, and we 
> isolate their spying inside windows vm, plus eliminating the need for a dual 
> boot and for everyone not using their gaming gpus.

This was discussed many times, so search the archive for more detailed
answer. In short: GPU will always be able to see the screen content -
this is what GPU does. Having GPU passthrough done securely (for example
without increasing dom0 attack surface by launching qemu there) is quite
hard because GPUs use a lot of non standard tricks and hacks in addition
to standard PCI operation.

Implementing this is on our roadmap, but it is hard and will take time.

> So, XEN is not good for that? consider passing to KVM.

This is exactly what would expose dom0 ("host") for huge attack
surface from qemu...

> 3) Consider offering PFSENSE as optional firewall vm installed out of the 
> box. It`s very hard and time consuming to do that inside qubes system without 
> studying all, for managing internal ip structure etc. It is the most perfect 
> firewall for use inside a VM, qubes is a system for VMs, and i did use it 
> even inside windows in virtualbox. But i was in WINDOWS, and that means, no 
> real security at all.

Feel free to send patches...

> I would like also to give 2 more suggestions for people to considerate, 
> concerning whonix, since patrick is a developer here:
> 
> 4) People need a pop-up window to explain them to NEVER use an existing 
> normal vm trough the whonix proxy vm, just NEW ONES. Because they have 
> already fingerprints, identifiers, browser behavior, browser plugins 
> identification, aplication updates, specially in windows. If they connect 
> that with once used real wan IP, game over for anonymity.

It depends on use case - you may want to use tor not only for anonymity,
but also to just hide your traffic from just your local ISP (public wifi
etc). In that case it's fine to use existing VMs.

But yes, for anonymity new VMs should be used. I think this is already
covered in Whonix documentation.

> 5) i will use this post to state that tor behaves differently to connect in 
> windows tor browser, or linux tor browser, compared to whonix, and i dont 
> know why. Whonix gets always same speed, 250 to 500 Kbps, (not KBps) with 
> speed of 30 to 60 kB/s of downloads, and in tor browser outside whonix, i get 
> 500 to 1 Mb kB/s downloads. Thats really strange and wasn`t expected. I get 
> this behavior for almost 2 years, and i dont have the expertize to know why. 
> after some googling, i saw i am not the only one getting different special 
> routes in tor using whonix.

Strange, I haven't noticed such effect.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJXe3NFAAoJENuP0xzK19csiAMH/1gfCmbwIyfMh4TfvbmWADsE
05rB9xXivGvDRCAddAB08LuycAzZxA4mPggrhlR4aaunbwupDUJGwU0sNBHmLTHy
djpPunx3NRqJCPHQe8p5oqHBLpwGivld+p1mgZnfkl3O1LRzNRCGHG8EB708b+SX
o0gmPdOvXvVdzQeKBMhzENUqgtY2uaGl7FZosP9KJsQdpwdFDrawS26q3RDBppvf
uIj5gl5k9CzSU9nswCsGuW+F6NrJ/3itp2ueRiF8K+RSjUeAXwXEJHgtaICjad46
DNyuM6rWe3rAJQUYf+lf3RXzk10qZ13DTWR4Gf3S+y1y/sAoZAQyhKg/hTdFUwE=
=tuBS
-END PGP SIGNATURE-

-- 
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

[qubes-users] Qubes top priorities suggestions for me as an user.

2016-07-04 Thread jurisdan 
1) qubes is a system for security and isolation. But when you install, you have 
no encryption options.
distros thinks that if a user wants some strong crypto thing, they must 
research themselves and do all manually. We dont even find nothing about qubes 
encryption in docs. That is wrong. First thing we must do out-of-the-box is to 
offer strong full disk encryption, like veracrypt ones, with options, 
iteractions, etc., and inform the user about that. Even tails for just a live 
browser with storage capability does that. Even distros like PARTED MAGIC for 
managing partitions now come with veracrypt installed as default in live-cds. 
To me, Qubes is neglecting what the user wants to read and do in encryption 
aspects.

I usually use mint strong encryption. But even that i must do manually. Imagine 
ALL users trying to do this on their own. They wont. i use appendix A configs 
from links below, much stronger.

https://community.linuxmint.com/tutorial/view/2026 (bios)
https://community.linuxmint.com/tutorial/view/2061 (uefi)

2) Qubes face 2 problems nowadays for engaging new users with real security.

a) Qubes is a system for HIGH END computers with lots of RAM. Usually if for 
people that has WINDOWS and GAMES also, a good GPU, and wont waste their 
machine on a UNIQUE linux system at least without dual boot. 

b) Nvidia spy on people, with their streaming @!^@^% they put in new gpus, 
network, etc, and people are suspicious amd too. But most consumers are from 
nvidia. nvidia now spy on hardware level. Does not matter the system security. 

The solution? REAL windows virtualization with GPU PASSTROUGH. So, the high end 
computers can use windows for what they need and even play games. Plus, if you 
do use nvidia in dom-0, they WILL capture the screen on hardware level. Nouveau 
is not working right for a long time. Onboard or gpu 1 for dom-0 and nvidia or 
amd high end for windows VM. If the person doesnt have 2 monitors, it can 
change the vga adapter from 1 to other to use windows after starting the vm. 
that would be perfect.

So we give a finger to nvidia and the drivers problems they cause, and we 
isolate their spying inside windows vm, plus eliminating the need for a dual 
boot and for everyone not using their gaming gpus.

So, XEN is not good for that? consider passing to KVM.

- To create a real secure isolation OS, it`s primal to ensure best disk 
encryption avaliable, with CHOICE for speed/security, eliminate the windows 
host multi boot needs, and make good use and usability for windows and gpus. 
You will reach that when you direct the efforts to adapting the system for what 
the global user WANTS AND NEEDS, and not adapting the user to the system that 1 
person in 1 chair dream for its personal needs. Ubuntu did not follow this 
lesson with their unity thing and they paid the price. 

3) Consider offering PFSENSE as optional firewall vm installed out of the box. 
It`s very hard and time consuming to do that inside qubes system without 
studying all, for managing internal ip structure etc. It is the most perfect 
firewall for use inside a VM, qubes is a system for VMs, and i did use it even 
inside windows in virtualbox. But i was in WINDOWS, and that means, no real 
security at all.

I would like also to give 2 more suggestions for people to considerate, 
concerning whonix, since patrick is a developer here:

4) People need a pop-up window to explain them to NEVER use an existing normal 
vm trough the whonix proxy vm, just NEW ONES. Because they have already 
fingerprints, identifiers, browser behavior, browser plugins identification, 
aplication updates, specially in windows. If they connect that with once used 
real wan IP, game over for anonymity.

5) i will use this post to state that tor behaves differently to connect in 
windows tor browser, or linux tor browser, compared to whonix, and i dont know 
why. Whonix gets always same speed, 250 to 500 Kbps, (not KBps) with speed of 
30 to 60 kB/s of downloads, and in tor browser outside whonix, i get 500 to 1 
Mb kB/s downloads. Thats really strange and wasn`t expected. I get this 
behavior for almost 2 years, and i dont have the expertize to know why. after 
some googling, i saw i am not the only one getting different special routes in 
tor using whonix.

Sorry for my bad english, is not my main language, i hope people can understand 
what i wrote. And forgive me if i wrote stupid things. 

-- 
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/8efb8d91-de6b-4a6d-b215-65bca333a81f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.