date:20161015

Ok i probobly figure it out how to do this.Install pfsense as HVM configure and 
then in qubes managment change HVM to proxy VM.But i dont know how to do 
this... maybe create proxyVM as name pfsense then delete in directory via 
terminal and copy HVM on the same name so qubes will see it as a proxyVM.I dont 
know but it may work.

-- 
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/098874ce-eec9-4524-80d8-5f0f239c8489%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-10-15 Thread QubesOS User

You mentioned some good points about QubesOS. One thing I definitely dislike 
about QubesOS (and that's no offense of course - it's simply unavoidable, and 
of course that's not the developers' fault - in contrast I couldn't imagine how 
they could optimize it even more [maybe one could do so as a user by switching 
from Fedora to a distro template which needs very few ressources despite having 
to run multiple VMs]) is that it consumes a really huge amount of CPU and 
memory, even on modern hardware.

Well, another approach for isolation (not in the way by VMs employed on any 
Linux distro, it's a totally different approach) is GNU Hurd, but it's still 
experimental and only works on QEMU as far as I know (didn't follow it for 
quite a while). However, those guys are really enthusiastic as well and maybe 
that could be another promising approach someday.


Yes, if the NSA etc. really wouldn't be able to break into your QubesOS system, 
then they'll certainly have plenty of other means to gain access to your data 
(refer to the NSA-ANT catalogue, papers about key strokes and radio sginal 
interception etc.).

No, I don't agree to your last paragraph. Any well-configured Linux distro plus 
a good firewall (pfsense etc.) / router (like Turris Omnia) will prevent any 
(super professional) hacker from breaking into your system, if you set up 
everything in the best possible way AND choose the right (open-source) hardware.


Kind regards and all the best


16.10.2016, 03:47, "raahe...@gmail.com" :
> On Saturday, October 15, 2016 at 9:16:52 PM UTC-4, QubesOS User wrote:
>>  16.10.2016, 01:03, "raahe...@gmail.com" :
>>  > On Saturday, October 15, 2016 at 5:09:46 PM UTC-4, QubesOS User wrote:
>>  >>  Hello everyone,
>>  >>
>>  >>  I could imagine that this question has been discussed before already, 
>> and if this should be the case, then I'm very sorry for posting this (I'd be 
>> thankful for an according link if so though).
>>  >>
>>  >>  I think that I've gained quite much knowledge about possible attack 
>> surfaces provided on hardware and software level during the last 15 years, 
>> trying to keep up-to-date and often doing research on new approaches in this 
>> field. First of all, I'd like to stress that the 'objection' (which I don't 
>> mean as such) I may raise by this post does not have any intention of 
>> criticizing the great work and effort done by the QubesOS developers and the 
>> community (it's not meant as an unhelpful 'critique' at all). Much rather I 
>> have a huge respect for the commitment shown by everyone involved in the 
>> development of QubesOS.
>>  >>
>>  >>  Having compared various approaches in this field (e. g. OpenBSD, Linux 
>> using a hardened security kernel, GNU Hurd), I'd basically come to the 
>> conclusion that QubesOS is the most promising approach, especially if VT-d 
>> isolation is available.
>>  >>
>>  >>  However, the main points I'd like to address are:
>>  >>
>>  >>  1) XEN is developed by people working for a company based in the U.S. 
>> (I know the difference between open-source and proprietary software, but 
>> still they belong to the same team/company). If even developers of TrueCrypt 
>> received one of those 'blue letters' - What is the reason to assume that the 
>> XEN developers didn't receive one of those as well? Seen from the 
>> perspective of the NSA it looks totally odd and irrational to me if they 
>> would not to so, since they can do so, and it's their task to thwart any 
>> efforts which might hinder them from collecting data. I don't regard those 
>> people as being 'evil' or anything like that (nor do I regard this as being 
>> positive, which should go without saying), I just look at things in a 
>> rational way: If QubesOS is a great approach to ensure security, then one 
>> must be naive to assume that this won't automatically lead to classifiying 
>> this as a 'high priority target' - With all the consequences.
>>  >>
>>  >>  1.2) Since this looks so obvious to me: Why isn't it a top priority for 
>> QubesOS developers to make use of a supervisor (or develop an independent 
>> one, which would surely need endless efforts, but wouldn't it be worth it?), 
>> which is not subjected to the objections I tried to express?
>>  >>
>>  >>  2) QubesOS totally relies on 2.1) trusting XEN developers to completely 
>> understand the more than just complex x64 architecture being used today and 
>> 2.2) on trusting Intel's VT technology.
>>  >>  Regarding 2.2): Just assuming Intel would have received some kind of 
>> 'advice' (they may even find motivation without getting such - I certainly 
>> don't think that Intel is an 'NSA subcontractor', but they are simply a big 
>> and profit-orientated company, not an idealistic open-source community like 
>> the QubesOS developers etc.) - Then how realistic is it that an absolutely 
>> professionally designed and implemented backdoor etc. as the result of sheer 
>>

[qubes-users] Re: philosofy on qubes and other environment

I dont know how to install it,im so stupid omg.Maybe like ProxyVM and route 
trafic by pFsense? but its no option to choice only fedora debian.WTF im so 
stupid.I dont know how to install 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/69831d86-1f68-4a98-a6c8-850d55e80b07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

But i prefer to build that kind of sys-firewall on something like pfsense bcs 
its real firewall.

Tell me how to build pFsense (or something familiar) firewall on Qubes and set 
to default.

-- 
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/380b5454-b260-4a44-bb22-39fd1977bc71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

unikernel u mean this?
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/
i have installed it and work good.

-- 
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/b912cff3-7ca0-4504-97b1-1e3d4ef7cd41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2016-10-15 Thread QubesOS User



16.10.2016, 01:03, "raahe...@gmail.com" :
> On Saturday, October 15, 2016 at 5:09:46 PM UTC-4, QubesOS User wrote:
>>  Hello everyone,
>>
>>  I could imagine that this question has been discussed before already, and 
>> if this should be the case, then I'm very sorry for posting this (I'd be 
>> thankful for an according link if so though).
>>
>>  I think that I've gained quite much knowledge about possible attack 
>> surfaces provided on hardware and software level during the last 15 years, 
>> trying to keep up-to-date and often doing research on new approaches in this 
>> field. First of all, I'd like to stress that the 'objection' (which I don't 
>> mean as such) I may raise by this post does not have any intention of 
>> criticizing the great work and effort done by the QubesOS developers and the 
>> community (it's not meant as an unhelpful 'critique' at all). Much rather I 
>> have a huge respect for the commitment shown by everyone involved in the 
>> development of QubesOS.
>>
>>  Having compared various approaches in this field (e. g. OpenBSD, Linux 
>> using a hardened security kernel, GNU Hurd), I'd basically come to the 
>> conclusion that QubesOS is the most promising approach, especially if VT-d 
>> isolation is available.
>>
>>  However, the main points I'd like to address are:
>>
>>  1) XEN is developed by people working for a company based in the U.S. (I 
>> know the difference between open-source and proprietary software, but still 
>> they belong to the same team/company). If even developers of TrueCrypt 
>> received one of those 'blue letters' - What is the reason to assume that the 
>> XEN developers didn't receive one of those as well? Seen from the 
>> perspective of the NSA it looks totally odd and irrational to me if they 
>> would not to so, since they can do so, and it's their task to thwart any 
>> efforts which might hinder them from collecting data. I don't regard those 
>> people as being 'evil' or anything like that (nor do I regard this as being 
>> positive, which should go without saying), I just look at things in a 
>> rational way: If QubesOS is a great approach to ensure security, then one 
>> must be naive to assume that this won't automatically lead to classifiying 
>> this as a 'high priority target' - With all the consequences.
>>
>>  1.2) Since this looks so obvious to me: Why isn't it a top priority for 
>> QubesOS developers to make use of a supervisor (or develop an independent 
>> one, which would surely need endless efforts, but wouldn't it be worth it?), 
>> which is not subjected to the objections I tried to express?
>>
>>  2) QubesOS totally relies on 2.1) trusting XEN developers to completely 
>> understand the more than just complex x64 architecture being used today and 
>> 2.2) on trusting Intel's VT technology.
>>  Regarding 2.2): Just assuming Intel would have received some kind of 
>> 'advice' (they may even find motivation without getting such - I certainly 
>> don't think that Intel is an 'NSA subcontractor', but they are simply a big 
>> and profit-orientated company, not an idealistic open-source community like 
>> the QubesOS developers etc.) - Then how realistic is it that an absolutely 
>> professionally designed and implemented backdoor etc. as the result of sheer 
>> endless human, technological and financial ressources gets discovered by 
>> people like the QubesOS community, no matter how enthusiastic, intelligent, 
>> cautious and sceptical those are?
>>
>>  Referring once again to 2.1) I'd like to point to and quote from a highly 
>> interesting Qubes Security Bulletin 
>> (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-018-2015.txt):
>>  "2) We are not entirely convinced if the way Xen Security Team decided to 
>> address this vulnerability is really optimal, security wise. It seems like a 
>> more defensive approach would be to get rid of this
>>  dangerous construct of reusing the same memory for both an internal pointer 
>> and VM-provided data. Apparently Xen developers believe that they can fully 
>> understand the code, with all its execution paths, for decoding x86 
>> operands. This optimistic attitude seems surprising, given the very bug 
>> we're discussing today."
>>  [One should read the whole bulletin to know the context, but I didn't want 
>> this to become too long.]
>>
>>  One might also like to take a look at this bulletin, which gives me, among 
>> other XEN-related informations and facts, the strong impression that seeking 
>> an alternative hyperadvisor should have higest priority for the QubesOS 
>> development (believe me, I'd more than like to contribute to doing so by 
>> myself, too, and if I shold be able to aquire the necessary skills, I'll 
>> definitely try to do so):
>>  https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
>>  "A more radical reader might be of the opinion that we should completely 
>> replace Xen with some other hypervisor. Such

