date:20161112

you want to copy the file from your work VM to the fedora-23 template and then 
install all with terminal?

1)open terminal in your workVM
2)ls (useful to lists directories/files)
3)cd Downloads (or where ever you saved it)
4)qvm-copy-to-vm "DestinationVM" filename

https://www.qubes-os.org/doc/vm-tools/qvm-copy-to-vm/

4)sudo dnf install /path/to/package.rpm
(path will likely be /home/user/QubesIncoming/nameofsendingVM)


That should get libreoffice installed for you.

-- 
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/4092697e-5e91-4a91-843b-78244239d6f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Fedora 24 template available for Qubes 3.2

> Yes, it is also available - as noted in the message.

And i read too quickly, doh :o)

Look forward to taking 24 for a spin.

-- 
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/5c1147ea-f2e9-4702-82b6-24ded29b7197%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Genymotion in Qubes

2016-11-12 Thread entr0py

Sec Tester:
> pl1...@sigaint.org:
>> Good day
>> I want to install an android emulator in Qubes and reading some review,
>> Genymotion is the best. The issue is that it run in Virtualbox, how can I
>> install it in Qubes?
>> 
>> Thanks
>> 
> Nice question. I would also like to know.
> 
> Have you setup a Win7 HVM?
> 
> This maybe be the best place to try setup Genymotion.
> 

https://www.genymotion.com/faq/

May be theoretically possible but not for the faint-of-heart.

You would need to patch Xen to allow nested HVM, then use VGA-passthrough to 
give Genymotion a GPU.

Android on Qubes is not well supported (and probably shouldn't be).

There is a current thread discussing Android-x86 / RemixOS:
https://groups.google.com/forum/#!topic/qubes-users/frK8xaBh9pI

and Github issue:
https://github.com/QubesOS/qubes-issues/issues/2233

-- 
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/f871c8ab-27e8-8509-c5fd-d93e9c44bd19%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.


> > This might add significant time to the install, but could be a tick box 
> > option, with a note about extra time.
> 
> I think a better practice along these lines is to supply the additional 
> packages needed to create a desktop-friendly template... alongside the 
> minimal template. This would take a *little* extra time during installation.
> 
> Another option would be to simply provide a script that purges all the 
> packages that are unneeded for a minimal template.
> 

Good suggestion. A script that shrinks templates into minimals. I like this 
idea. A script could then also create a min debian template too.

I just had a look inside the Qubes-R3.2-x86_64.iso
I found the templates under packages/q

I wonder if a script could also be used to turn a whonix-ws into a whonix-gw or 
vise versa. This could reduce the size of the Qubes.iso by about 500mb. making 
more room for other goodies.

-- 
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/b358c399-fb50-4632-a582-922a30b44199%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Arch-template and Firefox (49.0.2)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Nov 10, 2016 at 02:21:38PM +0100, Marek Marczykowski-Górecki wrote:
> On Thu, Nov 03, 2016 at 08:17:18PM +0100, Achim Patzner wrote:
> > Hi!
> > 
> > 
> > I just tried moving my main working environments from the Fedora
> > template to Arch. All in all a much better user experience for nearly
> > everything besides one thing: Firefox tabs are constantly crashing. If
> > I'm opening the same URLs on a native Arch installation or other
> > templates the contents is displayed without any problems. Am I the only
> > one with that problem?
> > 
> > 
> > And no, no plugins installed at all.
> > 
> > 
> > Besides that: I could live without ever getiing a Ubuntu (or lookalike)
> > template but it might be time to adopt the Arch template (even if that
> > means the debian template was dropped completely). (Marek: What could we
> > offer to convince a core developer that he always wanted to do this?)
> 
> http://explosm.net/comics/2243/
> 
> In short: more people to help with handling those over 500 issues on
> github already. Then we can think of something possibly resulting in
> more issues to handle.
> 
> That's said, I've pointed template builder at config with
> BUILDER_PLUGINS+=builder-archlinux and tried to build it - to have it in
> qubes-templates-community repository. Every package uploaded to official
> repository is built in Disposable VM connected through Tor - to minimize
> risk of targeted attacks. After roughly hundred tries I gave up - it
> failed every time on downloading some package, which fails the whole
> build. If someone know how to convince pacman to retry failed downloads,
> that would help. Pull request to builder-archlinux would be even better
> ;)

Ok, I've changed pacman mirror (echo PACMAN_MIRROR=mirrors.kernel.org >>
builder.conf) and it worked at third try. This means:

qubes-template-archlinux package is available qubes-templates-community 
repository!

I haven't tested it in any way. It include only what builder-archlinux
scripts does - especially powerpill (or some other mean to use updates
proxy) still needs to be configured manually:
https://www.qubes-os.org/doc/templates/archlinux/#package-manager-proxy-setup-section

Further work include:
 - test it out
 - automate powerpill setup (probably as part of core-agent-linux
   repository - some post-installation script or such)
 - adjust https://www.qubes-os.org/doc/templates/archlinux/
 - write some separate announcement(?)

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

iQEcBAEBCAAGBQJYJ+tfAAoJENuP0xzK19csmPoH/jXvtYSMYp3eH0UEOWtjoKdM
JsNqu4MfQlxosARHjxtUqeBBHGRBIK1RLnZAjFvxPKAyOLsHKr3zk81ZhDzMNJZQ
gjo4OTCX9/4x7pJ3A0VhPQOkFId337gQgSQdL6ymofJHYIKpq3gUVE2OakY9Fcmh
0kMxWlmWIOdk3udUVLmpFPA+1ss6kRrolkRxMh/u9JYv6mwHb+QuWD9ZGJX7NAgg
b784vlfHE22qpr+bymUp+EjOJbxh6nhHsdv9SyGLCQsZLjyS0jGsj6l61SENEjvP
Ae8KzYRXqdYY5bNMh9rB00lVRFCF4iqXcrFqn6zS5wNKl8rUReOgV4dAE9blGx0=
=MBCn
-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/20161113042606.GE15162%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Fedora 24 template available for Qubes 3.2

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Nov 12, 2016 at 08:01:37PM -0800, Sec Tester wrote:
> NICE!!
> 
> Any specific improvements or fixes running Fedora-24?

Nothing specific to Qubes, see upstream release notes for non-Qubes
changes:
https://docs.fedoraproject.org/en-US/Fedora/24/html/Release_Notes/

> I noticed F-23 seemed to have trouble playing flash videos for me.
> 
> F-24 Min template coming?

Yes, it is also available - as noted in the message.

> A Deb-8 min template would also be nice :)

Actually, default debian-8 template is already pretty minimal.

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

