Re: [qubes-users] Installed Qubes on "reasonably" secure, portable and fast USB drive

[Franz]

On Thu, Oct 13, 2016 at 10:34 PM, Manuel Amador (Rudd-O) 
wrote:

> On 10/13/2016 11:36 PM, Toni S wrote:
> > Only annoyance with the stick so far has been that it locks itself
> automatically right after it loses power, and for some reason there is a
> short power break in booting the Qubes, just before the graphical loading
> screen and crypto unlock. Then you just need to unlock the stick again and
> you are good to go.
>
> I don't think that's a power drop.  I think that's the BIOS handing over
> the device to the Linux kernel, which then needs to reboot and
> reinitialize the device to continue reading from it.
>
> I like the self-destruct capability, but what's the benefit of the
> encryption on the drive?  How do you type the password on the device, if
> it isn't LUKS?
>
>
It seems there is a hardware numeric keyboard on the device. Could be
really interesting for travelling.
best
Fran

> --
> Rudd-O
> http://rudd-o.com/
>
> --
> 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/1ebd5bee-dcf6-614a-6f29-88e1a6f06cc4%40rudd-o.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAPzH-qCdntO0Lgob0KYJGRsbsaZw4Xa_W4L369xpznxd4oQXGA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts about installed software

[Jeremy Rand]

Rusty Bird:
> Hi Robert,
> 
>> However I would not use the "move to VM" command like this, as I 
>> experienced those requests getting lost One time files were 
>> actually deleted, since that time I always use copy instead of 
>> move.
> 
> Sounds troubling. Do you remember the last Qubes release version
> where you experienced this kind of data loss?
> 
> Rusty

In Qubes 3.0, I noticed that source files for the "move to VM" command
would be deleted even if the move failed due to insufficient disk space
in the destination VM.  (It goes without saying that this is a Very Bad
Thing.)  I'm not sure if this is still the case in newer releases of Qubes.

Cheers,
-Jeremy

-- 
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/6ba93f84-206a-303e-e608-262b10a79f97%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] ANN: Leakproof Qubes VPN

[Chris Laprise]

On 10/13/2016 09:31 PM, Manuel Amador (Rudd-O) wrote:


Oops about what?  Unlike the official Qubes VPN documentation, which
counsels people to write scripts that make non-atomic modifications to
their firewall, which actually and demonstrably have a leak between
Qubes firewall updates and VPN rules setup, my work doesn't leak traffic
in-between the addition of iptables rules.


The qubes-firewall-user-script is a feature of Qubes firewall. And its 
one of the original Qubes docs that encourage people to use it. So, yes, 
there is a vulnerability in Qubes firewall, and it should be noted 
foremost in the Known Issues for the project.


The VPN use case is probably one of the least-vulnerable examples of 
leakiness in Qubes firewall, because it requires multiple failures to 
line up in a small window. That means non-VPN use cases are probably at 
least as vulnerable. Its the underlying problem which is my overriding 
concern.


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/9f1744c7-7eb1-f240-731c-7ccbd86179b0%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: ReactOS instead of Win7?

[Drew White]

On Thursday, 13 October 2016 23:26:31 UTC+11, gaikokuji...@gmail.com  wrote:
> On Wednesday, October 12, 2016 at 10:12:48 PM UTC-4, Drew White wrote:
> > On Thursday, 13 October 2016 07:48:24 UTC+11, Gaiko Kyofusho  wrote:
> > > I haven't seen much mention of ReactOS on the list but was thinking it 
> > > *might* be worth trying a ReactOS AppVM as an alternative to a MS Windows 
> > > AppVM but before I put myself through the frustration I thought I'd ask 
> > > #1 The wisdom (or not) of the idea and #2 If its been tried already and 
> > > doesn't work yet.
> > > 
> > > Thx
> > 
> > Qubes tools will NOT work. ROS is only 32 bit. It's still only 2003/XP 
> > based.
> > I'm looking at doing something with the Qubes Tools to enable at least 
> > copy/paste/qrexec.
> > 
> > But at this time, it just won't have that option available if you use 
> > ReactOS.
> 
> Thats too bad, it would have been nice to use OSS to run win apps but anyway 
> thanks for the answer! Saved me a bit of frustration trying to make it work.

No problem, I just talked to the ReactOS people to find out.
during the chat, I may have worked out exactly how to get them working though, 
as some of them have patches/cracks to get win7 stuff to work on ROS.
Not always well, but it does work.

On the other hand, I may just write an interpreter for ReactOS to work just 
like the tools normally would. It shouldn't be that hard since the code is 
already available. But who knows. I will probably encounter many issues. But I 
think that it will be beneficial in the end.

At the moment there are other things I'm working on in Qubes to get it to work 
right, you know, bridged networking and all. and I mean completely bridged, not 
just forwarding.
So that's my first priority, then I'll get onto this other thing and see what I 
can pull off, or if it is even possible. It should be possible, and shouldn't 
take too long if it is possible. 

I'll let you know how it goes.

-- 
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/b5a9b2b6-d346-4fcd-a469-80021ea1bb43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking issue with bittorrent client Q3.2

[Manuel Amador (Rudd-O)]

On 10/13/2016 09:56 PM, Desobediente wrote:
> Assuming that Manuel described your case, you would have to set a
> static port, not random, and forward the port in the firewall VM and
> also in every device in the middle of the way (routers, etc.)