Re: [qubes-users] SMB mount point location

On 10/13/2016 02:25 PM, John Maher wrote:
> On Wednesday, October 12, 2016 at 12:06:15 PM UTC-4, Manuel Amador (Rudd-O) 
> wrote:
>> On 10/12/2016 12:55 PM, John Maher wrote:
>>> Hello,
>>>
>>> I'm trying to access file on the command line through an SMB mount point 
>>> that is created in the GUI. I'm using a debian-8 AppVM and connecting to an 
>>> SMB share in a Files window, but I cannot find a mount point for the share. 
>>> I would expect it to be in /run/users/1000/.gvfs, but there's nothing 
>>> there. 
>>>
>>> Can anyone point out where I would find that mount point?
>> By default, GVFS won't actually mount it — it just appears in the Files
>> window.  I believe the first time you attempt to activate (open) a file
>> on the share, GVFS does the mount.  It used to be different, I know, I
>> just hit this issue myself a few days ago.
>>
>> This is more a GNOME upstream thing.
>>
>> Do your files show on the file manager?
>>
>>
>> -- 
>> Rudd-O
>> http://rudd-o.com/
> The real issue is that I'm trying to access a KeePassX database that resides 
> on a smb share, and the Database > Open dialog box does not present mounted 
> smb shares or bookmarks to the shares. Any thoughts on this?

You need an actual mount for that to work, and the dialog box will not
trigger the mount operation.  You have two choices:

1) Open your KeepAssX database in a StandaloneVM which you have
configured to mount the SMB drive.
2) In the template, create and enable an /etc/systemd/system mount unit
for the SMB drive, that is only active if a file in
/var/run/qubes-service/ exists (check the various
qubes-*.service files in /usr/lib/systemd/system for examples on how the
ConditionPathExists thing works), then set up the qubes-service
 on the VM in question.  That way, when you boot the VM in
question, and only that VM in question, the mount appears immediately.

I would also use automount units if I were you, just to make sure that
your VM where you run KeepAssX boots fast and does not wait to mount the
remote device.

Here is a crude example of such a thing:

[user@tpl ~]$ mkdir /mnt/keepassxmount
[user@tpl ~]$ cat > /etc/systemd/system/mnt-keepassxmount.mount
[Unit]
Description=Mount /mnt/keepassxmount
ConditionPathExists=/var/run/qubes-service/mnt-keepassxmount
Before=remote-fs.target
After=remote-fs-pre.target mnt-keepassxmount.path

[Mount]
What=//smbserverip/keepassxmount
Where=/mnt/keepassxmount
Type=cifs
Options=_netdev,cache=strict,forceuid,forcegid,noperm,noserverino,nomapposix,nomapchars,uid=user,gid=user,forceuid,forcegid

[Install]
WantedBy=remote-fs.target
[user@tpl ~]$ systemctl enable mnt-keepassxmount.mount

At this point you add the Qubes service mnt-keepassxmount in your VM's
configuration.

Option 3: use some file sync service to keep that KeepAssX file
synchronized to local disk on that VM.

-- 
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/6dc1b9a0-3194-638a-afd4-a224cf2cc46b%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

I would love to see an openbsd,  or some more hardened sys-firewall.  There 
have been some community efforts maybe you can create one.  we have minimal 
templates available now.  I read about a unikernel someone made for qubes that 
looked interesting.  Maybe you can create something.  Qubes team is not very 
large and this is still way more secure imo then a traditional linux or windows 
os man. 

-- 
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/d88f7035-7834-421e-9341-ccd85cc676e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

On Saturday, October 15, 2016 at 10:02:32 PM UTC-4, pleo...@gmail.com wrote:
> for an example it was much better for security if that no build on the same 
> but somethin like this
> 
> ubuntu (sys-net)-pfsense(sys-firewall)- appVM (debian or fedora)

again probably only making a real difference against a random or automatic 
qubes designed attack I guess?   You can still do what you want yourself man.  
You don't have to use the default setup.

-- 
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/a2ebb8d7-eb4e-458a-bcb1-6070a674b590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

for an example it was much better for security if that no build on the same but 
somethin like this

ubuntu (sys-net)-pfsense(sys-firewall)- appVM (debian or fedora)

-- 
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/281c5e58-160b-4ad7-8a05-697fe9bd7e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

On 10/15/2016 04:56 PM, 4lgaqp+cqeepdnbinsts via qubes-users wrote:
> Hi Chris,
>
> Thanks for the suggestion.
> Just to clarify, the VPN tunnel was created within the sys-firewall,

I believe the VPN set up by the instructions in the official docs
interfere with the updates proxy functionality.

Try this: https://github.com/Rudd-O/qubes-vpn .  Pay special attention
to README.md heading "Updates of template VMs attached to the VPN VM". 
That ought to work.

>  and currently that's the only proxyVM that I'm using (apart from the 
> sys-whonix), hence all traffic from the sys-net isn't encapsulated by the 
> tunnel.
> My understanding is that the sys-firewall merely forwards the traffic through 
> the sys-net by adding a forwad rule in the sys-firewall every time a new VM 
> is started. For that reason I was wondering if I cannot solve this more 
> effectively by simple adding a forwarding rule in the sys-firewall to 
> whitelist all traffic originated from 0.0.0.0/0 to the destination address 
> 10.137.255.254/32 and port 8082, wouldn't this be possible? 
> Privacy during updates are not an issue for me, by the contrary, since this 
> would allow more network throughput.
> I confess I'm not very keen in changing templates or creating a dedicated 
> proxyVm for this purpose.
>
> Thanks
>
>
>
>
>
> 
> Sent using GuerrillaMail.com
> Block or report abuse: 
> https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D
>
>


-- 
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/85a129e5-98f8-9dfa-e4f2-3b6ca5c569c2%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

look at qubes how is it build? 
vitrualisation of the same environment 

1-2-3 is separated but its still the same so somoene exploit 1 then exploit 2-3 
on recursive.

i mean by this vitrualisation same topology.

So what i mean is better way to multiple topology than avoid recursive exploits.

-- 
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/1aa5eed5-7fd7-4790-87da-c3ce11818f9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

On 10/15/2016 04:56 PM, 4lgaqp+cqeepdnbinsts via qubes-users wrote:
> Hi Chris,
>
> Thanks for the suggestion.
> Just to clarify, the VPN tunnel was created within the sys-firewall, and 
> currently that's the only proxyVM that I'm using (apart from the sys-whonix), 
> hence all traffic from the sys-net isn't encapsulated by the tunnel.

The instructions in the VPN doc (appear to me to) interfere with the Yum
Qubes proxy forwarding that is necessary for updates to work.

Try https://github.com/Rudd-O/qubes-vpn if possible, see if updates work
there.  You must run the Qubes updates proxy service directly in the
same VPN VM.Note that update server queries will be handled by the
proxy and therefore will not go over the VPN.

> My understanding is that the sys-firewall merely forwards the traffic through 
> the sys-net by adding a forwad rule in the sys-firewall every time a new VM 
> is started. For that reason I was wondering if I cannot solve this more 
> effectively by simple adding a forwarding rule in the sys-firewall to 
> whitelist all traffic originated from 0.0.0.0/0 to the destination address 
> 10.137.255.254/32 and port 8082, wouldn't this be possible? 
> Privacy during updates are not an issue for me, by the contrary, since this 
> would allow more network throughput.
> I confess I'm not very keen in changing templates or creating a dedicated 
> proxyVm for this purpose.
>
> Thanks
>
>
>
>
>
> 
> Sent using GuerrillaMail.com
> Block or report abuse: 
> https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D
>
>


-- 
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/081416f6-f3ff-7404-222a-2d9b32fae64a%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

pleom...@gmail.com:
> or the worst thing if hacker cant do this he can try to compromize 
> sys-firewall in the same way as sysnet bcs its the same topology.And after 
> compromizing sys-firewall then can do whatever he like.
> 

I'm not sure what you're trying to say here.  Anyway it should be
difficult to compromise sys-firewall, as the attack surface just isn't
that big.  But still possible, most likely.

Anyway after compromising sys-firewall, the attacker is still confined
to sys-firewall.  This just allows the attacker to observe and modify
network traffic, which is already a part of your threat model.  Right?