iQEcBAEBCAAGBQJYJ+fSAAoJENuP0xzK19cs4MwIAIp8qjAWDJjAJiOhuZrYf4F4
Dz78ytaBP9u0wEDGRwGJ6qoEIFH2mPX3Ktt94Grc0995P2cI9ORBFYNYCyXyBncJ
/jfBlI2Tr2xyfOfXUi3WEwXiNoG3Ef1U23gmeStn8mKvrQa0KNm3xP0rXNI+fO1I
Y1bM3jvTjAOqg/cm2eubNYbaeKOKitvmLT7GeL9OsSdRG+YTiL/5y1lXC1ycwscj
wpIkdbM6uSFmwk0FwbjxsHkCz2ZsRmMb0svQa2O7axbFmvSwcpcRurjKcsiFw2DR
fJA5t+QJz1HlTIgamzbqDzj9kCcceWy8ijrXYZXn3UlIXSqN2q0iQUhYSfxW3R4=
=Cekd
-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/20161113041056.GS7073%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Fedora 24 template available for Qubes 3.2

NICE!!

Any specific improvements or fixes running Fedora-24?

I noticed F-23 seemed to have trouble playing flash videos for me.

F-24 Min template coming?
A Deb-8 min template would also be nice :)

-- 
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/b899644a-927c-4c07-bf0d-a5667c4a2b72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Fedora 24 template available for Qubes 3.2

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi all,

Fedora 24 template is now available for direct installation. This means
there are now two ways to have it on Qubes 3.2 system:

1. Upgrade existing Fedora 23 template according to this instruction:

https://www.qubes-os.org/doc/fedora-template-upgrade-23/

2. Install a fresh one using:

qubes-dom0-update qubes-template-fedora-24

The later option will get you fresh template. If you made any
modifications there, you'll need to do them again (if you want).
The same is available for fedora-24-minimal template.

In any case, after getting new template using any method, the next step
is switching some/all qubes (VMs) to the new one. This can be done using
either Qubes Manager (in qube settings), or using qvm-prefs command line
tool.

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

iQEcBAEBCAAGBQJYJ+OXAAoJENuP0xzK19csWa8H/RqO4RjNVeeIEb7s8KRgUMzg
VjQUOrC5YmirnFACrq7t8VDZxbcvSrQ88pifMsIKZYzAzfIHa2s3O6m9XzkDetQO
+of7iUIQaijlec5BKkCGM+3cP3zQSHyrCdb6udOEzYkkSLkeWaYoC6+F/dPrFLVx
1Wb2pNeUY0eWGuL64/WjpozpUGXKtD1tp1RbFv7cqVdF530THVXX+W7g3fp6zmUS
k4goQv0rjhdlhWr9ZYwvlUbGRMpJHaIix4Q4ajXNToVnql69fZxGhhSOtPwBasGe
j4TIbyTKr01a0mQn6mIa+MKkS19H8RwLpu+25EaOlmd2f91vVO8IJrPBSmwvZ84=
=+DPm
-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/20161113035254.GD15162%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock


On 11/12/2016 05:47 PM, hed...@tutanota.com wrote:


I guess the question still stands: is the latest version materially 
superior to the March 2015 version? (And enough to want to re-create 
over a dozen proxyVMs?)


Yes, the VPN doc method is better in the sense that it separates packets 
generated from the VPN VM from the packets going to/from appVMs. So 
accidental net access generated while using the VPN CLI, for example, 
will be blocked and stay out of the VPN tunnel. Its not critical but 
Whonix people wanted it as a precaution.


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/bad5c927-bb5c-65aa-c9a7-6111d0aed002%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

On 11/12/2016 07:48 PM, Sec Tester wrote:

Hi Marek,

On Sunday, 13 November 2016 03:33:50 UTC+10, Marek Marczykowski-Górecki wrote:

They have basically said, Elite hackers can gain root, so lets just not even
bother with this foundational layer of security.

The point is _if_ someone is able to run arbitrary code as user, he/she
can easily run it also as root, because of tremendous attack surface of
linux kernel and all the services running as root. In the worst case one
needs some patience and simply wait for you to authorize some command to
be ran as root (regardless of authorization method - password, qrexec
confirmation as described on https://www.qubes-os.org/doc/vm-sudo/ or
anything else). In the simplest case one may alias 'sudo' to for
example 'sudo /tmp/my-evil-script'.

Thats why i would like to see root pw + selinux together in Qubes VMs.

On the other hand, making it harder to execute arbitrary code in the VM
(reducing attack surface) makes sense. Things like SELinux, AppArmor,
seecomp filters etc.
Take a look at SubgraphOS + QubesOS thread here for more details:
https://secure-os.org/pipermail/desktops/2015-October/02.html

This sounds FANTASTIC!!
Definitely adds those extra layers of protection i was talking about. I hope
Qubes consider this in the future.

Yes, this mostly makes sense. As for out of the box configuration we're
somehow limited by installation image size. Now it barely fits on DVD
(which also means a lot to download). Adding another Linux-based
template means another few hundreds MBs.
Using unikernel may help here (see MirageOS for firewallVM). It is still
not mature enough to have it in default installation, but I hope it will
be some day. It's hard to do the same with sys-net, because the need for
all the hardware support...

Install size is a valid restriction.
Could the install process not compile a minimal templates from the standard
fedora-23 template?

This might add significant time to the install, but could be a tick box option,
with a note about extra time.

I think a better practice along these lines is to supply the additional
packages needed to create a desktop-friendly template... alongside the
minimal template. This would take a *little* extra time during installation.

Another option would be to simply provide a script that purges all the
packages that are unneeded for a minimal template.

Again - this may be useful for some, but not as part of default
installation image. In some cases this may be even harmful, see here:
https://groups.google.com/d/msgid/qubes-devel/80a370cd-7868-5c2a-e0ff-c9b05a569f10%40gmail.com

I agree that this doesn't need to be an out of the box feature. But would be
nice to be able to implement. glad to see issue has already been raised.

The file copy protocol is specifically designed the way to avoid
immediate target compromise if you copy a file there. For example files
are always placed in directory named after source VM name. I hope it's
obvious enough to not blindly click on files from
"QubesIncoming/untrusted" directory in your template...

So QubesIncoming container makes self executing code impossible? eg worms etc
If so then an attacker may try to infect the users ligitmate files with a Parasitic
virus, that will be copied & opened at some point.

My point is this kind of activity can currently go on inside our VMs unopposed.
There are currntly no preventative layers of security inside VMs. Which is the
perfect enviroment to execute attacks on dom0, or infect user & system files.

We even consider getting rid of this confirmation in file copy at all:
https://github.com/QubesOS/qubes-issues/issues/2280

CRAZY.

IMO if people want a "windows" experience where everything runs as admin, and
security is dropped in the name of convince, then they belong on windows.

The demographic that are interested in Qubes OS are security & privacy focused.
Honestly if things could transfer between VMs without authorization, then what is
the point of even having seperate VMs? and thus even running Qubes?

That's probably not happening anyway. It would make people paranoid
about enabling the prompts over and over for VMs that are created, and
there is no way to guarantee that 'certain' VMs have integrity to do
this by default.

Hi Chris,

Its easy to enable apparmor. See the Whonix documentation about this.