That is right.  You want to set a static port on your BT client, even if
you use Qubes network server to give it a static IP.  In that case you
do not have to set a forwarding in any VM, but you may have to use a
wireless router that supports UPNP (for which you need to at the
corresponding firewall rules to the VM that allow UPNP request packets),
and you need to add an allow firewall rule for the port you opened (I
think it's both TCP and UDP these days).

>  
> -- 
> iuri.neocities.org 
> -- 
> 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/CAF0bz4S4DdASCr6Z5kFTDkBOZuscEU0Jy%3DwDLQ1Atrv0EGwPOw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/d9d18f29-8852-9a6f-4fb0-908463162bd9%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installed Qubes on "reasonably" secure, portable and fast USB drive

[Manuel Amador (Rudd-O)]

On 10/13/2016 11:36 PM, Toni S wrote:
> Only annoyance with the stick so far has been that it locks itself 
> automatically right after it loses power, and for some reason there is a 
> short power break in booting the Qubes, just before the graphical loading 
> screen and crypto unlock. Then you just need to unlock the stick again and 
> you are good to go.

I don't think that's a power drop.  I think that's the BIOS handing over
the device to the Linux kernel, which then needs to reboot and
reinitialize the device to continue reading from it.

I like the self-destruct capability, but what's the benefit of the
encryption on the drive?  How do you type the password on the device, if
it isn't LUKS?

-- 
Rudd-O
http://rudd-o.com/

-- 
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/1ebd5bee-dcf6-614a-6f29-88e1a6f06cc4%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: Leakproof Qubes VPN

[Manuel Amador (Rudd-O)]

On 10/14/2016 12:32 AM, Chris Laprise wrote:
> On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote:
> * Interdependent packet marking, detection and routing rules are
> needlessly complex
 FWMARK was the only way to get blackholing to work reliably without
 interference from the Qubes OS firewalling system.
>>> So you added complexity where simply blocking all forwarding to/from
>>> eth0 would have sufficed.
>> Not really.  I implemented the simplest and least-invasive solution I
>> could think of.  It's four directives:
>>
>> 1. Instruct the routing engine to route all packets from downstream VMs
>> to use table 78.  This happens very early during boot, right after the
>> Qubes OS default firewall rules are loaded, and so it happens that VMs
>> cannot leak.
>> 2. Tell table 78 to route all traffic to the VPN if the VPN interface is
>> active, and to blackhole all traffic if the VPN interface goes down.
>> This is actually quite cool, because there's no need to clean up
>> anything if the VPN fails — the routes disappear when the TUN/TAP device
>> goes away, leaving the blackhole route active.
>> 3. Add two firewall rules directing all DNS requests from downstream VMs
>> to the DNS servers of the VPN.
>>
>> I think, in my humble opinion, that this compares /quite favorably/ with
>> (the doc) asking the user to write several scripts, all of which make
>> much more invasive iptables modifications, while still allowing the VPN
>> server to muck with the system routing table, a practice which under
>> some circumstances could cause the ProxyVM itself to use the wrong DNS
>> servers, or to fail to reconnect to the VPN.
>>
>> Additionally, I see that some of the tables that the doc's scripts
>> modify are actually tables that the Qubes firewall may revert to their
>> original state, so it's quite easy for a firewall config change to blow
>> those rules up, leaving the user with a leaky VPN.  Granted, the
>> firewall config change will only last about a half a second, because the
>> user firewall script will be invoked afterwards, but during that
>> half-second, traffic can leak via the eth0 route.  OOPS!
>
> Now that is something interesting. So the Qubes firewall is supposedly
> bad.

Nope.  It's actually pretty good, and it was the inspiration for my
work.  Getting leakproof VPNs is a hard job.  The official documentation
for the firewall is as good as you can get, without hard core networking
work.

> And we can let most users suffer whatever consequences when they block
> traffic with sys-firewall, because only our specific VPN application
> matters??

I don't know what you mean.  "Most users", "suffer", "consequences" when
they "block traffic".  I have zero idea what this means with regards to
my work.  Most users don't actually write shell scripts to do basic
things like VPN.  "Most users" are not even the target of work like VPN
systems.  The target market for such work is users who want provable
privacy.  That is the sort of work that I endeavored to do, and now I
have delivered it.

>
> Keeping in mind that the default policy of FORWARD is DROP, we should
> also consider whether a stream of iptables commands is too slow to be
> secure.

Yes, the document should probably be updated to reflect that.

> And if so, ask why 1) the user firewall rules are in script format;

That isn't the case within Qubes OS.  Qubes OS firewall adds / changes
rules atomically via iptables-restore.

> Or why 2) the commands aren't all combined for an iptables-restore;

They are in Qubes OS.

IF you are critiquing my work again, then I have to say you are
technically correct, as the DNS rules my work adds (during OpenVPN "up")
are not atomically added via iptables-restore.

That fact is not relevant to the promise of leak-proofness that my work
makes.  The only *relevant* rules that get added during VPN connection,
are two DNS rules.  Any DNS packets sent by downstream VMs will be
blackholed in the meantime, so, well, leakproof like I said from the
beginning.  It's okay to flush the specific routing table for DNS that
my program creates, and then to add rules non-atomically, as DNS packets
coming in between the flush and the rules will get dropped and not
routed anywhere useful.

If you look closely at my work — this is not an accident, but a
deliberate outcome of my study of the problem — during OpenVPN "up", the
DNS rules are added before the routes are added, which has the side
effect of DNS packets being routed nowhere until the routes are added. 
So non-atomic modifications to the firewall are fine in this case.  It's
all in the `qubes-vpn-interface-control.in` script for anyone to see.