The attacker would need to break out to dom0 to "do whatever (s)he wants".

Andrew

-- 
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/8858692c-819a-09ad-6cb3-aa881475d8c2%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

2016-10-15 Thread johnyjukya

> Ok, so I tried to enable the updates proxy in the sys-firewall
> consequently forcing all updates to go through the VPN, I followed the
> instructions outlined here -
> https://www.qubes-os.org/doc/software-update-vm/#updates-proxy
> However, as soon as I try to run the updates on one of the vmtemplate I
> get the error "No route to host". All the templatevm has a default route
> to the sys-net (10.137.1.1), notwithstanding the update should be
> targeting the sys-firewall. Should I change the default GW of the
> templatevm ?!

I found that using an UpdateVM other than sys-net results in failures
because the iptables rule to accept connections on local port 8082 is
never added to any VM, other than than the default NetVM.

Updates failed for me (packets to port 8082 being dropped on the update
VM) until I manually added the rule myself as the first filter rule:

"-A INPUT -i vif+ -p tcp -m tcp --dport 8082 -j ACCEPT"

Or you could just call /usr/lib/qubes/iptables-updates-proxy, which is
what happens in sys-net



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

Re: [qubes-users] Re: philosofy on qubes and other environment

On Saturday, October 15, 2016 at 9:17:14 PM UTC-4, johny...@sigaint.org wrote:
> > Andrew:
> > This kind of security-first posture is what has made Qubes famous.
> 
> I agree that Qubes separation is probably the most secure basis for a
> reasonably usable PC-based platform today.  It's all I'll use.  (I worry
> about 4.0 not working on my hardware, tho.  And upgrading hardware brings
> its own security risks.)
> 
> That being said, there are a few things that stuck out like sore thumbs as
> being terribly insecure in the default install, which surprised me:
> 
> - (There are some outstanding tickets on this one): All the daemons
> started by systemd, some of which phone home (at the very least, leaking
> your IP address) to Microsoft (resolving SMB names, even when you don't
> use SMB) or RedHat (default network connectivity check for NetworkManger).
> 
> exim4, cupsd, ntpd (on by default in debian-8) don't need to be running,
> and can potentially leak information (and increase the attack surface). 
> pulseaudio and the speaker daemon can potentially leak information from a
> VM through audio channels, and aren't needed in most cases.
> 
> The default templates should be very much stripped of having any software
> run by default, or unexpectedly.  The package (such exim, cups) can be
> included in the template, sure, but not on by default.
> 
> - Fairly loose default iptables/firewall setup (particularly for outbound
> connections).  No inherent DNS leakage protection.  (whonix or a VPN can
> solve this.)  Fairly limited firewall configuration.
> 
> - No apparmor by default.  When I tried to install it in a VM, I got
> errors about a missing kernel module, and haven't explored it further.
> 
> Yes, VM separation keeps rogue processes at bay, but it'd still be nice if
> a compromised Firefox just didn't have the option of going through
> ~/Documents and uploading the contents to some .ru site.  :)
> 
> Apparmor and its profiles would add this extra layer of protection.  Wow,
> being able to run *two* or more apps in a VM without worry of them spying
> on each other's data or connect to the net in ways they shouldn't!  :)
> 
> Keeping every useful work file on separate or non-networked machines to
> avoid rogue applications is too much of a PITA for most people.  Or at
> least for me.
> 
> - Unencrypted /boot partition.  This one is a huge hole and could be
> fixed.  I've converted my /boot to luks filesystem successfully, grub
> supports it.  Adding a Grub password doesn't hurt, either.   (As well as a
> BIOS password, but I'm digressing.)
> 
> - Some of the things trumpeted in the earlier design documents and press
> coverage just aren't there.  Sound cards, video cards, storage devices,
> USB, all (by default) live in dom0, not safely tucked in VMs.
> 
> (Not sure why my network card's Linux module seems to load in dom0 as well
> as sys-net, but I'm assuming that's not an issue, and the network card is
> fully in sys-net.)
> 
> Individual VM's disks aren't encrypted with their own luks filesystem and
> keys, which is mentioned in a few articles or papers I read.  Not sure how
> important this one is, but where it is listed as a feature in some
> reviews, I thought I'd mention it for clarity.  It might be useful if
> someone compromised root, that they wouldn't necessarily have access to
> the data on your VM's.  But that's a lot more password juggling and
> layered encryption with associated CPU cost, so I dunno.  (Qubes VM
> Manager would end up being a bit of a password vault in itself, ugh.)
> 
> I'm only pointing these out in a constructive way, I still love the
> system, and just want to suggest ways to make it even better for those who
> don't spend the time or have the knowledge to tweak up these security
> risks.
> 
> Cheers.
> 
> JJ

Microsoft phoning home? what?

debian is not default for qubes vms.  Its a community package,   But you can 
customize it how ever you want just like a bare metal debian.

whonix has instructions for how to install apparmor,  which will also apply to 
a debian template. https://www.whonix.org/wiki/Qubes/Install I use it for 
chromium and hexchat.

VM separation means you don't go to a website that will upload your documents 
to a .ru site, in a vm that has documents you don't want there.  Thats the 
whole point I think maybe your missing, and understandably what turns alot of 
people off.   

You have to be able to strictly use different vms for diff tasks.  Which also 
means you want alot of memory and hdd space.  Its perceived overwhelming to 
those not used to it.  but no different then having lots of file folders on a 
machine imo.

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

Re: [qubes-users] Re:Persistant routes on Qubes are not persistant?!

2016-10-15 Thread johnyjukya

>> Does anyone knows how to set static routes persistently into the
>> sys-firewall?

NetworkManager lets you add static routes for a network card.  You might
be able to get what you want by adding and checking off the
'network-manager' service for the VM (and restarting), then configuring
the virtual interface's routes from the new additional NetworkManager Icon
that should show up.

You might be able to disable the service afterwards if you don't want the
extra taskbar icon.  I think the settings should stick around even if the
NetworkManager GUI/icon isn't running.

JJ

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86aa4b922926306dd6f0b5fec9c0c28c.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.

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

On 10/16/2016 01:03 AM, pleom...@gmail.com wrote:
> my vpn connection is good bcs its connect 
> openvpn --config qubes-vpn.conf

That's not what I asked for.

Please give me the information required by the Troubleshooting section
of the README.md file in the project

Otherwise I cannot debug the problem for you and you are on your own.

> its something with your script,have you test it whith fedora minimal?

Yes, I use it with Fedora minimal.

-- 
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/8efc8406-769e-65be-41e8-941aaf46cf46%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

On 10/16/2016 12:16 AM, pleom...@gmail.com wrote:
> look guys if someone compromize sys-net then go route trafic by fake dns and 
> sites.You paste your credit card or something and all data goes to the hacker.

If someone compromises the network card of your AppArmor-enabled Ubuntu
instance, the same thing happens.  Except in that case the malware can
access way more than just DNS spoofing.

Advantage: Qubes OS.


-- 
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/d06829fc-0a08-d543-2598-352ebc4c05b8%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

2016-10-15 Thread johnyjukya

> Andrew:
> This kind of security-first posture is what has made Qubes famous.

I agree that Qubes separation is probably the most secure basis for a
reasonably usable PC-based platform today. It's all I'll use. (I worry
about 4.0 not working on my hardware, tho. And upgrading hardware brings
its own security risks.)

That being said, there are a few things that stuck out like sore thumbs as
being terribly insecure in the default install, which surprised me:

- (There are some outstanding tickets on this one): All the daemons
started by systemd, some of which phone home (at the very least, leaking
your IP address) to Microsoft (resolving SMB names, even when you don't
use SMB) or RedHat (default network connectivity check for NetworkManger).

exim4, cupsd, ntpd (on by default in debian-8) don't need to be running,
and can potentially leak information (and increase the attack surface).
pulseaudio and the speaker daemon can potentially leak information from a
VM through audio channels, and aren't needed in most cases.

The default templates should be very much stripped of having any software
run by default, or unexpectedly. The package (such exim, cups) can be
included in the template, sure, but not on by default.

- Fairly loose default iptables/firewall setup (particularly for outbound
connections). No inherent DNS leakage protection. (whonix or a VPN can
solve this.) Fairly limited firewall configuration.

- No apparmor by default. When I tried to install it in a VM, I got
errors about a missing kernel module, and haven't explored it further.

Yes, VM separation keeps rogue processes at bay, but it'd still be nice if
a compromised Firefox just didn't have the option of going through
~/Documents and uploading the contents to some .ru site. :)

Apparmor and its profiles would add this extra layer of protection. Wow,
being able to run *two* or more apps in a VM without worry of them spying
on each other's data or connect to the net in ways they shouldn't! :)

Keeping every useful work file on separate or non-networked machines to
avoid rogue applications is too much of a PITA for most people. Or at
least for me.

- Unencrypted /boot partition. This one is a huge hole and could be
fixed. I've converted my /boot to luks filesystem successfully, grub
supports it. Adding a Grub password doesn't hurt, either. (As well as a
BIOS password, but I'm digressing.)