I will have a look thanks. I have read that AppArmor isnt as robust as SELinux,
but IMO an extra layer of security is better than none.

Therefore, I think it is up to the community to promote the Linux extra
security measures as a kind of add-on. Enabling it could be a good thing
IF and only if we can do it with minimal effort and distraction. But
keep it far away from pre-installed or supported status.

Well how hard is it really to at least provide the option of root password
protection for VM's?

Say a check box in the VM settings that let dom0 know this VM needs a

Re: [qubes-users] Re: #2 .odt files and LibreOffice Install

Can someone provide me with the terminal commands (from template: fedoara-23) 
to receive the downloaded LibreOffice install file 
(LibreOffice_5.2.3_Linux_x86-64_rpm.tar.gz) from the [work: web browser] 
Downloads, and then run the installation script?



Alternatively, could you provide the terminal commands from [work] domain to 
the Fedora-23 template?

-- 
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/VUCbr-8AtmVj6XxtVmqXrRmIwirbNnyNiyvX6bQRFdsmSBDJEn3wfAkvTMpniCK95QlSXhj2IXZxbATK_GHJAjAlI4P5h5gYevMWSMBeKGQ%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Genymotion in Qubes

Nice question. I would also like to know.

Have you setup a Win7 HVM?

This maybe be the best place to try setup Genymotion.

-- 
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/fda74214-2db6-48f7-b81a-bf90683697e3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

Hi Marek,

>On Sunday, 13 November 2016 03:33:50 UTC+10, Marek Marczykowski-Górecki  wrote:
> > They have basically said, Elite hackers can gain root, so lets just not 
> > even bother with this foundational layer of security.
> 
> The point is _if_ someone is able to run arbitrary code as user, he/she
> can easily run it also as root, because of tremendous attack surface of
> linux kernel and all the services running as root. In the worst case one
> needs some patience and simply wait for you to authorize some command to
> be ran as root (regardless of authorization method - password, qrexec
> confirmation as described on https://www.qubes-os.org/doc/vm-sudo/ or
> anything else).  In the simplest case one may alias 'sudo' to for
> example 'sudo /tmp/my-evil-script'.

Thats why i would like to see root pw + selinux together in Qubes VMs.

> On the other hand, making it harder to execute arbitrary code in the VM
> (reducing attack surface) makes sense. Things like SELinux, AppArmor,
> seecomp filters etc.
> Take a look at SubgraphOS + QubesOS thread here for more details:
> https://secure-os.org/pipermail/desktops/2015-October/02.html

This sounds FANTASTIC!!
Definitely adds those extra layers of protection i was talking about. I hope 
Qubes consider this in the future.

> Yes, this mostly makes sense. As for out of the box configuration we're
> somehow limited by installation image size. Now it barely fits on DVD
> (which also means a lot to download). Adding another Linux-based
> template means another few hundreds MBs.
> Using unikernel may help here (see MirageOS for firewallVM). It is still
> not mature enough to have it in default installation, but I hope it will
> be some day. It's hard to do the same with sys-net, because the need for
> all the hardware support...

Install size is a valid restriction.
Could the install process not compile a minimal templates from the standard 
fedora-23 template?

This might add significant time to the install, but could be a tick box option, 
with a note about extra time.

> 
> Again - this may be useful for some, but not as part of default
> installation image. In some cases this may be even harmful, see here:
> https://groups.google.com/d/msgid/qubes-devel/80a370cd-7868-5c2a-e0ff-c9b05a569f10%40gmail.com

I agree that this doesn't need to be an out of the box feature. But would be 
nice to be able to implement. glad to see issue has already been raised.

> The file copy protocol is specifically designed the way to avoid
> immediate target compromise if you copy a file there. For example files
> are always placed in directory named after source VM name. I hope it's
> obvious enough to not blindly click on files from
> "QubesIncoming/untrusted" directory in your template...

So QubesIncoming container makes self executing code impossible? eg worms etc
If so then an attacker may try to infect the users ligitmate files with a 
Parasitic virus, that will be copied & opened at some point.

My point is this kind of activity can currently go on inside our VMs unopposed. 
There are currntly no preventative layers of security inside VMs. Which is the 
perfect enviroment to execute attacks on dom0, or infect user & system files. 

> We even consider getting rid of this confirmation in file copy at all:
> https://github.com/QubesOS/qubes-issues/issues/2280

CRAZY.
IMO if people want a "windows" experience where everything runs as admin, and 
security is dropped in the name of convince, then they belong on windows.

The demographic that are interested in Qubes OS are security & privacy focused. 
Honestly if things could transfer between VMs without authorization, then what 
is the point of even having seperate VMs? and thus even running Qubes?

Hi Chris,

> Its easy to enable apparmor. See the Whonix documentation about this.
> 
I will have a look thanks. I have read that AppArmor isnt as robust as SELinux, 
but IMO an extra layer of security is better than none.

> Therefore, I think it is up to the community to promote the Linux extra 
> security measures as a kind of add-on. Enabling it could be a good thing 
> IF and only if we can do it with minimal effort and distraction. But 
> keep it far away from pre-installed or supported status.

Well how hard is it really to at least provide the option of root password 
protection for VM's?

Say a check box in the VM settings that let dom0 know this VM needs a password 
before trying to update it.