You are welcome to verify these claims with tcpdump (I did it too).

You are also welcome to send pull requests to make the rule addition atomic.

> Or why 3) the chains aren't started with a temporary REJECT while they
> are being populated. ANY. ONE. Of these will address the issue for
> VPNs and all the other use 

Re: [qubes-users] ANN: Leakproof Qubes VPN

[Chris Laprise]

On 10/13/2016 11:39 AM, Manuel Amador (Rudd-O) wrote:

* Interdependent packet marking, detection and routing rules are
needlessly complex

FWMARK was the only way to get blackholing to work reliably without
interference from the Qubes OS firewalling system.

So you added complexity where simply blocking all forwarding to/from
eth0 would have sufficed.

Not really.  I implemented the simplest and least-invasive solution I
could think of.  It's four directives:

1. Instruct the routing engine to route all packets from downstream VMs
to use table 78.  This happens very early during boot, right after the
Qubes OS default firewall rules are loaded, and so it happens that VMs
cannot leak.
2. Tell table 78 to route all traffic to the VPN if the VPN interface is
active, and to blackhole all traffic if the VPN interface goes down.
This is actually quite cool, because there's no need to clean up
anything if the VPN fails — the routes disappear when the TUN/TAP device
goes away, leaving the blackhole route active.
3. Add two firewall rules directing all DNS requests from downstream VMs
to the DNS servers of the VPN.

I think, in my humble opinion, that this compares /quite favorably/ with
(the doc) asking the user to write several scripts, all of which make
much more invasive iptables modifications, while still allowing the VPN
server to muck with the system routing table, a practice which under
some circumstances could cause the ProxyVM itself to use the wrong DNS
servers, or to fail to reconnect to the VPN.

Additionally, I see that some of the tables that the doc's scripts
modify are actually tables that the Qubes firewall may revert to their
original state, so it's quite easy for a firewall config change to blow
those rules up, leaving the user with a leaky VPN.  Granted, the
firewall config change will only last about a half a second, because the
user firewall script will be invoked afterwards, but during that
half-second, traffic can leak via the eth0 route.  OOPS!


Now that is something interesting. So the Qubes firewall is supposedly 
bad. And we can let most users suffer whatever consequences when they 
block traffic with sys-firewall, because only our specific VPN 
application matters??


Keeping in mind that the default policy of FORWARD is DROP, we should 
also consider whether a stream of iptables commands is too slow to be 
secure. And if so, ask why 1) the user firewall rules are in script 
format; Or why 2) the commands aren't all combined for an 
iptables-restore; Or why 3) the chains aren't started with a temporary 
REJECT while they are being populated. ANY. ONE. Of these will address 
the issue for VPNs and all the other use cases.


'OOPS!'

Here is bog-standard advice for properly handling firewall rules in Fedora:

https://fedoraproject.org/wiki/How_to_edit_iptables_rules

Or how about:
$ cat internal-qubes-rules qubes-user-rules iptables-commit-cmd | 
iptables-restore



At this point, we all need to know if Qubes firewall will be fixed in a 
timely fashion. I am wondering what the heck "reasonably secure OS" is 
supposed to mean in this context.



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/95b5e003-c4a9-ae0b-823c-70d276c7a69d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking issue with bittorrent client Q3.2

[Desobediente]

Assuming that Manuel described your case, you would have to set a static
port, not random, and forward the port in the firewall VM and also in every
device in the middle of the way (routers, etc.)

-- 
iuri.neocities.org

-- 
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/CAF0bz4S4DdASCr6Z5kFTDkBOZuscEU0Jy%3DwDLQ1Atrv0EGwPOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] QR32 & Mulitasking?

[702357045704574579]

Hello,

I install Win7 inside a HVM.

$ top 

load 0.15
4028848 KiB used
55784 KiB free
no swaping
298 tasks

So it looks normal, I think.

Kind Regards

-- 
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/19c10608-6bcb-422f-b9b0-acc940837848%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Installing Windows 7 freeze Qubes dom0

[98164891748916498146891]

Hello,

I had also strange broken screens, now I try to run the Win7 installation 
process alone and don't have other apps running.

But it seems very slow to me and something with the multitasking is quite odd.

Kind Regards

-- 
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/be1010da-3631-42e7-91dc-45e90fcedcb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Error converting vmdk disk to raw

[justinrcopeland]

I'm having same issue, I know there is enough space because df -h shows 198G 
available and qemu-img-xen info image.vmdk shows that the virtual disk size is 
8G


On Wednesday, April 27, 2016 at 6:39:18 AM UTC-5, TheGrandQubes wrote:
> How do you know there is enough space? 
> 
> 
> If the vmdk file is 30 GB, but the disk is configured as a 250GB disk in 
> VirtualBox/VMWare, you need at least 250GB of free space to do the conversion.
> 
> 
> Could this be the case for you?
> 
> 
> After I did the conversion, the rwa file "size" was 250GB and the "size on 
> disk" 30 GB! 
> 
> 
>  
> 
> 
> On Saturday, 30 January 2016 00:37:58 UTC, Adrian Rocha  wrote:
> Hi people,
> 
> 
> I'm trying to convert a virtualbox disk to Xen raw format, but I'm having an 
> error:
> 
> 
> 
> [user@dom0 ~]$ qemu-img-xen convert -O raw RI_IP2-disk1.vmdk RI_IP2-disk1.raw
> qemu-img: error while writing
> [user@dom0 ~]$ qemu-img-xen convert -f vmdk -O raw RI_IP2-disk1.vmdk 
> RI_IP2-disk1.raw
> qemu-img: error while writing
> 
> 
> ll
> -rw-r--r-- 1 user user 31739346944 ene 29 18:28 RI_IP2-disk1.raw
> -rw-rw-r-- 1 user user 31739346944 ene 29 18:27 RI_IP2-disk1.vmdk
> 
> 
> The process fails selecting other formats too:
> 
> 
> [user@dom0 ~]$ qemu-img-xen convert -f vmdk -O qcow2 RI_IP2-disk1.vmdk 
> RI_IP2-disk1.raw
> qemu-img: error while writing
> 
> 
> I have enough space in the file system to write the file
> 
> 
> Any ideas about this issue?
> 
> 
> Regards