- Some of the things trumpeted in the earlier design documents and press
coverage just aren't there. Sound cards, video cards, storage devices,
USB, all (by default) live in dom0, not safely tucked in VMs.

(Not sure why my network card's Linux module seems to load in dom0 as well
as sys-net, but I'm assuming that's not an issue, and the network card is
fully in sys-net.)

Individual VM's disks aren't encrypted with their own luks filesystem and
keys, which is mentioned in a few articles or papers I read. Not sure how
important this one is, but where it is listed as a feature in some
reviews, I thought I'd mention it for clarity. It might be useful if
someone compromised root, that they wouldn't necessarily have access to
the data on your VM's. But that's a lot more password juggling and
layered encryption with associated CPU cost, so I dunno. (Qubes VM
Manager would end up being a bit of a password vault in itself, ugh.)

I'm only pointing these out in a constructive way, I still love the
system, and just want to suggest ways to make it even better for those who
don't spend the time or have the knowledge to tweak up these security
risks.

Cheers.

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

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

my vpn connection is good bcs its connect 
openvpn --config qubes-vpn.conf
its something with your script,have you test it whith fedora minimal?

-- 
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/3f3f27cd-4eb1-4c08-a2c8-efcc0f975946%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

look guys if someone compromize sys-net then go route trafic by fake dns and 
sites.You paste your credit card or something and all data goes to the hacker.

-- 
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/e10e42a9-17a2-4d6a-b2ff-7733f8fc4708%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

pleom...@gmail.com:
> But look every vms in qubes base on the same,so if someone compromize sys-net 
> VM then it should not be so hard to compromize other VMs.
> 

It would compromise sys-net.  Any writes to the template-based volume
(with /bin, /usr, /var, etc.) are discarded upon VM reboot.  They are
not written to the base template--only the template itself can do that.

It's possible malware could persist in sys-net, though, by compromising
its /rw partition, which *does* persist across reboots (but is only used
by that specific VM).  But even then: it only compromizes sys-net.

Andrew

-- 
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/cef64a3a-176c-0081-2b0e-fb67f7e30837%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

Andrew:
> pleom...@gmail.com:
>> If there is no user acces control like a real root real user then its no 
>> sense to use it.
>>
> 
> I think you've missed something pretty fundamental.
> 
> Throw out everything you know about the Linux kernel and how it enforces
> security (including MAC).  Qubes takes the position that the Linux
> kernel code base is simply too large and complex to meaningfully trust,
> and that any security policies must be enforced by a smaller, more
> trustable hypervisor.
> 
> The security problem is then less about user accounts, process
> separation, etc. and more about ensuring guest VMs only modify their own
> state, and interact with other VMs only through simple, easier-to-audit
> and easier-to-securely-implement channels.
> 
> IMO all the Qubes magic is about these over-the-top channels.  You can
> use bare Xen (or ESXi, or HyperV or whatever) to get similar VM
> isolation, but it will be cumbersome to orchestrate typical user actions
> (inter-VM file copying, PDF conversion, networking/firewalling,
> trustable DWM, ...).  Qubes makes it easy.
> 
> Andrew
> 
> PS: Let me give an example.  Suppose your typical Linux desktop has a
> 'user1' account and a 'tor' account.  Suppose the latter is used for
> running a Tor relay.  Normally you would expect the Linux kernel to
> enforce access control, to ensure any code running with the 'tor' uid
> will not be able to access 'user1''s files.  In Qubes, you just install
> Tor into a separate VM from the VM you use for the 'user1' persona.
> Thus the barrier for Tor to access 'user1''s data is the hypervisor, not
> the Linux kernel.
> 

Sorry for adding to the spam, but I feel obliged to add two important
points:

1) It's not just the kernel.  Practical user security depends on a lot
of userland system components, too.  That's why it really is appropriate
for Qubes to abstract security domains as independent VMs.

2) While I wrote 'similar VM isolation', I still believe Qubes is the
most secure practical virtualization platform.  For example, the VENOM
(CVE-2015-3456) vulnerability affected nearly every other Xen
vendor--but not Qubes.  To quote Marek:

"[The solution] is already there - there is no other option in Qubes.
We've never considered running such a bloatware as qemu directly in dom0
;) "

This kind of security-first posture is what has made Qubes famous.
Trust it or not, but I hope the architecture now makes sense!

Andrew

-- 
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/70244db2-44a2-e5f7-c09c-1c320307fdac%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

pleom...@gmail.com:
> If there is no user acces control like a real root real user then its no
> sense to use it.
>

I think you've missed something pretty fundamental.

Throw out everything you know about the Linux kernel and how it enforces
security (including MAC). Qubes takes the position that the Linux
kernel code base is simply too large and complex to meaningfully trust,
and that any security policies must be enforced by a smaller, more
trustable hypervisor.

The security problem is then less about user accounts, process
separation, etc. and more about ensuring guest VMs only modify their own
state, and interact with other VMs only through simple, easier-to-audit
and easier-to-securely-implement channels.

IMO all the Qubes magic is about these over-the-top channels. You can
use bare Xen (or ESXi, or HyperV or whatever) to get similar VM
isolation, but it will be cumbersome to orchestrate typical user actions
(inter-VM file copying, PDF conversion, networking/firewalling,
trustable DWM, ...). Qubes makes it easy.

Andrew

PS: Let me give an example. Suppose your typical Linux desktop has a
'user1' account and a 'tor' account. Suppose the latter is used for
running a Tor relay. Normally you would expect the Linux kernel to
enforce access control, to ensure any code running with the 'tor' uid
will not be able to access 'user1''s files. In Qubes, you just install
Tor into a separate VM from the VM you use for the 'user1' persona.
Thus the barrier for Tor to access 'user1''s data is the hypervisor, not
the Linux kernel.

--
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/1af259c8-f9ea-a631-3204-836d435f344f%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re:Persistant routes on Qubes are not persistant?!

2016-10-15 Thread 4lj7sp+iurnm2duwf1g via qubes-users

bump

Does anyone knows how to set static routes persistently into the sys-firewall?

Thanks






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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

[qubes-users] Re: philosofy on qubes and other environment

If there is no user acces control like a real root real user then its no sense 
to use 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/d6c6a3e7-4119-4f76-94db-75e5e825aa11%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

the idea of apparmor is to resist to app to resources they need to run and 
nothing more.

-- 
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/9aecf737-f844-4688-8a70-bb7061780636%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

On Saturday, October 15, 2016 at 7:09:00 PM UTC-4, raah...@gmail.com wrote:
> On Saturday, October 15, 2016 at 7:08:24 PM UTC-4, raah...@gmail.com wrote:
> > On Saturday, October 15, 2016 at 5:48:16 PM UTC-4, pleo...@gmail.com wrote:
> > > @ raa...@gmail.com
> > > 
> > > dont know if this have any sense bcs everything in qubes in default 
> > > configuration is user accesible.Firstly to use this it should be 
> > > configured  user acces control wich qubes dont provide in default 
> > > configuration.
> > 
> > I think you can make a root user during install i could be wrong.  But it 
> > wouldn't make much of a difference anyways man.
> 
> but also apparmor works on root too.

ya but again, its more about what user wants to do on his computer that makes 
them vulnerable,  and I'm sure there is 0 days out there for everyone, so big 
money gov'ts pwn us all,  i mean if they that bored but at least we can stop 
the robots hopefully.

-- 
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/2aec57dd-1258-4866-add4-52946244ea9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maybe a provocative question