> I will say this is fair.
> 
> Even so, the attackers have to find an exploit for the apps you're 
> using. The apps are already designed by default not to grant access. But 
> they have large surface area and Linux could help reduce it somewhat. 
> Throwing a chair in the path of your attacker (and warding off the 
> percentage of attackers that can't deal with chairs) is a good thing.

The "chair" from my reading actually Stops the Majority of attacks.

I read a whitepaper that showed just by NOT

[qubes-users] Screen blanks instead of power off

2016-11-12 Thread taii...@gmx.com

I have tried all the options in the power control menu but my screen 
still doesn't turn off it just disconnects the output so the screen will 
say "NO VGA/DVI DETECTED" when power save mode turns on.


Ideas?

--
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/0d476cac-9776-4108-c1c3-3a37a9f85661%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: #2 .odt files and LibreOffice Install

2016-11-12 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-11-12 04:28, 'IntersolarMN' via qubes-users wrote:
>> Your trying to modify the fedora-23 template correct? Yes.
>> Is sys-firewall specified as its net VM? Yes.
>> Do your other app VM's have internet access? Yes.
>> Does sys-firewall have sys-net set as its "NetVM"? Yes.
>> Sys-net and Sys-firewall pings to Google both were successful.
>> After restarting Qubes, launching fedora-23 terminal, and then running sudo 
>> dnf install libreoffice, the command eventually lead to the following 
>> message:
> Error: Error downloading packages: Cannot download 
> l/libreoffice-core-5.0.6.2-10.fc23.x86_64.rpm: All mirrors were tried
> (Also note that during additional attempts of re-running the sudo command, 
> various other errors would appear including "Failed to synchronize cache for 
> repo 'updates')

In your template's VM Settings, on the Firewall rules tab, make sure "Allow 
connections to Updates Proxy" is checked, then try again.

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

iQIcBAEBCgAGBQJYJ6SWAAoJENtN07w5UDAwn2EP+wfBqmv77ojix+/bOZ63bnhG
0dGo0cC4ju70h1nipX07DhJVMLpJl1s0pkRfS/OiegkfStZScoqmY1n03csKzsL/
f+NGBbqOjm15f1K2WJBmg/09nAxw3PE75cYvvtS847d2DITlxfYXTs9N+w4fQFeK
WaGvOzJ3XLLWsACDBJDGOX4rTU4X9RWc6WkK5AJQUjl8yFBmoVfNJQ5tw3rSYE2d
tx4Of95Nz3AIMBVYpHBUPGJbHEYlt1mJUsK6gzCAaZGtQWhHErMI5MWIzCSphYxO
JUKwFo/OH9qhTPxEmpn0WesBLSQpZSV1ZHYZfzk+wtNoBvJ7di5uLzc90YGp/lbt
POwP/GV0ZbFyCZvmchuD9DidJbMlrRjNEPqpgPckJI1nN4kjP+57NYjrN5HUa6mE
h/gpDucI+g+AlEfIpeNAg70UyBR/rhTUgq1EONg44+7ufUhD4AsQlluxiSiu0P0i
JZMDlAkUQ6eSsNTvaPG2z5mAxaBY0wsnV0BMw0fw3CaC/bbPTy+hm87NWUfSaHA8
LFTjZddHjt614odfie5zkZLTyvK1qn3jqT2GH1KRnimjyj4Bzf4si8ezM6Yb0Vlc
cHtORgEzd4lVOxwR7G+Ytug+lskk9+58l8T8e6Le4afTcViaGnB92kZCA9l33zyL
00sWlxR5I9DFCA4RvStn
=XT97
-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/614e3d92-e2b5-69c4-8f81-b8aa94cad419%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Use YubiKey for Anti-Evil-Maid?

2016-11-12 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-11-12 12:07, Eric wrote:
> Is there any way to use a YubiKey for Anti-Evil-Maid, instead of just a 
> regular USB flash drive?

AFAIK, yes, but I haven't personally tried it, since I don't own a YubiKey.

> I imagine (though I will be the first to say that I don't know), that the 
> firmware on it is much less resistant to compromise/BadUSB attacks, and since 
> it crypto something something, it seems a natural fit.
> 

There are, indeed, security considerations regarding the choice of medium for 
an AEM drive. Take a look at this issue:

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

And this associated discussion thread:

https://groups.google.com/d/topic/qubes-users/I5clx1E-S9M/discussion

> Of course, I haven't seen the code for AEM,

Why "of course"? The source code is freely available for all to see:

https://github.com/QubesOS/qubes-antievilmaid

> and I know that it's a program instead of just a keyfile. Is there any 
> possibility of two factor authentication for anti-evil-maid? IE, passphrase 
> and a YubiKey?
> 

Well, there's been some work done on using a YubiKey as a second factor for 
logging in to Qubes, but it's for the lock screen, not for AEM:

https://www.qubes-os.org/doc/yubi-key/

I'm not sure if it'd be possible to do with AEM, since that prompt is so early 
in the boot process.

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

iQIcBAEBCgAGBQJYJ6NoAAoJENtN07w5UDAwihQP/1MF4QStLEXh2WaTQ9rWaICC
ytB/kpujfvGvATB23/OkQ3qGElziBVQ308FYWXIs2HGHSteJPeH2Wx0EYpWjUgtf
6GgkVMjcQRFmIzbl29ZvcftrF1YhdV6HRHy+/DmdEAwfGu6sl4FHnoUV0/R2EaSf
AhbUpM4u0Y5G9ecqUz/lOVlvnKbX5UBuwE6gDPNEdMgHq6rVU28TsSw581UHxi/c
RmBEagnoZfYutVLNYTGOM/wDUgGAUDsZprD0DYurFdwWp4Mut2SQYqOFRcEucpdX
Cympsp8mzQf19LLgmjrYEALMbO+HL7XYa6mly1eWoPErWgJpMWpP3D1W3y1wYVm3
On6wB3rDZnCxoQUls9jgdQjyS9QI4Fu4d0UZD6EkO+K5XR8cdwrnl/1nkJGq6nK6
kio5gp2DiNz2WMbpzKh7HHGh5qPD14xHuLRxHzPw/pp0xCcKF/WBAo9NhXheh6sl
mBHAlEMdlc0nB5M8YjcAfaluCEsNz7mA+fEBGKV28UNJsGyUub0wY6LbQVXGBxSx
6bjvVWr9QE12RuqmV9NPOilFGmznmJ7Ml9zwnkOd2cgBuGSIjF2Skp9ag/Pv+cOY
bulkrJnb8+8Wdvt5d7H9wXvjYOum9OeY7rhIYmKpXtLK8D4YjL2sOuS0vJ3aH+Mx
xmqQWHd5VjaFE1lWL+21
=AsT6
-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/22e0f325-f64f-598d-e2c2-5c1dbc580584%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock

2016-11-12 Thread hedron




12. Nov 2016 20:39 by tas...@openmailbox.org:


>
> By 'template' you mean the setup at my github repo? If you look closely, they 
> are 90% the same except the doc version uses rc.local to start the client and 
> the one on github creates a systemd service for it. What makes it look 
> simpler is the github readme says 'download the file, unzip in /rw/config and 
> adjust the ovpn settings' and doesn't show script code.
>
> Chris




No, it didn't come from github. After a brief search, I found the thread that 
was the source I used: 
https://groups.google.com/forum/#!msg/qubes-users/-9gR1Va3BnY/nQG6j-YOtZ4J;context-place=topic/qubes-users/T0wbCuIgISg
  which dates from March 2015. The author was cprise, so I was wrong to 
attribute it to Chris Laprise, though the names do seem suspiciously similar. ;)




I guess the question still stands: is the latest version materially superior to 
the March 2015 version? (And enough to want to re-create over a dozen proxyVMs?)

-- 
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/KWPiIRQ--3-0%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] [feature request] Shutdown template after update

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Nov 08, 2016 at 01:07:38AM -0800, Andrew David Wong wrote:
> On 2016-11-07 10:05, Eva Star wrote:
> > After template updated ask user at the console to shutdown current template.
> > 
> > "Shutdown current template [Y/n]"
> > 
> 
> Currently tracking a very similar suggestion here:
> 
> https://github.com/QubesOS/qubes-issues/issues/832

Indeed this is similar, but not the same because it does matter when you
shutdown the template - until you do so, child VMs do not see the
changes.

Created new issue here:
https://github.com/QubesOS/qubes-issues/issues/2431

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