-- 
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/4f249285-bdb2-412e-88d9-97f6c7d8a1e9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Why is whonix-ws necessary?

[9174710470470470470]

Hello,

If you don't need it, you can choose under software in the installation if you 
install whonix - or not. So it is totally up to you.

Someone might or might not use whonix also as a command and control server, so 
I by myself disabled it.

Kind Regards

-- 
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/86cc924b-b8e9-42f7-a6d2-0056ee2690ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Anonymize MAC address

[pl11ty]

Good day
When I go to options of my wifi network (always spoofed the MAC address),
in the field "device" there is written my real MAC. Has been detected by
network?

Another question, always in the field "device" there are 2 options: mac
address and wlp0s0+mac address. What do I have to select? (I haven't
ethernet network, then I have activated only macspoof-wlp0s0)

pL11


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

[qubes-users] QR32 WinVM - tooks very long..

[094094709q709qwe709q7we0q7wer9]

Hello,

is this normal, that the installation of Win7 into a HVM takes hours?

top:
load.average 0.16

I don't run any in parallel, because I have seen also 2 times a window 
bluescreens, which aborts my Win7 installation...

Kind Regards

-- 
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/cea91c80-f177-4275-8e1b-1e373d50cfc9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts about installed software

[097403710470970q970q97w89]

Template VM Hierachy?

Was still some topic (and would meet the user logic to design more foundation 
TVM's and higher specific TVM's on top of them)...

https://groups.google.com/forum/#!searchin/qubes-users/vm$20hierachy%7Csort:relevance/qubes-users/iLJjTTQqgrw/-0OG1jrZPgAJ

-- 
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/9d6a4088-c81c-455f-a610-ae9c7647110f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts about installed software

[193840242421424214249]

Hello,

how I found out, if the minimal Templates D8 or F22 will contain only "exploit 
proof" applications, which support all ASLR - against code injection - like the 
browsers?

Or if not, how can I build an ASLR D8 template for Qubes?

Kind Regards

-- 
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/f29d890a-6d35-4388-a535-c7dd45e2a245%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts about installed software

[094142174178942479]

Hello,

sounds quite interessting :-)

How would be a encrypted software-database. Inside are all compressed folders, 
pathes and files and if you run some app, it will payed in this DVMs?

Nice would be, if the protocols and logs get played back inside this database. 
And they are also compressed and enrypted.

In the end you have an database, which maintain all the running coding, 
configurations and security-logs (So AppArmor can be used to see the good or 
bad behaviors).

Kind Regards

-- 
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/200f40ab-d468-4257-9643-6bd5d048698c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Win7VM - Audio via Bluethooth USB Stick?

[70240424242409409999970]

Hello,

as far I know, the Win7-VM will today not support the sound features.

Would it be possible to use a USB-Bluethooth device (e.g. Blue Fritz), which is 
paired with some bluetooth sound-box and play the sound in this way?

This would be great!

Kind Regards