On Saturday, October 15, 2016 at 7:04:46 PM UTC-4, raah...@gmail.com wrote:
> On Saturday, October 15, 2016 at 7:03:43 PM UTC-4, raah...@gmail.com wrote:
> > On Saturday, October 15, 2016 at 5:09:46 PM UTC-4, QubesOS User wrote:
> > > Hello everyone,
> > > 
> > > I could imagine that this question has been discussed before already, and 
> > > if this should be the case, then I'm very sorry for posting this (I'd be 
> > > thankful for an according link if so though).
> > > 
> > > 
> > > I think that I've gained quite much knowledge about possible attack 
> > > surfaces provided on hardware and software level during the last 15 
> > > years, trying to keep up-to-date and often doing research on new 
> > > approaches in this field. First of all, I'd like to stress that the 
> > > 'objection' (which I don't mean as such) I may raise by this post does 
> > > not have any intention of criticizing the great work and effort done by 
> > > the QubesOS developers and the community (it's not meant as an unhelpful 
> > > 'critique' at all). Much rather I have a huge respect for the commitment 
> > > shown by everyone involved in the development of QubesOS.
> > > 
> > > 
> > > Having compared various approaches in this field (e. g. OpenBSD, Linux 
> > > using a hardened security kernel, GNU Hurd), I'd basically come to the 
> > > conclusion that QubesOS is the most promising approach, especially if 
> > > VT-d isolation is available.
> > > 
> > > 
> > > However, the main points I'd like to address are:
> > > 
> > > 1) XEN is developed by people working for a company based in the U.S. (I 
> > > know the difference between open-source and proprietary software, but 
> > > still they belong to the same team/company). If even developers of 
> > > TrueCrypt received one of those 'blue letters' - What is the reason to 
> > > assume that the XEN developers didn't receive one of those as well? Seen 
> > > from the perspective of the NSA it looks totally odd and irrational to me 
> > > if they would not to so, since they can do so, and it's their task to 
> > > thwart any efforts which might hinder them from collecting data. I don't 
> > > regard those people as being 'evil'  or anything like that (nor do I 
> > > regard this as being positive, which should go without saying), I just 
> > > look at things in a rational way: If QubesOS is a great approach to 
> > > ensure security, then one must be naive to assume that this won't 
> > > automatically lead to classifiying this as a 'high priority target' - 
> > > With all the consequences.
> > > 
> > > 1.2) Since this looks so obvious to me: Why isn't it a top priority for 
> > > QubesOS developers to make use of a supervisor (or develop an independent 
> > > one, which would surely need endless efforts, but wouldn't it be worth 
> > > it?), which is not subjected to the objections I tried to express?
> > > 
> > > 2) QubesOS totally relies on 2.1) trusting XEN developers to completely 
> > > understand the more than just complex x64 architecture being used today 
> > > and 2.2) on trusting Intel's VT technology.
> > > Regarding 2.2): Just assuming Intel would have received some kind of 
> > > 'advice' (they may even find motivation without getting such - I 
> > > certainly don't think that Intel is an 'NSA subcontractor', but they are 
> > > simply a big and profit-orientated company, not an idealistic open-source 
> > > community like the QubesOS developers etc.) - Then how realistic is it 
> > > that an absolutely professionally designed and implemented backdoor etc. 
> > > as the result of sheer endless human, technological and financial 
> > > ressources gets discovered by people like the QubesOS community, no 
> > > matter how enthusiastic, intelligent, cautious and sceptical those are?
> > > 
> > > Referring once again to 2.1) I'd like to point to and quote from a highly 
> > > interesting Qubes Security Bulletin 
> > > (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-018-2015.txt):
> > > "2) We are not entirely convinced if the way Xen Security Team decided to 
> > > address this vulnerability is really optimal, security wise. It seems 
> > > like a more defensive approach would be to get rid of this
> > > dangerous construct of reusing the same memory for both an internal 
> > > pointer and VM-provided data. Apparently Xen developers believe that they 
> > > can fully understand the code, with all its execution paths, for decoding 
> > > x86 operands. This optimistic attitude seems surprising, given the very 
> > > bug we're discussing today."
> > > [One should read the whole bulletin to know the context, but I didn't 
> > > want this to become too long.]
> > > 
> > > One might also like to take a look at this bulletin, which gives me, 
> > > among other XEN-related informations and facts, the strong impression 
> > > that seeking an alternative hyperadvisor should have higest priority for 
> > > the QubesOS development (believe me, I'd more than like to

[qubes-users] Maybe a provocative question

2016-10-15 Thread QubesOS User

Hello everyone,

I could imagine that this question has been discussed before already, and if 
this should be the case, then I'm very sorry for posting this (I'd be thankful 
for an according link if so though).


I think that I've gained quite much knowledge about possible attack surfaces 
provided on hardware and software level during the last 15 years, trying to 
keep up-to-date and often doing research on new approaches in this field. First 
of all, I'd like to stress that the 'objection' (which I don't mean as such) I 
may raise by this post does not have any intention of criticizing the great 
work and effort done by the QubesOS developers and the community (it's not 
meant as an unhelpful 'critique' at all). Much rather I have a huge respect for 
the commitment shown by everyone involved in the development of QubesOS.


Having compared various approaches in this field (e. g. OpenBSD, Linux using a 
hardened security kernel, GNU Hurd), I'd basically come to the conclusion that 
QubesOS is the most promising approach, especially if VT-d isolation is 
available.


However, the main points I'd like to address are:

1) XEN is developed by people working for a company based in the U.S. (I know 
the difference between open-source and proprietary software, but still they 
belong to the same team/company). If even developers of TrueCrypt received one 
of those 'blue letters' - What is the reason to assume that the XEN developers 
didn't receive one of those as well? Seen from the perspective of the NSA it 
looks totally odd and irrational to me if they would not to so, since they can 
do so, and it's their task to thwart any efforts which might hinder them from 
collecting data. I don't regard those people as being 'evil'  or anything like 
that (nor do I regard this as being positive, which should go without saying), 
I just look at things in a rational way: If QubesOS is a great approach to 
ensure security, then one must be naive to assume that this won't automatically 
lead to classifiying this as a 'high priority target' - With all the 
consequences.

1.2) Since this looks so obvious to me: Why isn't it a top priority for QubesOS 
developers to make use of a supervisor (or develop an independent one, which 
would surely need endless efforts, but wouldn't it be worth it?), which is not 
subjected to the objections I tried to express?

2) QubesOS totally relies on 2.1) trusting XEN developers to completely 
understand the more than just complex x64 architecture being used today and 
2.2) on trusting Intel's VT technology.
Regarding 2.2): Just assuming Intel would have received some kind of 'advice' 
(they may even find motivation without getting such - I certainly don't think 
that Intel is an 'NSA subcontractor', but they are simply a big and 
profit-orientated company, not an idealistic open-source community like the 
QubesOS developers etc.) - Then how realistic is it that an absolutely 
professionally designed and implemented backdoor etc. as the result of sheer 
endless human, technological and financial ressources gets discovered by people 
like the QubesOS community, no matter how enthusiastic, intelligent, cautious 
and sceptical those are?

Referring once again to 2.1) I'd like to point to and quote from a highly 
interesting Qubes Security Bulletin 
(https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-018-2015.txt):
"2) We are not entirely convinced if the way Xen Security Team decided to 
address this vulnerability is really optimal, security wise. It seems like a 
more defensive approach would be to get rid of this
dangerous construct of reusing the same memory for both an internal pointer and 
VM-provided data. Apparently Xen developers believe that they can fully 
understand the code, with all its execution paths, for decoding x86 operands. 
This optimistic attitude seems surprising, given the very bug we're discussing 
today."
[One should read the whole bulletin to know the context, but I didn't want this 
to become too long.]

One might also like to take a look at this bulletin, which gives me, among 
other XEN-related informations and facts, the strong impression that seeking an 
alternative hyperadvisor should have higest priority for the QubesOS 
development (believe me, I'd more than like to contribute to doing so by 
myself, too, and if I shold be able to aquire the necessary skills, I'll 
definitely try to do so):
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
"A more radical reader might be of the opinion that we should completely 
replace Xen with some other hypervisor. Such an opinion is surely not 
unfounded, as we have previously expressed our disappointment in the Xen 
security process [5]. Sadly, not much has improved over the past several 
months. Moreover, even though Qubes is now based on a hypervisor-abstracting 
architecture ("Odyssey"), which should make switching to a different VMM a 
relatively easy task, the primary problem that

[qubes-users] Re: philosofy on qubes and other environment

On Saturday, October 15, 2016 at 7:08:24 PM UTC-4, raah...@gmail.com wrote:
> On Saturday, October 15, 2016 at 5:48:16 PM UTC-4, pleo...@gmail.com wrote:
> > @ raa...@gmail.com
> > 
> > dont know if this have any sense bcs everything in qubes in default 
> > configuration is user accesible.Firstly to use this it should be configured 
> >  user acces control wich qubes dont provide in default configuration.
> 
> I think you can make a root user during install i could be wrong.  But it 
> wouldn't make much of a difference anyways man.

but also apparmor works on root too.

-- 
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/d0109409-e6dd-46c3-b28a-df03d1d06f24%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

On Saturday, October 15, 2016 at 5:48:16 PM UTC-4, pleo...@gmail.com wrote:
> @ raa...@gmail.com
> 
> dont know if this have any sense bcs everything in qubes in default 
> configuration is user accesible.Firstly to use this it should be configured  
> user acces control wich qubes dont provide in default configuration.

I think you can make a root user during install i could be wrong.  But it 
wouldn't make much of a difference anyways man.

-- 
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/3faa6ce9-8967-4dec-87d1-7672e50f1257%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Maybe a provocative question