iQEcBAEBCAAGBQJYJ4nRAAoJENuP0xzK19csKJYH/232f3ts6oGOcVDvnqubDaEI
NFSENa+ovKD9v7ZQjVmd0bdWlj7vH8HfhzCgzJZzFR0qLZb5sBHKmE1o3iqEkiYf
HYi3WBKNgu7YtGhmS8iGLnBilSuJYjAyiaAzvVRbEHc8WFuy04U42lPzKSo/GMj6
FQxLXU/1lVz8TmwKVRkmVq+VuOxkO4OS58STu2PW5pKn3B1nx+qREzhNURhybYSV
d4zgGQmvztNk88PG2sppnQAeYprqgR+fINwLqjPu8Mg7DfW2kb6EIpcFMJbNGqb3
WvV1ZmNPeIMAtzv8rvlvPE80niEOBsU0UDiTJ6T0YMlMBt/LnhEJeSX3yj2fm8o=
=5wOE
-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/20161112212951.GC15162%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

On 11/11/2016 10:21 PM, Sec Tester wrote:

So Im still new to Qubes, but after going through a bit of a learning curve,
building & customizing VM's to suit my security needs, I have a few thoughts on
its security.

Firstly I really love the direction Qubes has taken the future of operating
systems, and its has definitely become my OS of choice.

HOWEVER, i feel that Qubes OS relies HEAVILY on ONE security mechanism >
Isolation.

There are 2 ways we can improve security

1. But adding layers of protection.
2. By reducing the attack surface area.

Layers of protection

In regards to layers of protection, IMO Qubes only has one. By isolating VM's if a
system is infected, it has to breach that VM & gain access to dom0, where it
then has total control of the system.

The problem is in the current configuration, there is nothing to stop a hacker
or malicious software from running, manipulating VM system files, or
downloading additional hack tools/scripts to attempt to breach into dom0.

To basic extra layers of protection missing from Qubes that usually hardens
Linux security are;
Password protected root access on VM's
SELinux or AppArmor.

Its easy to enable apparmor. See the Whonix documentation about this.

I have read Qubes excuse for NOT requiring a password for root access in
VM'shttps://www.qubes-os.org/doc/vm-sudo/

I frankly think saying "its highly unlikely if that person (who could breach a VM to
dom0) couldn't also find a user-to-root escalation in VM" as a very LAZY
justification.

That was my first reaction, too. But years later, I am so, s glad
ITL de-emphasized kernel-based security.

If they had kept it as a supported security layer, the
"security-in-depth" mindset would have dominated most of our discussions
and attention... essentially eaten our brains like it does to everyone
else. Seriously, this stuff can be perniciously misleading, and the
moment that "authoritative" voices in the community start looking down
their noses at "dinky little 1MB hypervisor" compared with their heavy
bookshelves full of standard admin guides and certifications... that's
when the security zombies start encroaching.

They have basically said, Elite hackers can gain root, so lets just not even
bother with this foundational layer of security.

Already... "foundational"... NO.

So we have VM's where any script kiddies code can run riot. This to me is over
confidence in VM isolation, and a lax attitude because, hey if your infected you
can just reboot & VM is clean again right? Except the infected files sitting in
the home directory, just waiting to be opened again and run with root permissions.

I will say this is fair.

Even so, the attackers have to find an exploit for the apps you're
using. The apps are already designed by default not to grant access. But
they have large surface area and Linux could help reduce it somewhat.
Throwing a chair in the path of your attacker (and warding off the
percentage of attackers that can't deal with chairs) is a good thing.

And in the example of a server VM, that system may rarely be rebooted very
often? Infecting the system to infect others that connect to that server. NOT
GOOD.

>From what i've read SELinux isn't running do to some compatibility errors, and
because there is no point when the whole system has root access. Well lets lock down
default VM root access, and lets find a way to make SELinux work in Qubes VMs &
even dom0, or possibly AppArmor. Or maybe we need a totally new piece of software that
is Qubes specific.

The more layers of security in the system the better.

IIRC, SELinux isn't held in high regard these days. Doubt people will
get enthusiastic about it.

Reducing the attack surface area

Qubes OS through the use of dom0 has reduced the attack surface area of the
kernel, which is good.

However, where i think Qubes could improve right out of the box, is having
dedicated minimized templates for sys-net & sys-firewall.

When you think about what a dedicated firewall does, the risk is very
low. I don't think it really sacrifices any security to share a template
with sys-net.

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/45ccbf60-9ee9-4164-e3a4-c2f41200bcee%40openmailbox.org.
For more

[qubes-users] Genymotion in Qubes

2016-11-12 Thread pl11ty

Good day
I want to install an android emulator in Qubes and reading some review,
Genymotion is the best. The issue is that it run in Virtualbox, how can I
install it in Qubes?

Thanks

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

Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock

On 11/12/2016 06:26 AM, David Hobach wrote:

> I would also advise users *not* to
> rely on firewall settings in Qubes Manager/VM Settings as the options
> are too limited to stop compromised VMs that are supposed to be
confined
> to the VPN tunnel from leaking data to clearnet (e.g. a hostile
access

> point or other upstream node) regardless of which address/port you
specify.

Can you please explain that in a more detailed way?

Currently I disagree as I don't see a way to leak anything if the user
employs the Qubes Firewall for the proxy VM to only allow access to
his VPN gateway IPs (preferably not hostnames) and disallows
everything else (incl. DNS); in particular nothing is leaked when the
VPN is down.

This approach might not work for all VPN providers as some e.g. do
load balancing via DNS or other tricks, but for some it does. For the
others, yes, Qubes Firewall might be too limited.

People often use VPNs to safely access the Internet through Wifi access
points and routers and ISPs that are hostile. If the VPN-connected appVM
is compromised it could search for the VPN IP address in order to send
cleartext to the router. All of the known VPN addresses in the world
could very easily be programmed into the malware, as this search space
is tiny compared to the number of IPv4 addresses.

Assuming your VPN setup was not compromised the infrastructure being
used does not matter - even if it's potentially hostile (most of it
should actually be assumed to be hostile). Due to the beauties of
cryptography there's a tunnel between your proxy VM and your VPN exit
node as if there was a fixed line. And yes, your appvm using that
proxyVM can obviously find your VPN exit node IP by checking its IP
with whatever public service. And then what?
It cannot communicate outside of that tunnel as Qubes makes sure it
cannot use anything else than your proxy VPN VM; so I don't see how it
should identify your ISP IP address (except for maybe state-level
attacks such as netflow pattern analysis on a global scale).

If the VPN VM isn't internally restricting all forwarding, and VM
firewall settings (upstream proxyVM) is filtering by IP address, then a
compromised downstream appVM can send packets to the server IP that are
crafted to go around the tunnel. The most famous example of this is DNS
packets. People complain about them leaking all the time. On Qubes, DNS
is dnat-ed to a set address, but having this set properly depends on a
trigger from the VPN client... which may have failed. The system should
also be setup to prevent leaks if the VPN client fails, which could mean
that the client fails to set the default route or has a failure mode
that un-sets it.