-- 
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/9de3a865-dd07-4565-a99e-ecc4a756fa5b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-10-13 03:45, Robert Mittendorf wrote:
> Am 10/13/2016 um 04:50 AM schrieb raahe...@gmail.com:
>>
>> feature.  I use to make menu shortcuts to launch programs in dispvms 
>> inheriting firewall rules.  But xfce only lets you edit already existing 
>> rules,  not create new ones :(   editing a config file is a little too much 
>> effort for me lol.
>>
> You can edit the rules in Xfce-Dom0 via the Qubes VM Manager?!
> 
> How can this "feature" be disabled? I want to start a normal DispVM, not a 
> "special" DispVM.
> 
> Use Case: Mail VM is only allowed to access Mail-Server. I want to start a 
> Browser in DispVM for urls in Mails.
> This works fine, but those "special" DispVMs have the same limitations. I 
> want just a normal DispVM like the one started via Dom0. The only way to 
> achieve this afaik is to let the special DispVM connect to NetVM, so no 
> ProxyVM is used. But this means that the DispVM has access to the 
> intranet.
> 

This is precisely the use case I described in issue #1296, which I linked in my 
previous message:

https://github.com/QubesOS/qubes-issues/issues/1296

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

iQIcBAEBCgAGBQJX/9QlAAoJENtN07w5UDAweRkP/0uhxA8ARtTJuYuroi0znFNb
gXb/LRC0rCy9F1TdiwXAhj7kHMSx+HObeXCqTGFlvCYl6sJGkTW0GWulN2M6XtCj
KLHQ+vS6YpMTB4EYrDu2QBVlMuFoZoNuj+O/XVcup3aK1MUvpeJJwX6VzCc/X2Y4
NHYthK8PtbPZ8WHEdsdAYWBrKWw14ewtaQY9bIsx4SBjf/iq0sr/vGeWOR6Trok1
0SCYo0UBgWKKDPCUeRFUKPSrL/ZCPzeF5fC+F4oG+LZE5xHM5Vu8++U5D9lCuOoS
pfqfWI9zKib4WTjwv+tQth5G3khM+W9vfmLJfkwuO6bIGO2B59gKSwwh/DCcTH0q
jPUgGv7dn4Ypobh15YKxynvilYMNXBLoN5nst/3ZWh2tGMwsJ9Qicc7LRg5lUpWq
Gm+V27OEmwf40G3ejFKXr937Jc3j+GjiBAMN3hhTbfb9FkMjTS5HJqVl0rpTOX7V
p6YW+JfdtiRGEPhiCY/24ld0p//TIyL72Ry5mT4naSP2mJyViFt3cZr91Uvcr4/p
5BltNOzPvpGvlR+S1CM8Kn3LcV9GZb1uKdHBGRfAVA0Y6Ikh8t8N/i1h28e0gSdr
02Wf9tssdixLIJL5kNQDew36kwqcW79c28qJTsfv60EM+nYHFfhrPSoZyyzrT4ty
Jv8Ojecj2huxgn9KS0ln
=uR2N
-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/d649c65f-b049-f544-6d3f-709bb0936176%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Bug or Feature? DispVM inherits settings from calling VM

[David Hobach]

On 10/13/2016 12:45 PM, Robert Mittendorf wrote:

Am 10/13/2016 um 04:50 AM schrieb raahe...@gmail.com:


feature.  I use to make menu shortcuts to launch programs in dispvms
inheriting firewall rules.  But xfce only lets you edit already
existing rules,  not create new ones :(   editing a config file is a
little too much effort for me lol.


You can edit the rules in Xfce-Dom0 via the Qubes VM Manager?!

How can this "feature" be disabled? I want to start a normal DispVM, not
a "special" DispVM.


Of course it's a feature. You want to open those pesky attachments of 
your mail VM in a dispVM, don't you? But do you want to grant that VM 
internet access? At least I wouldn't want that and thus would expect 
that those firewall rules are inherited.



Use Case: Mail VM is only allowed to access Mail-Server. I want to start
a Browser in DispVM for urls in Mails.
This works fine, but those "special" DispVMs have the same limitations.
I want just a normal DispVM like the one started via Dom0. The only way
to achieve this afaik is to let the special DispVM connect to NetVM, so
no ProxyVM is used. But this means that the DispVM has access to the
intranet.



Currently your easiest option is not to click on the links, but to 
copy-paste them to an open dispVM. Small sacrifice for a major security 
gain.


--
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/a906460e-0754-3b34-ca6e-232d3252ef34%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] ANN: Leakproof Qubes VPN

[Manuel Amador (Rudd-O)]

On 10/13/2016 02:14 PM, Chris Laprise wrote:
>
> So this is dependent on OpenVPN's features, again.

Yes, I make no secret of the fact that my software depends on OpenVPN. 
I accept contributions to make it work with other VPN solutions.

>
> And is forcing your routing schema on an unknown VPN topology wise?

I don't know what you mean by "forcing" or "my schema" or "wise".  I
know that my program creates a private routing table for the VPN, so the
system routing table is not affected.  This is less unsafe than, for
example, what NetworkManager VPN does — which alters your system routing
table.

>
> Routing tables should be irrelevant to whether non-VPN traffic is
> blocked by a proxyVM.

This is a nice opinion, and you are entitled to it.  However, it turns
out that using a blackhole routing rule is quite effective at blocking
any and all non-VPN traffic.

> A VPN server should be able to push down whichever routes it sees fit,
> without any risk of leakage even if those rules are malicious... or
> simply a configuration you can't anticipate.

Oh, that's true.  And Qubes-VPN supports that.  Because it uses a
separate routing table, the system's operation is not affected even if
the VPN server sends malicious or nonsensical routes.

>
> Making the solution dependent on routing tables just makes the
> security *and* the operation more precarious.

While Qubes VPN does not depend solely on routing tables, I would like
to see you prove these allegations.  This allegation of yours sounds
like something you can prove by reasoning or by example.  Why not do it?

Let's also get one thing out of the way here, because what you're saying
here is borderline FUD.

ALL VPN solutions depend upon routing tables.

There are no VPNs that do not use routing tables on the client to direct
traffic.

Qubes VPN merely uses a *separate* routing table, not the system routing
table (table #0).

So when you say that "making the solution dependent on routing tables"
is somehow bad, you're attacking *all* VPN software.

>
>>
>>> * Interdependent packet marking, detection and routing rules are
>>> needlessly complex
>> FWMARK was the only way to get blackholing to work reliably without
>> interference from the Qubes OS firewalling system.
>
> So you added complexity where simply blocking all forwarding to/from
> eth0 would have sufficed.

Not really.  I implemented the simplest and least-invasive solution I
could think of.  It's four directives:

1. Instruct the routing engine to route all packets from downstream VMs
to use table 78.  This happens very early during boot, right after the
Qubes OS default firewall rules are loaded, and so it happens that VMs
cannot leak.
2. Tell table 78 to route all traffic to the VPN if the VPN interface is
active, and to blackhole all traffic if the VPN interface goes down. 
This is actually quite cool, because there's no need to clean up
anything if the VPN fails — the routes disappear when the TUN/TAP device
goes away, leaving the blackhole route active.
3. Add two firewall rules directing all DNS requests from downstream VMs
to the DNS servers of the VPN.

I think, in my humble opinion, that this compares /quite favorably/ with
(the doc) asking the user to write several scripts, all of which make
much more invasive iptables modifications, while still allowing the VPN
server to muck with the system routing table, a practice which under
some circumstances could cause the ProxyVM itself to use the wrong DNS
servers, or to fail to reconnect to the VPN.

Additionally, I see that some of the tables that the doc's scripts
modify are actually tables that the Qubes firewall may revert to their
original state, so it's quite easy for a firewall config change to blow
those rules up, leaving the user with a leaky VPN.  Granted, the
firewall config change will only last about a half a second, because the
user firewall script will be invoked afterwards, but during that
half-second, traffic can leak via the eth0 route.  OOPS!

>
>>> * Hardly a model for 'fail closed':

I forgot to mention that the software I wrote is 100% fail-closed.  If
the VPN fails, traffic from VMs will always be blackholed.  There's no
way that this rule can be altered by VMs or the VPN itself.

>>> Instead of being steady-state,

The steady fail-safe state is established very early on boot by the
qubes-vpn-forwarding.service unit file.  That steady fail-safe state —
represented by the blackhole rule in table 78 and the firewall rule
routing downstream traffic to table 78 —  is never removed during any
state transition.

>>> blocking is dependent on state transitions in fw/routes (even worse,
>>> ones that are initiated by OpenVPN events). Blocking should not
>>> require active measures initiated by client software.
>> Check the code again.  Blocking happens way before VPN and Qubes
>> Firewall starts.  If there's a failure in the VPN, even if the
>> re-blackholing fails, no   traffic from the VMs will be routed, simply
>> because 

Re: [qubes-users] Re: Google Maps producing a very high CPU usage

[Desobediente]

Google Maps is like that everywhere else

I guess maybe it's just the fact that Qubes Manager allow you to see easily
how much they are ripping the memory and the processor that made you
realize this

-- 
iuri.neocities.org

-- 
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/CAF0bz4T9GwNk4Q_N%2BBt8CDw9wBnbhpE6VhEkCGPi9EKcGtP7yQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] SMB mount point location

[John Maher]

On Wednesday, October 12, 2016 at 12:06:15 PM UTC-4, Manuel Amador (Rudd-O) 
wrote:

> Do your files show on the file manager?

Manuel, thank you for responding. Yes, they do. So, there is no way to access 
the files through the connection created by the file manager?

-- 
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/3a3ff2dd-47ca-45d0-9ae3-26ad5aabf33c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ANN: Leakproof Qubes VPN

[Chris Laprise]

On 10/13/2016 01:08 AM, Manuel Amador (Rudd-O) wrote:

On 10/13/2016 03:13 AM, Chris Laprise wrote:

Here is a rundown of initial concerns...

* Routing tables should not be manipulated when VPN clients will
surely do this as well

The program prohibits OpenVPN from manipulating routing tables.


So this is dependent on OpenVPN's features, again.

And is forcing your routing schema on an unknown VPN topology wise?




* Unknown side-effects with different VPN topologies (i.e. atypical
routing commands pushed down to the VPN client)

Almost no routing instructions are obeyed.  Those which are obeyed, are
applied to routing table 78, which prevents malicious server
manipulation of ProxyVM routing tables.


Routing tables should be irrelevant to whether non-VPN traffic is 
blocked by a proxyVM. A VPN server should be able to push down whichever 
routes it sees fit, without any risk of leakage even if those rules are 
malicious... or simply a configuration you can't anticipate.


Making the solution dependent on routing tables just makes the security 
*and* the operation more precarious.





* Interdependent packet marking, detection and routing rules are
needlessly complex

FWMARK was the only way to get blackholing to work reliably without
interference from the Qubes OS firewalling system.


So you added complexity where simply blocking all forwarding to/from 
eth0 would have sufficed.



* Hardly a model for 'fail closed': Instead of being steady-state,
blocking is dependent on state transitions in fw/routes (even worse,
ones that are initiated by OpenVPN events). Blocking should not
require active measures initiated by client software.

Check the code again.  Blocking happens way before VPN and Qubes
Firewall starts.  If there's a failure in the VPN, even if the
re-blackholing fails, no   traffic from the VMs will be routed, simply
because everything is FWMARKed to go to routing table 78, which is dead
by the time VPN fails.


I can see the code where 'up' and 'down' are reconfiguring both iptables 
and routing tables. That is using OpenVPN events to shift between 
states, one of which is the so-called "blackhole" mode... which looks 
more like the makings for a zombie process.


OTOH, its possible that Qubes proxyVMs might leak packets before Qubes 
firewall starts, as you claim. That has implications for *most* use 
cases involving proxyVMs. Did you think to test that and submit an issue?





* Specific to Fedora template and hard-coded for OpenVPN

Yes, this is specific to Fedora and hard-coded for OpenVPN.  OpenVPN is
the standard

...is presumptuous.


* Not /rw based; Adds more services to template

Partially true.  Config goes in /rw as it should.  Services are optional
and need to be specifically enabled.


They need to be enabled, but they are still there. That does negatively 
affect security from the Qubes perspective; Why should we have even more 
privileged code laying around in multiple VMs just because one of them 
uses a VPN?



Frankly, much better than an instruction manual, or putting all of the
stuff in /rw/config/firewall stuff, because it being a package, it can
be updated regularly, given a repo containing the packages.


Yes, you were suggesting that people incorporate your repo, while 
pretending the Qubes-approved solution didn't exist.




* Not tested with Whonix/Tor

True.  Then again, Whonix has its own "VPN" solution called TOR.


Oh, OK.


* Uncommented code


There are a few comments now.  Surely not enough to satisfy your
standards, but I welcome pull requests.


* A full throttle busy-wait loop in 'qubes-vpn-forwarding.in'

Please point out the line of code where that happens.  I don't think I
have done that.


Its the /only/ loop in that script ...and boy is it ugly. :)