On Saturday, October 15, 2016 at 5:09:46 PM UTC-4, QubesOS User wrote:
> Hello everyone,
> 
> I could imagine that this question has been discussed before already, and if 
> this should be the case, then I'm very sorry for posting this (I'd be 
> thankful for an according link if so though).
> 
> 
> I think that I've gained quite much knowledge about possible attack surfaces 
> provided on hardware and software level during the last 15 years, trying to 
> keep up-to-date and often doing research on new approaches in this field. 
> First of all, I'd like to stress that the 'objection' (which I don't mean as 
> such) I may raise by this post does not have any intention of criticizing the 
> great work and effort done by the QubesOS developers and the community (it's 
> not meant as an unhelpful 'critique' at all). Much rather I have a huge 
> respect for the commitment shown by everyone involved in the development of 
> QubesOS.
> 
> 
> Having compared various approaches in this field (e. g. OpenBSD, Linux using 
> a hardened security kernel, GNU Hurd), I'd basically come to the conclusion 
> that QubesOS is the most promising approach, especially if VT-d isolation is 
> available.
> 
> 
> However, the main points I'd like to address are:
> 
> 1) XEN is developed by people working for a company based in the U.S. (I know 
> the difference between open-source and proprietary software, but still they 
> belong to the same team/company). If even developers of TrueCrypt received 
> one of those 'blue letters' - What is the reason to assume that the XEN 
> developers didn't receive one of those as well? Seen from the perspective of 
> the NSA it looks totally odd and irrational to me if they would not to so, 
> since they can do so, and it's their task to thwart any efforts which might 
> hinder them from collecting data. I don't regard those people as being 'evil' 
>  or anything like that (nor do I regard this as being positive, which should 
> go without saying), I just look at things in a rational way: If QubesOS is a 
> great approach to ensure security, then one must be naive to assume that this 
> won't automatically lead to classifiying this as a 'high priority target' - 
> With all the consequences.
> 
> 1.2) Since this looks so obvious to me: Why isn't it a top priority for 
> QubesOS developers to make use of a supervisor (or develop an independent 
> one, which would surely need endless efforts, but wouldn't it be worth it?), 
> which is not subjected to the objections I tried to express?
> 
> 2) QubesOS totally relies on 2.1) trusting XEN developers to completely 
> understand the more than just complex x64 architecture being used today and 
> 2.2) on trusting Intel's VT technology.
> Regarding 2.2): Just assuming Intel would have received some kind of 'advice' 
> (they may even find motivation without getting such - I certainly don't think 
> that Intel is an 'NSA subcontractor', but they are simply a big and 
> profit-orientated company, not an idealistic open-source community like the 
> QubesOS developers etc.) - Then how realistic is it that an absolutely 
> professionally designed and implemented backdoor etc. as the result of sheer 
> endless human, technological and financial ressources gets discovered by 
> people like the QubesOS community, no matter how enthusiastic, intelligent, 
> cautious and sceptical those are?
> 
> Referring once again to 2.1) I'd like to point to and quote from a highly 
> interesting Qubes Security Bulletin 
> (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-018-2015.txt):
> "2) We are not entirely convinced if the way Xen Security Team decided to 
> address this vulnerability is really optimal, security wise. It seems like a 
> more defensive approach would be to get rid of this
> dangerous construct of reusing the same memory for both an internal pointer 
> and VM-provided data. Apparently Xen developers believe that they can fully 
> understand the code, with all its execution paths, for decoding x86 operands. 
> This optimistic attitude seems surprising, given the very bug we're 
> discussing today."
> [One should read the whole bulletin to know the context, but I didn't want 
> this to become too long.]
> 
> One might also like to take a look at this bulletin, which gives me, among 
> other XEN-related informations and facts, the strong impression that seeking 
> an alternative hyperadvisor should have higest priority for the QubesOS 
> development (believe me, I'd more than like to contribute to doing so by 
> myself, too, and if I shold be able to aquire the necessary skills, I'll 
> definitely try to do so):
> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
> "A more radical reader might be of the opinion that we should completely 
> replace Xen with some other hypervisor. Such an opinion is surely not 
> unfounded, as we have previously expressed our disappointment in the Xen 
> security process [5]. Sadly, not much

[qubes-users] Re: QUBES 3.2 won't install... EFI_MEMMAP is not enabled... ESRT header is not in the memory map

On Saturday, October 15, 2016 at 6:05:39 PM UTC-4, aldenj...@gmail.com wrote:
> I have the same issue!

see if you can select legacy boot mode in your bios and then install qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/648cacc3-1f95-490c-9197-edc4e9650906%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Android development under QubesOS

2016-10-15 Thread Vít Šesták

Well, you can select ARM in the emulator. While it reduces performance (you 
need to actually emulate the instructions), it works.

I've also tried installing Android in a HVM, it worked somehow, but it was not 
very usable. Most notably, there was a problem with mapping touches to mouse. 
(Well, Qubes AFAIK provides an emulated tablet there.) I don't know which build 
it was and you might be more lucky.

-- 
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/77f979bd-9794-46c3-952b-5c8c6792b8bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

2016-10-15 Thread 4limaw+5vktrow980bj4 via qubes-users

I was finally able to put this to work! I have to set the sys-firewall as a 
qubes-yum-proxy forcing also all the apt/yum traffic through the tunnel.
Everything seems to be working fine now, although I do get a warning on the 
sys-firewall on the firewall settings while using the Qubes VM Manager:

"The 'sys-firewall' AppVM is not connected to a FirewallVM!

You may edit the 'sys-firewall' VM firewall rules, but these will not take any 
effect until you connect it to a working Firewall VM."

I would expect this warning to be normal, right? Is there any risk in terms of 
IP leakage to allow all the output traffic from the sys-firewall to the sys-net?






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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

Re: [qubes-users] Android development under QubesOS

2016-10-15 Thread Torsten Grote

On 10/15/2016 03:38 PM, Alex wrote:
> I've had luck with Alcatel Pixi 3 and Wiko Jerry, but there's no way of
> forwarding an Asus Zenfone 4 - it just resets itself and returns to usbvm.

Check this issue that describes the problem and some workarounds:

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

On a related note: I'd still be grateful for any hints for how to get
the Android Emulator working under qubes.

Kind Regards,
Torsten

-- 
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/b25ad1e9-d0b9-3854-515b-e466fe215de8%40grobox.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

2016-10-15 Thread Chris Laprise

On 10/15/2016 12:56 PM, 4lgaqp+cqeepdnbinsts via qubes-users wrote:

Hi Chris,

Thanks for the suggestion.
Just to clarify, the VPN tunnel was created within the sys-firewall, and
currently that's the only proxyVM that I'm using (apart from the sys-whonix),
hence all traffic from the sys-net isn't encapsulated by the tunnel.
My understanding is that the sys-firewall merely forwards the traffic through
the sys-net by adding a forwad rule in the sys-firewall every time a new VM is
started. For that reason I was wondering if I cannot solve this more
effectively by simple adding a forwarding rule in the sys-firewall to whitelist
all traffic originated from 0.0.0.0/0 to the destination address
10.137.255.254/32 and port 8082, wouldn't this be possible?
Privacy during updates are not an issue for me, by the contrary, since this
would allow more network throughput.
I confess I'm not very keen in changing templates or creating a dedicated
proxyVm for this purpose.

Thanks

I think you mentioned you were using the 'eth0 -j DROP' rules in
FORWARD that would imply that you /are/ putting all traffic through
the tunnel. Also, your thread title says you are doing this?

Unfortunately, making exceptions to a VM that is configured to stop all
plaintext forwarding can be a bit dicey. IOW, this kind of VPN VM is
supposed to be dedicated to the purpose.

Qubes' modular style of networking allows you to make exceptions with
low risk if you use (for example) a plain sys-firewall in parallel to a
VPN VM.

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/774205fd-f688-b713-d799-d6f145d86de4%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

2016-10-15 Thread 4li11b+ehek5v7n6mpmg via qubes-users

Ok, so I tried to enable the updates proxy in the sys-firewall consequently 
forcing all updates to go through the VPN, I followed the instructions outlined 
here - https://www.qubes-os.org/doc/software-update-vm/#updates-proxy 
However, as soon as I try to run the updates on one of the vmtemplate I get the 
error "No route to host". All the templatevm has a default route to the sys-net 
(10.137.1.1), notwithstanding the update should be targeting the sys-firewall. 
Should I change the default GW of the templatevm ?! 

Thanks






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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

[qubes-users] Persistant routes on Qubes are not persistant?!

2016-10-15 Thread 4li11b+ehek5v7n6mpmg via qubes-users

Hello,

I need to add some static routes since I'm using a network with different GWs. 
For that reason I've tried to add some static routes through the NetworkManager 
which maps all the configuration into a file called qubes-uplink-eth0 . 
Strangely and since this file is within the private disk image, one would 
expect that the changes are be preserved after a reboot, unfortunately this has 
not been the case. Everytime there's a reboot the file gets overwritten 
somehow. 
Does anyone know if there's a way to preserve static routes on Qubes or is this 
simply a limitation?

Thank you






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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

Re: [qubes-users] Android development under QubesOS

2016-10-15 Thread Vít Šesták

The security of ADB over USB is rather a mystery. Since some Android version
(Jelly Bean?), Android needs confirmation of fingerprint of the host when
connecting over USB (!). Sure, even authentication of USB host has some merit,
which I am not going to discuss right now. However, when enabling network ADB,
it always used to warn that it is not secure. I've never dared to enable it.
Maybe it was some leftover warning. Maybe it just authenticates without
encryption, which might be OK for some limited purposes. Maybe the
authentication is missing or insufficient when using network ADB. (For example,
authenticating just initial handshake packets might be reasonable for some USB
threat model, but it can be hardly reasonable for network threat model.) Unless
you find some details that I was unable to find few years ago, I can hardly
consider it as secure.

Moreover, this option seems to be missing on Android 6.0.1 on BlackBerry PRIV.
Maybe it is removed by Google, maybe it is just disabled by BlackBerry.