So we have a way of blocking anything at all that might be forwarded to
the upstream network interface. This is much better than filtering by
IP. Users can employ whatever addressing scheme, and we don't have to
instruct them to hard-code IP addresses into scripts, config files and
VM settings... the address preconfigured in a downloaded config file
will work automatically and be completely protected.

I fully agree that this more generic solution is better assuming it's
properly reviewed & maintained.

Side note: I recently ran into
https://github.com/QubesOS/qubes-issues/issues/1183 - I'm still not
100% sure whether it's absolutely impossible to get some unexpected
DNS leaks from that bug.

That's causing a whitelist operation to fail, so the DNS packets would
be blocked instead of leaked. I believe that's why the issue was flagged
as minor.

Not 100% correct. Another address is whitelisted instead, namely that
of the netvm. So your DNS requests might go plain text through the
netvm (!= VPN --> leak) in the worst case. The things that help here
should be the routing table installed by openvpn, the DNS server
settings of your proxy VM & maybe the other iptables commands from the
VPN doc assuming a user manually implemented them, yes. So probably
only some further bugs in combination would lead to serious issues.

I see. So that is similar to the scenario I described above.

Chris

@Sec Tester:
AirVPN enables you to download the openVPN config files per VPN exit
node, i.e. switching should be as easy as writing some small bash
script to get it done on the command-line.
Alternatively they provide some generic config files by country which
apparently do the selection for you, i.e. by using one of these you
should also have some variety of exit nodes.

--
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/d8db5059-7221-fc35-33d1-df2b32504bd1%40openmailbox.org.
For more options, visit

[qubes-users] Use YubiKey for Anti-Evil-Maid?

2016-11-12 Thread Eric

Is there any way to use a YubiKey for Anti-Evil-Maid, instead of just a regular 
USB flash drive? I imagine (though I will be the first to say that I don't 
know), that the firmware on it is much less resistant to compromise/BadUSB 
attacks, and since it crypto something something, it seems a natural fit.

Of course, I haven't seen the code for AEM, and I know that it's a program 
instead of just a keyfile. Is there any possibility of two factor 
authentication for anti-evil-maid? IE, passphrase and a YubiKey?

-- 
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/55d6fca4-e86f-45ae-9cce-5408829a4c0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] VM label icons

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Nov 12, 2016 at 10:38:41AM -0800, longridge wrote:
> AM new user - just finding my way around.
> 
> On all VM's that I open, the label heading is clear and bold (obviously less 
> so when inactive) but the icons (eg minimise, maximise, close etc) are all 
> very faint. (barely visible)
> 
> Am sure there just be a way to enhance them (screen examples from online 
> articles are all clear) - but have spent ages trying various settings - 
> without success. 
> 
> Grateful for any help!

Try changing windows style: settings -> window manager -> style.

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

iQEcBAEBCAAGBQJYJ2xKAAoJENuP0xzK19csKbEH/2g47H9OgAksNoEMSLsiAUeh
VyKQqzxLaKs6+ycsbGn7vfop2rooQ1L08HAVgBpuFml/DD01gnz15wHH/T5JxU4t
WEZ4JvIk/hWExeKpa2O0qMYAofP8jSjwgcK3Mmk9r98NW8aWtSzz9Wr5HLlCddJx
55ehA2h3bqFRliYKU7orlDSK4WMc7hhkot/Cp9jVkLZiCxRUxrcf9PDy4gcFAy5J
0B0/1ykDQckbk5q1zPehKMRT35X7dtPUBRqYI8CrM7KVq4hIlJ6JPwQFNMEM8gls
Kx9w0ZQ4D2wMupdZIni8xuufVtmEbUAwN+Rwdlc/b2EvkeStQb0r01LuboMj3ws=
=yCZN
-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/20161112192352.GQ7073%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] VM label icons

2016-11-12 Thread longridge

AM new user - just finding my way around.

On all VM's that I open, the label heading is clear and bold (obviously less so 
when inactive) but the icons (eg minimise, maximise, close etc) are all very 
faint. (barely visible)

Am sure there just be a way to enhance them (screen examples from online 
articles are all clear) - but have spent ages trying various settings - without 
success. 

Grateful for any help!

-- 
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/caaba285-326b-4829-b122-8c4eecb8766e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Windows Tools 3.2.2-3 released

2016-11-12 Thread Eric Shelton

On Saturday, October 22, 2016 at 9:26:08 AM UTC-4, omeg wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi all,
> 
> We uploaded a new version of Qubes Windows Tools (3.2.2-3) to the
> current-testing repository.
> 
> Changelog:
> - - Updated Xen PV drivers to be in line with upstream
> - - Private disk image is now initialized during setup making the
>   install process require one less reboot
> - - Added handler for qubes.OpenURL qrexec service
> - - Fixed a bug that could make moving user profiles to the private
>   image fail if there were files with ACLs explicitly disallowing SYSTEM
>   access
> - - Fixed handling qrexec service requests for non-existing services
> - - Minor log readability improvements

I am unable to install the windows tools with the "Move user profiles" install 
option disabled.  I get the same message reported by Eva 
(https://i.imgur.com/1MPczCY.png), along with, at the end, "0x80070643 - Fatal 
error during installation".  In the log file, the action that seems to be 
failing is:

Applying execute package: qubes_tools_WIN7x64_3.2.2.3.msi ... arguments: ' 
ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7"'

The installer works if "Move user profiles" is enabled.

Maybe this is related to the "Private disk image is now initialized during 
setup making the install process require one less reboot" change.

Eric

-- 
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/b5052d10-24c5-48b3-adf6-aa76abd063b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] proper way to autostart script in dom0

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, Nov 12, 2016 at 09:55:44AM -0300, Franz wrote:
> Hello,
> 
> I looked on various old threads and there is mentioned a
> ~/.config/autostart, so I tried in dom0 using Qubes 3.2
> 
> cp myfile.sh ~/.config/autostart
> 
> but after rebooting nothing is autostarted.
> 
> The script is simply for starting various applicaions and settings in VMs
> and works well with ./myscript.sh

Files in ~/.config/autostart needs to be in "desktop entry" format. Try
placing myfile.desktop with content like this:

[Desktop Entry]
Type=Application
Name=My script
Exec=/path/to/myfile.sh

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