* Marketing hyperbole like "leak-proof" should be replaced with terms
like "anti-leak"

If you think it's possible to have this VPN leak, then prove you can
cause a leak, and — if you succeed — I will plug the leak.


Why move the goalposts? You explain why the existing solution, which is 
very unlike your complex set of rules, is insufficient *other* than not 
being packaged.





* Critique of existing solution stops at 'No packaging'[1]; Oddly,
nothing pertaining to anti-leak abili

Sorry, gotta go to bed.  I have a suggestion: I think we will
collaborate better w.r.t bringing a standardized leak-proof solution to
Qubes, if we approach the issue in a non-confrontational and
collaborative way.  I'm happy to have criticisms because they tend to
improve the software, but I fail to see valid criticisms here, which
makes me feel like you jumped to critiquing without trying what you were
critiquing.  Let's get some more solid criticisms based on facts and not
on opinions or hunches.


Lets "collaborate"? How disingenuous...

We already have a Qubes-approved solution that is considered secure. You 
did not seek to package, improve, criticize or even /acknowledge/ it 
before you started suggesting 

Re: [qubes-users] How to solve ProxyVM (sys-firewall) becomming non-functional at runtime

[Manuel Amador (Rudd-O)]

On 10/11/2016 09:42 AM, Robert Mittendorf wrote:
> Hey folks,
>
> sometimes the sys-firewall (more likely a service within it) crashes
> and does no longer allow connected VMs to resolve DNS.
> The ProxyVM must be the responsible entity, because the connection
> will be fine again If I restart the sys-firewall.