Rather than ensuring that network ADB is secure enough, it seems to be much
simpler to use USB. If the phone resets USB when moved from one VM to another
one, there is a workaround od running ADB in the USBVM. This is surely
suboptimal for security (risks of compromising USBVM) and convenience, but it
works.

--
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/308ed035-a5e8-447f-ab55-b2a863d53ae3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Android development under QubesOS

2016-10-15 Thread Marek Marczykowski-Górecki

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Oct 15, 2016 at 08:38:58PM +0200, Alex wrote:
> On 10/15/2016 08:33 PM, York Keyser wrote:
> > Hi group,
> > 
> > I want to develop an Android application and have a special VM for
> > that and also I have a sis-USB VM. So now there is my problem, how
> > can I forward the phone over USB to my developer VM. So I am able to
> > debug on the device.
> > 
> > Somebody in the group who have already solved this kind of problem?
> > 
> > Thanks for every hint you give me Regards York
> > 
> You can do this (I do this) simply using qvm-usb in dom0, e.g.:
> 
> $ qvm-usb -a android-dev usbvm:2-3
> 
> Note that some Android phones reset their USB part when disconnected
> from dom0/usbvm, so they never show up in the AppVM.
> I've had luck with Alcatel Pixi 3 and Wiko Jerry, but there's no way of
> forwarding an Asus Zenfone 4 - it just resets itself and returns to usbvm.

You can try with ADB over TCP. I have no idea whether the connection is
encrypted or not...

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

iQEcBAEBCAAGBQJYAoGAAAoJENuP0xzK19csjo8H/2urxiVjpm8C23E5ORblhP14
E+bcLY2vzzRHi85Z0/rGZ/RQKqKCoNySeU/WjrWWNjjGPk0mLnJ+LByP58ieIhju
AlplUUCErgWkhFiZK67IbIn5SwfTQs9Sv98cKALovAz8QAbb5ASNKbup45tYJTWG
1/H/OAfcw+fyqJ32E+5OkqGr19lBtF1ZEvz95v15UkahrhaRDAGZBjvgP9mibG5r
rJKy+V2o1419j7BWIAUPyG8O95Z+phQ9lLnJcWzND/Lkd71pdumM7pCg9roEdqao
dN36pNqWrix+/+xrX1oXYPpPhCGpYaDAdEV12Wuea3TJ9VSO9oPiuxexbzTI0Fc=
=eAs6
-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/20161015192034.GZ15776%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

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

On 10/14/2016 04:06 PM, epicd...@gmail.com wrote:
> Hello, what is the difference between this implementation and just following 
> the VPN guide on the Qubes website? Both seem to create a proxyVM.
>
> https://www.qubes-os.org/doc/vpn/
>
> Is your version more leak proof, if so, how?

My version is free of firewall rule addition races, and it's easier to
deploy.

The limitation is that my work only works IF you use OpenVPN as VPN client.

-- 
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/150917ce-bb93-0d99-d929-1cd20fe794b1%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: philosofy on qubes and other environment

On 10/15/2016 01:04 PM, pleom...@gmail.com wrote:
> you never break armored ubuntu,this is fact... dont try be einstein to know 
> some way to do this.No way.
>

This e-mail in particular has caused me to burst into uncontrollable
laughter.


-- 
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/2e526571-45c3-08fb-867a-f8fd5c42ac6e%40rudd-o.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Android development under QubesOS

2016-10-15 Thread Alex

On 10/15/2016 08:33 PM, York Keyser wrote:
> Hi group,
> 
> I want to develop an Android application and have a special VM for
> that and also I have a sis-USB VM. So now there is my problem, how
> can I forward the phone over USB to my developer VM. So I am able to
> debug on the device.
> 
> Somebody in the group who have already solved this kind of problem?
> 
> Thanks for every hint you give me Regards York
> 
You can do this (I do this) simply using qvm-usb in dom0, e.g.:

$ qvm-usb -a android-dev usbvm:2-3

Note that some Android phones reset their USB part when disconnected
from dom0/usbvm, so they never show up in the AppVM.
I've had luck with Alcatel Pixi 3 and Wiko Jerry, but there's no way of
forwarding an Asus Zenfone 4 - it just resets itself and returns to usbvm.

-- 
Alex

-- 
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/61edccee-5a86-997b-844e-34f22df312ec%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Error Debian Standalone restart

2016-10-15 Thread Unman

On Fri, Oct 14, 2016 at 10:54:11PM -0700, '09348'103248'109438'019438 wrote:
> Hello,
> 
> uner QR32 an D8 standalone restart via QM is running into the error
> 
> line: assert no vm.is running()
> func: start_vm
> line_no: 1158
> 
> ??
> 
> Kind Regards
> 
It works flawlessly for me - which version of QM do you have?
Was this a clean install or an upgrade from 3.1?

-- 
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/20161015183708.GA26638%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Android development under QubesOS

2016-10-15 Thread York Keyser


Hi group,

I want to develop an Android application and have a special VM for that 
and also I have a sis-USB VM. So now there is my problem, how can I 
forward the phone over USB to my developer VM. So I am able to debug on 
the device.


Somebody in the group who have already solved this kind of problem?

Thanks for every hint you give me
Regards York

--
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/77d2ab56-602d-2e66-5ea1-702333bd7e1a%40cryptea.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't Install KB3177467 on Windows HVM Template

2016-10-15 Thread entr0py

John Marrett:
> I've been running windows template HVMs for some time now and it's working
> quite well once you get past the initial patch installation.
> 
> I now have an issue where I can't successfully install the 11/10/2016
> update to KB3177467. After each installation and the required reboot the
> patch continues to detect as uninstalled and prompt to reboot to install it.
> 
> I'd welcome any guidance people can offer and I'm ready to test possible
> solutions.
> 
> Thanks in advance for your help,
> 
> -JohnF
> 

I just checked my Windows HVM Template and it did successfully install 
KB3177467.

Sorry, I don't have any advice to offer other than the usual "check disk space, 
RAM, etc."

I am running Windows 7 SP1 with 40 GB system storage and 2 GB RAM and the old 
stable versions of Qubes 3.1 and QWT 3.0.4.

-- 
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/d351f22f-80c2-c5e9-f48e-298ee9edc977%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Unable to uptade templates affer forced all traffic trhough VPN

2016-10-15 Thread 4lgpou+6fbuwvbjmjbe8 via qubes-users

Unfortunately I overlooked the config. There's already an automatic rule that 
whitelists all VMs that are marked to 'Allow connections to Updates proxy' to 
connect to the proxy on port 8082, therefore my suggestion would not work 
(specially given the fact that the rule to block all traffic is added at very 
top of the FORWARD chain).
So is there any way to use the same mechanism to use the proxy on the sys-net 
while forwarding the traffic to the sys-firewall?






Sent using GuerrillaMail.com
Block or report abuse: 
https://www.guerrillamail.com/abuse/?a=UFR2AB5NVqcQmh2U93EQdRjCStifx8dDiadNcQ%3D%3D


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

[qubes-users] Re: philosofy on qubes and other environment

On Saturday, October 15, 2016 at 7:35:47 AM UTC-4, pleo...@gmail.com wrote:
> i realy think that is more safer Ubuntu apparmored than this qubes OS.

u can use apparmor with debian in qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ac8eb69f-572d-4ec3-af74-495fd99610dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Unable to uptade templates affer forced all traffic trhough VPN

2016-10-15 Thread Chris Laprise

On 10/15/2016 08:07 AM, 4lef7a+2cmotzqtxu8g8 via qubes-users wrote:

Hi,

I've followed this tutorial in order to force all traffic to go through the VPN
- https://www.qubes-os.org/doc/vpn/ .
While this was successful I'm no longer able to do any updates on the
templateVMs (except the whonix which are working fine), it seems that the
traffic somehow is now blocked.
Anyone knows what rule should be added to iptables in order to have this
working through the VPN?
I've dropped all forward traffic (either upstream or downstream) from the
sys-fw as suggested:

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP

Should I need to allow the forwarding traffic to and from the subnet
10.137.1.0/24 in order to have the updates working again?

Thanks

The Qubes update proxy runs in sys-net by default. Since it intercepts
requests, it has to be able to understand what the downstream VMs are
requesting. Encrypting traffic with a VPN client means the proxy in
sys-net can't update.

Workarounds:

1. Have the templates use sys-firewall instead

If privacy during updates is an issue for you...

2. Turn on the update proxy in the VPN VM (or a downstream proxyVM)...

https://www.qubes-os.org/doc/software-update-vm/#updates-proxy

3. If you have sys-whonix setup, it will already have a running update proxy

4. Reconfigure the templates to not use the update proxy

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/c40844ff-77ac-80d6-fe1e-c2849c12856c%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Can't Install KB3177467 on Windows HVM Template

2016-10-15 Thread John Marrett

I've been running windows template HVMs for some time now and it's working
quite well once you get past the initial patch installation.