iQEcBAEBCAAGBQJYJ1MRAAoJENuP0xzK19csI64H/2LBYbf0+tRT4imEMTkCW+MU
z19+JLDLkzSP9ikeTHIyKctXNJtDqG3WUaqt/jXPTdFFikEow2x0RaA1QrMrOey2
dYZZ6TJYL3lZ16DSV4zLE5oUucE4lytoaLVsg6+ZjHntBHhYUx/H9h8Py7CfPWQ4
DaaaXsgZJ212psH8Nd5BCX7wrdcGFf3OE6aPi/dGeSinSDrCUXDYe6I4tqprn9nC
6ncCcD5QJnjlCUGQawb73qZ5zGUMElykgdYXcR8hfRBvdst9AKSSPgn3Z7PhhhFo
tpcjAqrfvzIjzv+SjLvfTDPzRWfRjR0Gw06hBu1pkjfpPnhOfIvaPHZah6me9TU=
=dBxy
-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/20161112173615.GP7073%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts on Qubes OS Security... Could be improved.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Nov 11, 2016 at 07:21:18PM -0800, Sec Tester wrote:
> So Im still new to Qubes, but after going through a bit of a learning curve, 
> building & customizing VM's to suit my security needs, I have a few thoughts 
> on its security.
> 
> Firstly I really love the direction Qubes has taken the future of operating 
> systems, and its has definitely become my OS of choice. 
> 
> HOWEVER, i feel that Qubes OS relies HEAVILY on ONE security mechanism > 
> Isolation.
> 
> There are 2 ways we can improve security
> 
> 1. But adding layers of protection.
> 2. By reducing the attack surface area.
> 
> 
> Layers of protection
> 
> In regards to layers of protection, IMO Qubes only has one. By isolating VM's 
> if a system is infected, it has to breach that VM & gain access to dom0, 
> where it then has total control of the system.
> 
> The problem is in the current configuration, there is nothing to stop a 
> hacker or malicious software from running, manipulating VM system files, or 
> downloading additional hack tools/scripts to attempt to breach into dom0.
> 
> To basic extra layers of protection missing from Qubes that usually hardens 
> Linux security are;
> Password protected root access on VM's
> SELinux or AppArmor.
> 
> I have read Qubes excuse for NOT requiring a password for root access in VM's 
> https://www.qubes-os.org/doc/vm-sudo/
> 
> I frankly think saying "its highly unlikely if that person (who could breach 
> a VM to dom0) couldn't also find a user-to-root escalation in VM" as a very 
> LAZY justification.
> 
> They have basically said, Elite hackers can gain root, so lets just not even 
> bother with this foundational layer of security.

The point is _if_ someone is able to run arbitrary code as user, he/she
can easily run it also as root, because of tremendous attack surface of
linux kernel and all the services running as root. In the worst case one
needs some patience and simply wait for you to authorize some command to
be ran as root (regardless of authorization method - password, qrexec
confirmation as described on https://www.qubes-os.org/doc/vm-sudo/ or
anything else).  In the simplest case one may alias 'sudo' to for
example 'sudo /tmp/my-evil-script'.

On the other hand, making it harder to execute arbitrary code in the VM
(reducing attack surface) makes sense. Things like SELinux, AppArmor,
seecomp filters etc.
Take a look at SubgraphOS + QubesOS thread here for more details:
https://secure-os.org/pipermail/desktops/2015-October/02.html

> So we have VM's where any script kiddies code can run riot. This to me is 
> over confidence in VM isolation, and a lax attitude because, hey if your 
> infected you can just reboot & VM is clean again right? Except the infected 
> files sitting in the home directory, just waiting to be opened again and run 
> with root permissions.
> 
> And in the example of a server VM, that system may rarely be rebooted very 
> often? Infecting the system to infect others that connect to that server. NOT 
> GOOD.
> 
> From what i've read SELinux isn't running do to some compatibility errors, 
> and because there is no point when the whole system has root access. Well 
> lets lock down default VM root access, and lets find a way to make SELinux 
> work in Qubes VMs & even dom0, or possibly AppArmor. Or maybe we need a 
> totally new piece of software that is Qubes specific.

Actually, the whole point of SELinux is to take away power even from
root, so having passwordless root is somehow orthogonal to
SELinux/AppArmor.

> The more layers of security in the system the better.
> 
> 
> Reducing the attack surface area
> 
> Qubes OS through the use of dom0 has reduced the attack surface area of the 
> kernel, which is good.
> 
> However, where i think Qubes could improve right out of the box, is having 
> dedicated minimized templates for sys-net & sys-firewall.
> 
> I spent time setting up fedora-23-minimal templates specifically for sys-net, 
> sys-VPN, banking, email & browsing. I plan to make another for sys-firewall 
> soon. VM's that have the minimal amount of programs on as possible, reduce 
> the attack surface, and possible exploits.
> 
> Again SELinux not only adds a layer of protection, it also reduces the attack 
> surface area vulnerable in the system.

Yes, this mostly makes sense. As for out of the box configuration we're
somehow limited by installation image size. Now it barely fits on DVD
(which also means a lot to download). Adding another Linux-based
template means another few hundreds MBs.
Using unikernel may help here (see MirageOS for firewallVM). It is still
not mature enough to have it in default installation, but I hope it will
be some day. It's hard to do the same with sys-net, because the need for
all the hardware support...

> =
> Finial suggestion
>

Re: [qubes-users] Re: #2 .odt files and LibreOffice Install

Can someone provide me with the terminal commands (from template: fedoara-23) 
to receive the downloaded LibreOffice install file 
(LibreOffice_5.2.3_Linux_x86-64_rpm.tar.gz) from the [work: web browser], and 
then run the installation script?

Alternatively, could you provide the terminal commands from [work] domain to 
the Fedora-23 template?



Sent with [ProtonMail](https://protonmail.com) Secure Email.


 Original Message 
Subject: Re: [qubes-users] Re: #2 .odt files and LibreOffice Install
Local Time: November 12, 2016 2:59 PM
UTC Time: November 12, 2016 12:59 PM
From: sectesting0...@gmail.com
To: qubes-users 
sectesting0...@gmail.com, interso...@protonmail.com

Im not sure about the kernel problem, maybe one of the Qubes team will have 
advice on that, post the error log if you can find it.

One other small thing that you've probably tried.

sudo dnf upgrade

Good luck

--
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/40177af9-222b-45ce-b52b-917ff66d75d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[qubes-users] Re: proper way to autostart script in dom0

maybe it needs to be made exacutable..

from the directory of file in terminal
sudo chmod +x /the/directory/of/file/filename.sh

-- 
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/0b98a473-c00c-452b-875b-6bfe447f7752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] proper way to autostart script in dom0

2016-11-12 Thread Franz

Hello,

I looked on various old threads and there is mentioned a
~/.config/autostart, so I tried in dom0 using Qubes 3.2

cp myfile.sh ~/.config/autostart

but after rebooting nothing is autostarted.

The script is simply for starting various applicaions and settings in VMs
and works well with ./myscript.sh

any idea
Best
Fran

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

[qubes-users] Re: Thoughts on Qubes OS Security... Could be improved.

Some examples of Default Root access possibly being exploited in Qubes.

===
Looks like the DRAMA attack would require root access in VM, to compromises
Qubes shared memory

"taskset 0x2 sudo ./measure -p 0.7 -s 16."

https://groups.google.com/forum/#!topic/qubes-users/qAd8NxcJB3I

=
I thought of a possible persistent attack vector, that would survive even after
rebooting the VM.

If malware wrote its self into rw/config/rc.local it could reinfecting the
system every restart.
===
===
Also today i used the CLI command to move files between VM's