You're onto it.  I think I fixed this yesterday:

https://github.com/QubesOS/qubes-core-agent-linux/pull/20
>


-- 
Rudd-O
http://rudd-o.com/

-- 
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/ce32fd1c-6f16-d434-d80a-4dca00c387ba%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Networking issue with bittorrent client Q3.2

[Manuel Amador (Rudd-O)]

On 10/11/2016 11:18 PM, yorp wrote:
> For some reason using a bittorrent client in an AppVM will not connect to 
> internet. 

It's usually the case that they listen to ports locally and expect
remote ends to connect to those ports, which they open using UPNP.  UPNP
firewall port opening is not supported in Qubes.

Try setting a static_ip on your AppVM after deploying Qubes network
server https://github.com/Rudd-O/qubes-network-server — of course, you
still need to allow inbound traffic to the VM using the standard
firewall rules.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/1cd2b199-87f6-f84e-87fe-0bcbf27a8c66%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] USB over IP (Network Gateway)

[Manuel Amador (Rudd-O)]

On 10/13/2016 12:16 AM, equi...@icloud.com wrote:
> Very interested to know if any reason why a USB network gateway software 
> would not work in Qubes? 
>
> For anyone interested, a USB network gateway provides USB functionality to a 
> client over IP. USB network gate by Eltima has Linux, Windows, Mac OS X  and 
> android client applications 
> (http://www.eltima.com/products/usb-over-ip-linux/). 
>
> I want to make the switch to Qubes. I have a VPS (Mac Pro) that I will access 
> through a client (e.g. RDP) on Qubes laptop. I need to be able to sync & 
> backup my iPod touch remotely. 
>
> Any ideas as to whether this will work? Anyone interested in checking it out 
> please post feedback. 

The USBIP client ought to work fine on any AppVM.  It's just hard to set
up.  And, of course, it sends plaintext USB URB packets over the
network, which isn't very good for security, but you could technically
wrap that over an SSH tunnel, or a curvetls
(https://github.com/Rudd-O/curvetls) tunnel.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/39d26f9d-b1d1-00c9-bce5-d0f9e828ddfa%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Thoughts about installed software

[Manuel Amador (Rudd-O)]

On 10/13/2016 12:31 AM, Drew White wrote:
> On Thursday, 13 October 2016 00:39:04 UTC+11, Manuel Amador (Rudd-O)  wrote:
>> On 10/12/2016 05:25 AM, Drew White wrote:
>>> So what do those packages require as dependancies though? 
>>> The dependancies are also required for full integration.
>>> Just saying, there is more than just "qubes-*" to be thinking about.
>> Are you trolling me with this question?  Installing those qubes* packages:
>>
>> * automatically shows you the dependencies on screen
>> * automatically installs the dependencies
>>
>> The recursive dependency information is trivial to discover.
>
> Yes it does, but what else does it need that I have installed that it won't 
> tell me BECAUSE the things are ALREADY INSTALLED?

Like I said, trivial to discover.  Literally first answer on Google:

https://stackoverflow.com/questions/16843928/is-there-any-way-to-retrieve-a-dependency-tree-from-yum

# repoquery --requires --recursive --resolve  

Wow, such hard, many work.

-- 
Rudd-O
http://rudd-o.com/

-- 
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/14625d5f-3168-efa6-993b-ba46b843ebc1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to send wake on lan from qubes?

[Manuel Amador (Rudd-O)]

On 10/13/2016 12:28 PM, galt...@gmail.com wrote:
> I'm trying to remotely wake a computer from qubes with these commands:
>
> sudo ether-wake -b MAC
> sudo ether-wake MAC

These commands only work from a NetVM by default because they require
knowledge of the target machine's MAC address, and that is only
available in the NetVM.

You may want to try Qubes network server which lets your AppVM do ARP on
the LAN.


-- 
Rudd-O
http://rudd-o.com/

-- 
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/4e2c2a16-0c88-9a07-2b0c-ad53ae8106b5%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Google Maps producing a very high CPU usage

[kototamo]

I found a solution by disabling WebGL. There were errors in the console 
indicating that the operation executed by the page are slow.

It is possible to set webgl.disable to true in about:config.

Now it's acceptably slow :)

-- 
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/6d132bd8-03d4-4718-92e6-4d15e9c88cf3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Google Maps producing a very high CPU usage

[pixel fairy]

On Thursday, October 13, 2016 at 4:36:28 AM UTC-4, koto...@gmail.com wrote:
> Hello,
> 
> I have consistently issues when accessing Google Maps from a DispVM (or VM) 
> with Firefox: the site becomes unresponsive or extremely slow and the CPU 
> usage is between 70 and 99%.
> 
> Do other users have a similar experience?

just tried. it was slower in the dvm, but cpu load was consistent. high when it 
was slow, low when it was fast or idle. 

i use chrome in other vms, and that was faster except for refreshes when 
firefox was faster. 

my laptop is a 2010 model maxed out at 8 gigs of ram with 12 vms running, so 
vim is the only app that runs fast on it.

-- 
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/22d35119-e350-4440-b4d1-0a6a26a39524%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Upgraded to 3.2 - now my desktop is wrong

[galthop]

On Wednesday, 12 October 2016 08:56:33 UTC+1, gal...@gmail.com  wrote:
> I upgraded to 3.2 by backing up in 3.1 and restoring in 3.2. I was using xfce 
> in 3.1 and had 4 workspaces (or activities) and each had its own background 
> image and I had different icons placed on each one. Now in 3.2 there are 4 
> workspaces but no icons and the same background. If I add an icon it gets 
> added to all four workspaces.
> 
> Also, under the system tools menu is a menu item for every shortcut in every 
> VM. For example Systemm Tools->work: Files
> 
> Other than this, everything seems to work as before and I cant see anything 
> new.
> 
> I've done the install and restore twice and it was the same both times. 
> 
> Have I done something wrong in the restore? Should I go back to 3.1?

I backed up and restored dom0 as well as my templates and VMs.

-- 
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/60e391b5-8102-4e1f-8da1-bdb7577e7d21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Problems while installing Qubes-OS 3.2 on Sony Vaio Z: no hard drive encryption possible, Setup fails

[Hanno 'Rince' Wagner]

Hi,

a friend recommended QubesOS to me and I thought I'd try the latest 
version of it. I'd like to share my experience and ask for help; I'll 
have a summary of my questions at the end of the mail.


I like the idea, but I had some Problems:

right now, for testing purposes, I installed it on a USB Stick (HyperX 
Savagge HXS3, USB3.0) which I put into the usb3-slot of my laptop. The 
installation medium was a "normal" USB stick on the other usb-slot. 
everything fine there. Install-Boot and testing of the install-USB-stick 
went fine.


The installation itself took it's time (~3.5 hours) but that's ok. at 
first, I wanted hard drive encryption, but when I rebooted this 
installation, the kernel wasn't able to ask me for a passphrase to 
decrypt the USB-Stick (it bootet the kernel, but then it waited at a 
time, so I was stuck at that point). It didn't boot properly.


without usb drive encryption, the setup process worked fine after the 
reboot until a specific point. I used only default parameter (so, no 
default networking through tor). It configured the Default VMs but then 
stopped with the following:


[‚/usr/bin/service‘, ‚qubes-netvm‘, ‚start‘] failed:
stdout: “”
stderr: “Redirecting to /bin/ssystemctl start qubes-netvm.service
Job for qubes-netvm.service failed because the control process exited 
with
error code. See “systemctl status qubes-netvm.service” and “journalctl 
–xe” for details.

“

my laptop never had network access while installing the system, so I am 
not sure wether this is related.


then I decided the installation is done and it started up. I created a 
user during the Installation, so I logged in. This worked, but I haven't 
had no menu bar or something similar, at first only the VM-Manager.
Is this normal? In the screenshots I see at the bottom a menu bar with 
more Information and I am missing this bar.


also, my laptop has one internal and one external ethernet adapter, one 
Wifi-Adapter and one UMTS/LTE-Adapter. Apparently, right now I can only 
see one internal adapter, but after a reboot I wasn't able to use the 
Network at all from dom0; is this correct? I wanted to install htop to 
see what my machine is doing.
which brings me to my final point: I have a fast machine with 8 cores 
and 8GB RAM. But even without having much to do, dom0 shows a Load of 
8-10, mostly doing something with pulseaudio. I can show a screenshot if 
someone wants to see this.



My questions are:
- how can I enable hard drive encryption for that machine? can I enable 
it later and not while Installation? maybe this works...
- why does the setup after the first reboot fail; is there a way to 
debug what is going wrong there?
- how can I finish the setup? I fear that some steps are missing for 
really using QubesOS then.


I have no problem in reinstalling the system, so if you have suggestions 
what I can do, please tell me.



best regards,

Hanno

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