I now have an issue where I can't successfully install the 11/10/2016
update to KB3177467. After each installation and the required reboot the
patch continues to detect as uninstalled and prompt to reboot to install it.

I'd welcome any guidance people can offer and I'm ready to test possible
solutions.

Thanks in advance for your help,

-JohnF

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

Re: [qubes-users] Anonymize MAC address

2016-10-15 Thread Chris Laprise


On 10/15/2016 08:59 AM, pl1...@sigaint.org wrote:

Anyone?



Instructions for MAC anonymization have just been updated:

https://www.qubes-os.org/doc/anonymizing-your-mac-address/

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/f429d0d6-14d6-7c2e-7c77-cc52ba63cb2b%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Possible to run a launcher (like Synapse) in Qubes?

2016-10-15 Thread gaikokujinkyofusho

On Saturday, October 15, 2016 at 4:18:12 AM UTC-4, pixel fairy wrote:
> On Saturday, October 15, 2016 at 4:16:23 AM UTC-4, pixel fairy wrote:
> > On Saturday, October 15, 2016 at 4:13:05 AM UTC-4, pixel fairy wrote:
> > > On Friday, October 14, 2016 at 6:43:54 PM UTC-4, Gaiko Kyofusho wrote:
> > > > given qubes separation is it possible to run something like Synapse (or 
> > > > some similar launcher) in Qubes? 
> > > > 
> > 
> > theres nothing in qubes preventing this. its already in the repo. but, its 
> > best not to add anything to dom0.
> 
> Q (upper-left) / system tools / keyboard 
> there you can add a shortcut to terminal so you dont even need your mouse to 
> pull it up.

Thanks for the ideas. I was really hoping for something "smooth" (work-flow and 
looking) like synapse or Gnome-Do _but_ not if it compromises sec and as you 
said, putting things in dom0 isn't a great idea.

This is a bit of a side question but I think its realated and given what you 
said likely has the same answer but is it possible to have a clipboard manager 
(eg clipman, kilpper, or copyq) work across VMs? The assumption is "no" but 
hope springs eternal ;)

-- 
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/05df6edc-a2f4-4e50-8ae8-0df82c78a30a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment

you never break armored ubuntu,this is fact... dont try be einstein to know 
some way to do this.No way.

-- 
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/cdb1dc56-30fe-4723-ba50-4e9c21d4c577%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Anonymize MAC address

2016-10-15 Thread pl11ty

Anyone?

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

[qubes-users] Re: philosofy on qubes and other environment

in AppVM is the same topology sys  so its posible chain logic atack.1 break 
exploit get down and other vms have the same system so its like domino.Multiple 
topology can solve this.

-- 
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/10e0ec4b-399d-403f-a71a-7cd9aa3f4901%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

On Saturday, October 15, 2016 at 7:23:12 AM UTC-4, raah...@gmail.com wrote:
> On Friday, October 14, 2016 at 11:06:48 PM UTC-4, Andrew David Wong wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2016-10-14 15:18, raahe...@gmail.com wrote:
> > > On Friday, October 14, 2016 at 6:16:16 PM UTC-4, raah...@gmail.com wrote:
> > >> On Thursday, October 13, 2016 at 2:36:30 PM UTC-4, Andrew David Wong 
> > >> wrote:
> > > 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
> > > 
> > >>
> > >> couldn't you just use a normal dispvm then?  meaning why even launch 
> > >> anything from within an appvm?  Just run it from dom0, like the default 
> > >> firefox dispvm menu item.
> > > 
> > > only reason i'd launch a program in a dispvm from within an appvm,  is to 
> > > inherit its firewall rules. 
> > > 
> > 
> > Starting a new DispVM from dom0 and setting its NetVM is a lot more 
> > labor-intensive than simply clicking a link in an email and having the rest 
> > work automatically.
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIcBAEBCgAGBQJYAZ06AAoJENtN07w5UDAwJJoQAIvVrJe8k7MWk2PxHc3sXvv/
> > C4MGgOLJ31WiZAfk1EAz/3MmVgZzG5nNII3ViDEXqGBppk7jxlF3p9UhpmMJNBju
> > xZB3z1MgVzSm5hXkHQ+enU/hv6RoO5iE+MdBSUnE9QGZiSf1Vg3xkCWzabGgjmuV
> > jGBXaRJXt1ioeBpvpke+NGwmtcd52/KJbGJLo9HRDZhBSz7us0T6e2Kh7Z9snDNe
> > mXTYpUvwriFbxnB4VEkfa52V4druYN3DWx39+nBsKZAzHSMpGfqAI7g0ZKdrLpHw
> > J8MQ4YxM1qaMZKOBQX2BOgTQs0V92255u5RiX1atVJmctYFZ4GQEdeJ/nln0I7VT
> > 86+mhkemBhzHVxvZkyPalZLi6+5INyjR8noJZpqkIsUUV50HmX0ZjG4yYPv88yTa
> > EQvglEY+/wjed9mE+M9dB73E7DLFMJr858ime5AYtDai8Baotf1bIRW5XjsxNPdf
> > h5zDU1ciEpoTYsX5O4bx4Fj+nF7+RMH5g0wC/o0/9A/3ougqEQ+9/sn7CWWBnPgA
> > Ucv4c7sd9A3zU80PYy1RSZiW2MxdTkKNMD+rCL97JaeKgUxHWLE2M6wPQbkMRl9d
> > XmbVBZpsj97ifpasDRRmA/zIeDqZT+Fg7F6GhuIyRUV2ym0UT8VvqOznp3Znvaj6
> > 9RV4PZn2lL6pywgVQfY2
> > =BVEY
> > -END PGP SIGNATURE-
> 
> oh yes absolutely, especially for email links for sure thats awesome.  But I 
> thought the OP was asking how *not to inherit firewall rules in general.  So 
> i was just suggesting why even bother opening it in specific appvms anyways 
> then.

xfce is a little frustrating cause you need a 3rd party tool to easily create 
menu entries like in kde to launch diff programs with while inheriting firewall 
rules.  but i'm leary to install one to dom0 so I just gave up and type it out. 
 rather do that then edit the cfg file lol.

-- 
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/e1a92e5e-799c-4f54-b9b3-ef23b44f2872%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

On Friday, October 14, 2016 at 11:06:48 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2016-10-14 15:18, raahe...@gmail.com wrote:
> > On Friday, October 14, 2016 at 6:16:16 PM UTC-4, raah...@gmail.com wrote:
> >> On Thursday, October 13, 2016 at 2:36:30 PM UTC-4, Andrew David Wong wrote:
> > 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
> > 
> >>
> >> couldn't you just use a normal dispvm then?  meaning why even launch 
> >> anything from within an appvm?  Just run it from dom0, like the default 
> >> firefox dispvm menu item.
> > 
> > only reason i'd launch a program in a dispvm from within an appvm,  is to 
> > inherit its firewall rules. 
> > 
> 
> Starting a new DispVM from dom0 and setting its NetVM is a lot more 
> labor-intensive than simply clicking a link in an email and having the rest 
> work automatically.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJYAZ06AAoJENtN07w5UDAwJJoQAIvVrJe8k7MWk2PxHc3sXvv/
> C4MGgOLJ31WiZAfk1EAz/3MmVgZzG5nNII3ViDEXqGBppk7jxlF3p9UhpmMJNBju
> xZB3z1MgVzSm5hXkHQ+enU/hv6RoO5iE+MdBSUnE9QGZiSf1Vg3xkCWzabGgjmuV
> jGBXaRJXt1ioeBpvpke+NGwmtcd52/KJbGJLo9HRDZhBSz7us0T6e2Kh7Z9snDNe
> mXTYpUvwriFbxnB4VEkfa52V4druYN3DWx39+nBsKZAzHSMpGfqAI7g0ZKdrLpHw
> J8MQ4YxM1qaMZKOBQX2BOgTQs0V92255u5RiX1atVJmctYFZ4GQEdeJ/nln0I7VT
> 86+mhkemBhzHVxvZkyPalZLi6+5INyjR8noJZpqkIsUUV50HmX0ZjG4yYPv88yTa
> EQvglEY+/wjed9mE+M9dB73E7DLFMJr858ime5AYtDai8Baotf1bIRW5XjsxNPdf
> h5zDU1ciEpoTYsX5O4bx4Fj+nF7+RMH5g0wC/o0/9A/3ougqEQ+9/sn7CWWBnPgA
> Ucv4c7sd9A3zU80PYy1RSZiW2MxdTkKNMD+rCL97JaeKgUxHWLE2M6wPQbkMRl9d
> XmbVBZpsj97ifpasDRRmA/zIeDqZT+Fg7F6GhuIyRUV2ym0UT8VvqOznp3Znvaj6
> 9RV4PZn2lL6pywgVQfY2
> =BVEY
> -END PGP SIGNATURE-

oh yes absolutely, especially for email links for sure thats awesome.  But I 
thought the OP was asking how *not to inherit firewall rules in general.  So i 
was just suggesting why even bother opening it in specific appvms anyways then. 

-- 
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/ad541753-69e1-431c-aedb-99c609bc787a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: philosofy on qubes and other environment