"qvm-copy-to-vm"

a dom0 prompt seems to be the only thing stopping an attacker spreading
malicious code across the whole machine, including templates.

Using the DRAMA attack to Authorize, bypass or spoof permission to transfer
malware across the entire system.

A VM root password would just add that extra layer of prevention.
===
All of these attacks could be mitigated with a password for root access in VM.

SELinux policies could also limit directories being read & written to.

Im still studying Qubes OS tho. Perhaps there are existing security features in
qubes im unaware of that prevent these attacks without requiring a VM root
password?

--
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/e9640658-7763-4e57-8af2-5eb0ff09a86d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: #2 .odt files and LibreOffice Install

>Your trying to modify the fedora-23 template correct? Yes.
>Is sys-firewall specified as its net VM? Yes.
>Do your other app VM's have internet access? Yes.
>Does sys-firewall have sys-net set as its "NetVM"? Yes.
>Sys-net and Sys-firewall pings to Google both were successful.
>After restarting Qubes, launching fedora-23 terminal, and then running sudo 
>dnf install libreoffice, the command eventually lead to the following message:
Error: Error downloading packages: Cannot download 
l/libreoffice-core-5.0.6.2-10.fc23.x86_64.rpm: All mirrors were tried
(Also note that during additional attempts of re-running the sudo command, 
various other errors would appear including "Failed to synchronize cache for 
repo 'updates')
Before attempting to reinstall the fedora-23 template, I want to point out a 
possible culprit. During bootup of Qubes, the following error appears twice 
very rapidly in different sections of the bootup process: FAILED: Failed to 
load start load kernels or Failed to load Kernel Modules. See specs below. 
Please advise.


Specs:
Qubes Version 3.2 (R3.2)
Qubes Default Kernel 4.4.14.11
Intel core i3 2.4GHz M370
4096MB SDRAM DDR3
120GB SSD

Thank you.

https://www.qubes-os.org/mailing-lists/
[https://groups.google.com/forum/#!forum/qubes-users](https://groups.google.com/forum/#%21forum/qubes-users)




Sent with [ProtonMail](https://protonmail.com) Secure Email.


 Original Message 
Subject: Re: [qubes-users] Re: #2 .odt files and LibreOffice Install
Local Time: November 12, 2016 4:02 AM
UTC Time: November 12, 2016 9:02 AM
From: sectesting0...@gmail.com
To: qubes-users 
sectesting0...@gmail.com, interso...@protonmail.com

Your trying to modify the fedora-23 template correct?
Is sys-firewall specified as its net VM?
If not, set the fedora-23 template NetVM to sys-firewall.
Then try "sudo dnf install libreoffice"

Do your other app VM's have internet access?

If not.
Does sys-firewall have sys-net set as its "NetVM"?

==
Ping tests
==
Open terminal in sys-Net. Try: ping www.google.com
If that works
Open terminal in sys-firewall. Then > ping www.google.com

If there is no ping result even from sys-net, then you have to check if the 
adaptor has been asigned, and is enabled.
https://www.qubes-os.org/doc/assigning-devices/

Just so you know, you cant ping or browse internet from a template, but it 
should still be able to update, and install packages via dnf.

sometimes stopping all the VM's and restarting them fixes internet.

worst case, you could replace the fedora-23 template with a fresh one from 
qubes.

in dom0 open a terminal.
sudo qubes-dom0-update --action=reinstall qubes-template-package-name
https://www.qubes-os.org/doc/reinstall-template/

if non of that works. maybe easier to just reinstall Qubes OS?

--
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/ac246815-3491-478c-b00a-f74810d79448%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: [qubes-users] Leak Problems with VPN ProxyVM + AirVPN & Network lock

2016-11-12 Thread David Hobach

Can you please explain that in a more detailed way?

This approach might not work for all VPN providers as some e.g. do
load balancing via DNS or other tricks, but for some it does. For the
others, yes, Qubes Firewall might be too limited.

Assuming your VPN setup was not compromised the infrastructure being
used does not matter - even if it's potentially hostile (most of it
should actually be assumed to be hostile). Due to the beauties of
cryptography there's a tunnel between your proxy VM and your VPN exit
node as if there was a fixed line. And yes, your appvm using that
proxyVM can obviously find your VPN exit node IP by checking its IP with
whatever public service. And then what?
It cannot communicate outside of that tunnel as Qubes makes sure it
cannot use anything else than your proxy VPN VM; so I don't see how it
should identify your ISP IP address (except for maybe state-level
attacks such as netflow pattern analysis on a global scale).

I fully agree that this more generic solution is better assuming it's
properly reviewed & maintained.

Side note: I recently ran into
https://github.com/QubesOS/qubes-issues/issues/1183 - I'm still not
100% sure whether it's absolutely impossible to get some unexpected
DNS leaks from that bug.

That's causing a whitelist operation to fail, so the DNS packets would
be blocked instead of leaked. I believe that's why the issue was flagged
as minor.

Not 100% correct. Another address is whitelisted instead, namely that of
the netvm. So your DNS requests might go plain text through the netvm
(!= VPN --> leak) in the worst case. The things that help here should be
the routing table installed by openvpn, the DNS server settings of your
proxy VM & maybe the other iptables commands from the VPN doc assuming a
user manually implemented them, yes. So probably only some further bugs
in combination would lead to serious issues.

@Sec Tester:
AirVPN enables you to download the openVPN config files per VPN exit
node, i.e. switching should be as easy as writing some small bash script
to get it done on the command-line.
Alternatively they provide some generic config files by country which
apparently do the selection for you, i.e. by using one of these you
should also have some variety of exit nodes.

--
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/26778679-1e00-471b-3c55-c5281b793d74%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: #2 .odt files and LibreOffice Install

Your trying to modify the fedora-23 template correct?
Is sys-firewall specified as its net VM?
If not, set the fedora-23 template NetVM to sys-firewall.
Then try "sudo dnf install libreoffice"

Do your other app VM's have internet access?

If not.
Does sys-firewall have sys-net set as its "NetVM"?

==
Ping tests
==
Open terminal in sys-Net. Try: ping www.google.com
If that works
Open terminal in sys-firewall. Then > ping www.google.com

If there is no ping result even from sys-net, then you have to check if the
adaptor has been asigned, and is enabled.
https://www.qubes-os.org/doc/assigning-devices/

Just so you know, you cant ping or browse internet from a template, but it
should still be able to update, and install packages via dnf.

sometimes stopping all the VM's and restarting them fixes internet.

worst case, you could replace the fedora-23 template with a fresh one from
qubes.

in dom0 open a terminal.
sudo qubes-dom0-update --action=reinstall qubes-template-package-name
https://www.qubes-os.org/doc/reinstall-template/

if non of that works. maybe easier to just reinstall Qubes OS?

--
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/ac246815-3491-478c-b00a-f74810d79448%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: #2 .odt files and LibreOffice Install