date:20160726

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Jul 27, 2016 at 04:32:24AM +, Jeremy Rand wrote:
> Marek Marczykowski-Górecki:
> > On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote:
> >> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote:
> >>> Hello.  I just did an update, rebooted, and now my window borders do not 
> >>> have the VM's colors.  The prefix on the window title is correct tho.
> >>>
> >>>
> >>> What gives?
> >>>
> >>>
> > 
> >> That sounds very strange. Have you done any kind of customization or made 
> >> any
> >> changes from the defaults? For example, have you changed the colors or 
> >> changed
> >> the window border style?
> > 
> >> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1?
> > 
> > Those are important questions.
> > 
> > In addition, please provide version of qubes-gui-dom0 package. And check
> > properties of some VM window using xprop from dom0 (call xprop, then
> > click on some VM window). Especially those properties:
> > _QUBES_LABEL
> > _QUBES_LABEL_COLOR
> > _KDE_NET_WM_COLOR_SCHEME
> > 
> > 
> 
> Same thing has happened to me.
> 
> No customizations have been done.  I initially thought it might be due
> to customizations, so I reinstalled Qubes from scratch, did a
> qubes-dom0-update, and rebooted, and it happened.  So definitely not due
> to customizations.
> 
> All the windows now appear to have the window border coloring that is
> normally associated with dom0 (gray when not in focus, cyan when in
> focus).  Also interestingly, the icon of the Launcher in the Panel has
> disappeared and became solid white.  (I was able to workaround it by
> right-clicking it, and in the settings dialog manually choosing an icon
> from the list.)  In addition, there is now an odd icon on the left side
> of every window title bar (just to the right of the application icon)
> that I don't recall ever being there before; it looks like a 1-pixel
> thick square with the corner pixels removed.  (I can provide a
> screenshot if you need it.)
> 
> KDE on 3.2rc1.
> 
> "dnf info qubes-gui-dom0" in dom0 shows version 3.2.1.
> 
> I did the xprop you requested, and clicked on the fedora-23 TemplateVM.
> 
> _QUBES_LABEL is 8.
> _KDE_NET_WM_COLOR_SCHEME is
> "/home/jeremy/.local/share/qubes-kde/black.colors".

This looks ok. I assume the file exists too.

> _QUBES_LABEL_COLOR does not show up in the xprop output at all.

This is also ok in qubes-gui-dom0 3.2.1.

> Hope this helps in diagnosing.

Try this:

Go to system settings -> Application Style -> Window Decorations. It
should be set to "Breeze". If it is set to "Plastik", it may be the
cause of the problems.

If this is the case, I think this may be related to KDE update done by
Fedora recently (a lot of kf5-* packages), so unrelated to
qubes-gui-dom0 version.

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

iQEcBAEBCAAGBQJXmD46AAoJENuP0xzK19csPtgH/Anmul9RmxX/prK2j1q1iyMt
43aLfNXcLjsQBh45pxi94HE/eYGnuZC/cuFZs5aTFJwVfigk3Xir5F/+2h573kTX
YNceUj9ZghLqigu7gsJQJAZ4O5Y6Nd43h2l6/6tcdsj2oSjExT0/uifI0FBJ8LU3
doE/TT1WNixZ9vKf5js9RU2GxsC5Gg5l+Qasp6dHjo0IaJQpYYMr5BmYAJtSXDbG
2BTrWo1YodPTgLIZiwmdgCe8zGUQ+F0eM/9TVin1+kEAF9KNI7WCKI3GLs3zr5eZ
TmbzOCuupAQS2FFKQE2T9Sv5O2mCpBaFi79YOXavZeL+wDioqD3FJ6o4Fr/kY9c=
=3Ts+
-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/20160727045314.GS32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] Window border colors

2016-07-26 Thread Jeremy Rand

Marek Marczykowski-Górecki:
> On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote:
>> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote:
>>> Hello.  I just did an update, rebooted, and now my window borders do not 
>>> have the VM's colors.  The prefix on the window title is correct tho.
>>>
>>>
>>> What gives?
>>>
>>>
> 
>> That sounds very strange. Have you done any kind of customization or made any
>> changes from the defaults? For example, have you changed the colors or 
>> changed
>> the window border style?
> 
>> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1?
> 
> Those are important questions.
> 
> In addition, please provide version of qubes-gui-dom0 package. And check
> properties of some VM window using xprop from dom0 (call xprop, then
> click on some VM window). Especially those properties:
> _QUBES_LABEL
> _QUBES_LABEL_COLOR
> _KDE_NET_WM_COLOR_SCHEME
> 
> 

Same thing has happened to me.

No customizations have been done.  I initially thought it might be due
to customizations, so I reinstalled Qubes from scratch, did a
qubes-dom0-update, and rebooted, and it happened.  So definitely not due
to customizations.

All the windows now appear to have the window border coloring that is
normally associated with dom0 (gray when not in focus, cyan when in
focus).  Also interestingly, the icon of the Launcher in the Panel has
disappeared and became solid white.  (I was able to workaround it by
right-clicking it, and in the settings dialog manually choosing an icon
from the list.)  In addition, there is now an odd icon on the left side
of every window title bar (just to the right of the application icon)
that I don't recall ever being there before; it looks like a 1-pixel
thick square with the corner pixels removed.  (I can provide a
screenshot if you need it.)

KDE on 3.2rc1.

"dnf info qubes-gui-dom0" in dom0 shows version 3.2.1.

I did the xprop you requested, and clicked on the fedora-23 TemplateVM.

_QUBES_LABEL is 8.
_KDE_NET_WM_COLOR_SCHEME is
"/home/jeremy/.local/share/qubes-kde/black.colors".

_QUBES_LABEL_COLOR does not show up in the xprop output at all.

Hope this helps in diagnosing.

Cheers,
-Jeremy Rand

-- 
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/1329b606-183b-3eec-cc01-9de0bfd287d9%40airmail.cc.
For more options, visit https://groups.google.com/d/optout.

signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

On Wednesday, 27 July 2016 09:34:17 UTC+10, Marek Marczykowski-Górecki  wrote:
> > "Of course, to be compatible with Qubes OS, the BIOS must properly expose 
> > all the VT-x, VT-d, and SLAT functionality that the underlying hardware 
> > offers (and which we require)."
> 
> The easiest way is to use qubes-hcl-report tool and check for "HVM" and
> "I/O MMU". I think "HVM" check currently doesn't include SLAT
> functionality check right now, but it's something we'll add in the near
> future.

What happens if we don't have the SLAT functionality? Will Qubes refuse to 
run/install/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/6494901b-24d5-4415-a5b5-124ec2aa4458%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Chris Laprise


On 07/26/2016 08:45 PM, el...@tutanota.com wrote:

What is best way to verify our system supports these things?

I think you can also check out the processor with Intel..
ark.intel.com
You can search through the different processors if you are looking to pick up a 
new computer.



A guide I found at AMD:
http://support.amd.com/en-us/kb-articles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx

From Microsoft:
http://support.amd.com/en-us/kb-articles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx

Basically, anything recent that isn't too cost-reduced.

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/07b40854-c066-ca18-df47-715ad96505cc%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Bill Wether

On Tuesday, July 26, 2016 at 11:34:17 PM UTC, Marek Marczykowski-Górecki wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Tue, Jul 26, 2016 at 04:25:41PM -0700, raahe...@gmail.com wrote:
> > "Of course, to be compatible with Qubes OS, the BIOS must properly expose 
> > all the VT-x, VT-d, and SLAT functionality that the underlying hardware 
> > offers (and which we require). Among other things, this implies proper DMAR 
> > ACPI table construction."
> > 
> > What is best way to verify our system supports these things?
> 
> The easiest way is to use qubes-hcl-report tool and check for "HVM" and
> "I/O MMU". I think "HVM" check currently doesn't include SLAT
> functionality check right now, but it's something we'll add in the near
> future.

Thanks, Marek.  Being able to plan for this change would help us a lot, so 
please announce it nice and loud when it's done.

Thanks again

BillW

-- 
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/bb0f8a53-eca0-40ad-8b75-46529d89a9e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Window border coloring

On Wednesday, 13 July 2016 11:36:00 UTC+10, Marek Marczykowski-Górecki  wrote:
> 
> Only very few places use this value currently. Most of them (including
> standard window decoration) use "label index" value (-l 3 here), which
> refers to hardcoded table in KDE/Xfce/i3/...
> This is going to be better in upcoming versions, but it isn't done yet.

Can you please tell me where this location is?
There are no folders matching that.

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

[qubes-users] Re: Linux Packages for Fedora

On Thursday, 21 July 2016 11:58:01 UTC+10, Drew White  wrote:
> What packages are required to get the system working as integrated into Qubes?
> 
> i.e. Seamless mode, copy and paste, live changes, memory balancing, etc..

Any chance anyone knows this? or does this remain a mystery because noone knows?

I know I've asked similar before and got no answer back then, so I asked again 
hoping someone would finally have an answer available for me.

-- 
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/fac36ae9-43bf-48d4-b219-89a26a110423%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Security Bulletin #24 (Critical bug)

On Tuesday, 26 July 2016 22:06:25 UTC+10, Joanna Rutkowska  wrote:
> 
> We have just released a new Qubes Security Bulletin (QSB #24) for a critical 
> bug
> in the Xen hypervisor:
> 
> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
> 
> Please install the updates, immediately.
> 

Question...
There is nowhere that says what updates to apply or what will be updated.
Where can I find a list of all packages and files that will be updated please?

-- 
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/21859281-089d-46ff-a7c3-1c3a4ab501ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread eliwu

> What is best way to verify our system supports these things?

I think you can also check out the processor with Intel..
ark.intel.com
You can search through the different processors if you are looking to pick up a 
new computer.  

-- 
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/b31cd45c-2c86-486b-8aea-a2e12d9a0dce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jul 26, 2016 at 04:25:41PM -0700, raahe...@gmail.com wrote:
> "Of course, to be compatible with Qubes OS, the BIOS must properly expose all 
> the VT-x, VT-d, and SLAT functionality that the underlying hardware offers 
> (and which we require). Among other things, this implies proper DMAR ACPI 
> table construction."
> 
> What is best way to verify our system supports these things?

The easiest way is to use qubes-hcl-report tool and check for "HVM" and
"I/O MMU". I think "HVM" check currently doesn't include SLAT
functionality check right now, but it's something we'll add in the near
future.

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

iQEcBAEBCAAGBQJXl/N0AAoJENuP0xzK19cs938IAJdFzaAVpZwR4Pw1UugW1CwP
DQdBjjor8gzbGuFHnNPxiWdlNegAg3xlXomlGuzaCbH4xr+8EX9ZwO48srbfmwvJ
1TveTCPq+4l8TWPUml9irCiZYQqs6g2kWU8rrxTZ7nw/9iWNAWhvp37EmWtb7HS4
C+rzTzj7htnqlTSMscHlwW4zVG7Op+FQDeb7m+p9XwQd+9ZKZSsKfQ5FQyMOHh+i
xd9Yi5rhavT9PeEMIWfKGEP7YPjL/d7H0xhQGumdwFZwju55JsepacYtIRnbBhOV
iZinJnFOIaDxh9bxtiIodWs/IN+8+eTZSBdQII5iw7s3DsYcaxdXLbHaKYacgeY=
=4zbg
-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/20160726233412.GQ32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] Window border colors

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jul 26, 2016 at 03:11:33PM -0700, Andrew David Wong wrote:
> On 2016-07-26 14:52, Manuel Amador (Rudd-O) wrote:
> > Hello.  I just did an update, rebooted, and now my window borders do not 
> > have the VM's colors.  The prefix on the window title is correct tho.
> > 
> > 
> > What gives?
> > 
> > 
> 
> That sounds very strange. Have you done any kind of customization or made any
> changes from the defaults? For example, have you changed the colors or changed
> the window border style?
> 
> Also, are you using KDE or XFCE? R3.1 or R3.2-rc1?

Those are important questions.

In addition, please provide version of qubes-gui-dom0 package. And check
properties of some VM window using xprop from dom0 (call xprop, then
click on some VM window). Especially those properties:
_QUBES_LABEL
_QUBES_LABEL_COLOR
_KDE_NET_WM_COLOR_SCHEME

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

iQEcBAEBCAAGBQJXl/JjAAoJENuP0xzK19cskcoH/3M2R7JHpTfeBpDMR0GH0ePj
Y7KKa92693Yeo9ymfQ7pPkXYVI9hOOS3enAhjga+cv5n8b6pzyyMBXlA9rjs+kWs
YzMrZFRg02pS1MRfB+4wrObetYbvkF5THXbbJ6dpb9q8Z+E4Q4YR9vci17i9lUkE
gAmIxNw2Orwi0cJ09Id0k0GMhnu7HrHW0sjQ3Bl5CX1QWQ5lbm5BMxbViN9yOzgU
WgzQMi6SD9NxLe56zTA6kOFJnXUwwztIywnseD1Jpa2jGzjw6D13QmTrehpg5fpS
aDuMARGBN1NgQaiztmtO1lc1cd3OzRqkIYl7ejxZ9khjx0aQh0Oah+LMqBeg5EM=
=9Lw3
-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/20160726232939.GP32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, Jul 27, 2016 at 01:13:29AM +0200, Achim Patzner wrote:
> > Am 26.07.2016 um 19:42 schrieb Andrew David Wong :
> > 
> > The updated requirements for Qubes R4.x-certified hardware are
> > explained here:
> > 
> > https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
> > 
> > Although the requirements for Qubes-certified hardware are likely to
> > be more stringent than that minimum requirements
> 
> If
> 
> "Another important requirement we’re introducing today is that 
> Qubes-certified hardware should run only open-source boot firmware (aka “the 
> BIOS”), such as coreboot. The only exception is the use of a (properly 
> authenticated) CPU-vendor-provided blobs for silicon and memory 
> initialization (see Intel FSP) as well as other internal operations (see 
> Intel ME). However, we specifically require all code used for and dealing 
> with the System Management Mode (SMM) to be open-source.”
> 
> is the minimum requirement, Qubes just put itself out of the game by being 
> able to run on prehistoric hardware only (see coreboot’s list of supported 
> systems and CPUs) or being at the mercy of someone being able to provide a 
> system with appropriate firmware support by twisting some of Intel’s 
> appendages. It’s nice to demand free beer for everyone but you’ll have to 
> find someone providing it. Especially with Qubes hardware demands to be more 
> than a fancy typewriter (unlike others I found 64 GB of memory and a 
> sufficient number of CPU cores not to be wasted).

The above are requirements for Qubes-certified hardware, which are
intended for top-level security/compatibility. Not a minimum system
requirements.

But in Qubes 4.0 will will also have revised minimum requirements,
especially requirement for VT-x with EPT (or AMD equivalent). Previously
it was needed only for running HVMs (Windows in most cases). But this
shouldn't be a big issue in practice, as most high-end hardware today
have it.
More details:
https://github.com/QubesOS/qubes-issues/issues/2185

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

iQEcBAEBCAAGBQJXl/B6AAoJENuP0xzK19csJbEH/1T8r0e6Xqz+m4PWjw12Z04r
Sb/WGXdx43Sn5hfRNc61tmgmrdoA3vsWRHG9oK0cSYDWg3v6ByMk/znbTVP3XCi+
5sW+BcRXAJwXK9StMTEZc48g6hFKzmkFQpRc7tRAnAVA4ZV31moUGDYrRIng80rL
kcOJ+BUQZJ9rkxV/voe0Lb4DeRXjP8Xeyf5W0EiKdTG4Fs/3fdUu3auGtQVuZR1w
RAtaOL6Yg9frCnVO7Ud8wMiF2ZJ2nZh0pni2g6YVzP4UZ/MpTvXR7hakzyB6ormF
uw+CSKqfqmjDaU9cce/4XqDLN19qstvCGmM+lVl6qGxPSJk+ABK8qo48IUOjEX4=
=fUaM
-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/20160726232130.GO32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Achim Patzner

> Am 26.07.2016 um 19:42 schrieb Andrew David Wong :
> 
> The updated requirements for Qubes R4.x-certified hardware are
> explained here:
> 
> https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
> 
> Although the requirements for Qubes-certified hardware are likely to
> be more stringent than that minimum requirements

If

"Another important requirement we’re introducing today is that Qubes-certified 
hardware should run only open-source boot firmware (aka “the BIOS”), such as 
coreboot. The only exception is the use of a (properly authenticated) 
CPU-vendor-provided blobs for silicon and memory initialization (see Intel FSP) 
as well as other internal operations (see Intel ME). However, we specifically 
require all code used for and dealing with the System Management Mode (SMM) to 
be open-source.”

is the minimum requirement, Qubes just put itself out of the game by being able 
to run on prehistoric hardware only (see coreboot’s list of supported systems 
and CPUs) or being at the mercy of someone being able to provide a system with 
appropriate firmware support by twisting some of Intel’s appendages. It’s nice 
to demand free beer for everyone but you’ll have to find someone providing it. 
Especially with Qubes hardware demands to be more than a fancy typewriter 
(unlike others I found 64 GB of memory and a sufficient number of CPU cores not 
to be wasted).


Achim

-- 
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/78D98A33-C9C9-4FF6-A9F4-230D5A80FA0B%40noses.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] disposableVM not really disposable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Tue, Jul 26, 2016 at 07:29:10PM +0100, cubit wrote:
> 26. Jul 2016 18:26 by a...@qubes-os.org:
> 
> > Another user, Alex, previously reported the same phenomenon here:
> >
> > https://groups.google.com/d/topic/qubes-users/Eipv3eNKzJQ/discussion
> >
> 
> Thank you, my search fu was failing me, I though I remembered something like 
> this already
> 
> > I've begun tracking this issue here:
> >
> > https://github.com/QubesOS/qubes-issues/issues/2200
> >
> > We currently know very little about this issue, so I'm afraid there is
> > no solution yet.
>
> Is there any information I can gather that might help before I run 
> qvm-create-defalult-dvm? 

Check file list in /var/lib/qubes/appvms/fedora-23-dvm. Especially date
and permissions of volatile.img there.

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

iQEcBAEBCAAGBQJXl+66AAoJENuP0xzK19csa+4IAIwrFubD3JWRprTv9ZrvbwnT
w0iiOFNig3JQplN5HUsG4MBd+4lkBUmCvjuWPccCTh4nuzJWFJT7VccL/fgs6vUk
Zhj4RQzugFjhn21+aiHvE/dgNJDwrMGx/AxW/kt2oeOJ/ITdOuBRCLs1eVKiKe02
xdyxKgq1paCqQILHb8o7j6hstdhyOwjpicGZz/BYTzG1ZuwCNHZ9rIlsHyUxYWgh
q75YnDK67vbeVQ0cvuhfgcmSkgR2RpbjxI+hZJL2ddJ6USyegr9nuPbUAwKLww+w
RZO8i9amwVtNYWpcUbKWx9RlrUQAgJOZ3+apecqaAHC+V6wU0dFluIBGrGzf+uA=
=DEa+
-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/20160726231402.GN32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: [qubes-devel] Window border colors

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-26 15:35, 45fv2s+682x23ntdh9z4 via qubes-users wrote:
> Same problem here. Window border colors are no longer working since today's
> update on Qubes 3.2-rc1. How can one restore it back to its original
> working state? Since this update every time a command is launched, when the
> respective AppVM is down, the window is not displayed and the AppVm shows
> as being in a transient state (for instance, when launching the
> gnome-terminal, the terminal console only gets displayed after another
> instance of gnome-terminal is launched, then two terminal console windows
> are displayed) Something definitively went wrong with this update...
> 

Tracking:

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

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

iQIcBAEBCgAGBQJXl+ukAAoJENtN07w5UDAwWpEP/A19YGmaSDBscBwdiJTrwKYJ
uVONeS+KXOiVwCyi6DVd5QWeyFN6qOlAbCTJa7hhKh1KAW8dxUOR4IvgtD06LwCv
9j0pUtC66F70myo03W970oiwH5h0wFqMwbBmVxcTnWdFiJxGKexROxupJ12/W64M
6h90KzqGB4LRUenwIFr5qFe01mE/enNSzHzf8sVdblpEPInwlVNGVXSfrLrSc8mp
+g4Z29nnqP8bJb80bn0P+J7+kpHLCh90La2Iidhf8eWNLrjOXQdz7FkjEf9ZU+7X
TW2hxZ4l8zHpbLa84+VH6xEgJFrenz9FlDT9hQlo3iYWVr6z51NI9Jwrfd0zC52J
WOkmPY/FOWeaXV6nf10BOpgR6P1DFrPXgdckOgkXGTaM3VUeq70T0u4k3J8jSG9m
+sHIhyjWcDqJ5sgy6I++W6dYC4fp27r6IaZr+Y81yDKXkSoDheq8XiaNsJ8w29uT
X3ernQrdAqUG/umq3CiUp2W7s15loFQrWragyRrnWyjkDSx598RWIsl9MJ/MpcNe
ajjp7GnSbKht01N0iAM4yXvT7dIs0AvZ+4vhm7PE1u64EdHoLt/oAc6oxQ2l+NYA
AludozKgzxWZhdJrPxjYMVnU7nNUBs47f6FN+xTzBM4mm3/zc3RJKoYJTLkOj4xs
+11W4iQD/JvQ62b37ObA
=uvUq
-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/1ab58fb7-894c-fce2-1495-41372c3e05d1%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-devel] Window border colors

2016-07-26 Thread 45fv2s+682x23ntdh9z4 via qubes-users

Same problem here. Window border colors are no longer working since today's 
update on Qubes 3.2-rc1.
How can one restore it back to its original working state?
Since this update every time a command is launched, when the respective AppVM 
is down, the window is not displayed and the AppVm shows as being in a 
transient state (for instance, when launching the gnome-terminal, the terminal 
console only gets displayed after another instance of gnome-terminal is 
launched, then two terminal console windows are displayed)  
Something definitively went wrong with this update...






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

Re: [qubes-users] How to log all the websites accessed by a VM

2016-07-26 Thread Franz

On Tue, Jul 26, 2016 at 11:38 AM, Steve Coleman 
wrote:

> Another hack to avoid having to manually type in the addresses is done
> with the attached script. Its like Mareks solution, but does the parsing on
> the dom0 side


I understand this means this script should be executed directly in dom0,
but isn't this a security problem?


> and the syntax is a little easier. It does the remote tcpdump command in
> the vm and the results are returned through the pass-io mechanism. With the
> -A option the script then generates the qvm-firewall add commands to its
> stdout.
>
> Then, if you want to add that address to the firewall you simply copy and
> paste the lines you want from that dom0 command terminal window into
> another dom0 command window, and the address is added to the firewall
> without any manual typing. If you want, you can add a netmask (e.g.
> address/24) to an IP in the target window before pressing enter.
>
> [user@dom0 ~]$ qvm-fwdenied -A 
> qvm-firewall  -add
> ec2-54-200-125-198.us-west-2.compute.amazonaws.com any
> qvm-firewall  -add 104.244.43.140 any
> qvm-firewall  -add 104.244.43.44 any
> qvm-firewall  -add
> ec2-54-148-80-75.us-west-2.compute.amazonaws.com any
> qvm-firewall  -add
> ec2-52-88-118-150.us-west-2.compute.amazonaws.com any
> qvm-firewall  -add
> ec2-52-25-189-162.us-west-2.compute.amazonaws.com any
> ...
>
> Note that these appear in batches on the console because tcpdump is in a
> mode where it exits after some number of captured packets have been
> filtered, with the default set to 200 packets. By default it will
> repeatedly restart tcpdump for another batch. The -C ### option allows that
> default number of packets to be changed.
>
> It would be far better if the script was made to be multi-threaded so the
> output of tcpdump could be read while another thread outputs the commands
> and asks the user if each entry should be added or not. I just have not had
> time to look into that yet. its obviously a work in progress.
>
> Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to look
> at what happened in your last session.
>
>
> On 07/25/2016 02:14 PM, Franz wrote:
>
>>
>>
>> On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
>> > > wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
>> > On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
>> > marma...@invisiblethingslab.com
>> > wrote:
>> > > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
>> > > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
>> > > > marma...@invisiblethingslab.com
>> > wrote:
>> > > > > On Mon, Jul 25, 2016 at 09:37:10AM -0400, Steve Coleman wrote:
>> > > > Anyway regarding Marek script I tried it in a dispVM, it writes:
>> > > > tcpdump: listening on eth0, link-type EN10MB (Ethernet),
>> capture size
>> > > > 262144 bytes
>> > > >
>> > > > but then if on the same dispVM I use firefox to go to a gmail
>> account or
>> > > > another account, nothing appears on the terminal.
>> > > >
>> > > > I even looked if anything changed on dispVM firewall rules, but
>> found
>> > > > nothing different.
>> > > >
>> > > > So how is this script working?
>> > >
>> > > I've just tried and it is still working. It should output list of
>> > > blocked destinations in format of qvm-firewall commands ready to
>> load
>> > > into Qubes firewall.
>> > >
>> > ,
>> > "blocked destinations"?  This makes me think that I should block
>> > destinations somehow before running the script. Is that so?
>>
>> Yes, change VM firewall to deny by default.
>>
>>
>> ok now it works, it outputted a list of addresses. But I have to paste
>> this list on firewall rules of that VM and this is on Qubes Manager that
>> is on Dom0, so normal copy paste between VMs does not work.
>>
>> I can only imagine of writing the addresses on a text file, then copying
>> the file to Dom0, using
>>
>> |qvm-run --pass-io  'cat /path/to/file_in_src_domain' >
>> /path/to/file_name_in_dom0|
>>
>> opening the file in Dom0 (which seems half prohibited) and finally
>> copying the adresses to Qubes Manager.
>>
>> Otherwise I'll have to digit manually the addresses to Qubes Manager.
>>
>> Which is the suggested way to do that?
>>
>>
>> - --
>> 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
>>
>> iQEcBAEBCAAGBQJXllGTAAoJENuP0xzK19cswBgH/A0OxAIaR7hzEfET8uAcNeiC
>>

Re: [qubes-users] VPN Link Up, NetVM set to VpnVM but AppVMs still don't have net access?

2016-07-26 Thread gaikokujinkyofusho

On Monday, July 25, 2016 at 5:12:42 PM UTC-10, Chris Laprise wrote:
> On 07/25/2016 04:25 PM, gaikokujinkyofu...@gmail.com wrote:
> > On Thursday, July 21, 2016 at 9:41:57 PM UTC+12, gaikokuji...@gmail.com 
> > wrote:
> >> On Wednesday, July 20, 2016 at 4:17:32 PM UTC-8, Chris Laprise wrote:
> >>> On 07/20/2016 02:59 PM, gaikokujinkyofu...@gmail.com wrote:
>  On Saturday, July 16, 2016 at 5:09:48 PM UTC-4, gaikokuji...@gmail.com 
>  wrote:
> > I tried the 'sudo iptables -L -v -t nat' anyway and to be honest I am 
> > not sure I understand the output:
> >
> > [user@VPN ~]$ sudo iptables -L -v -t nat
> > Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
> >pkts bytes target prot opt in out source   
> > destination
> >   0 0 PR-QBS all  --  anyany anywhere 
> > anywhere
> >   0 0 PR-QBS-SERVICES  all  --  anyany anywhere 
> > anywhere
> >
> > Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> >pkts bytes target prot opt in out source   
> > destination
> >
> > Chain OUTPUT (policy ACCEPT 432 packets, 30668 bytes)
> >pkts bytes target prot opt in out source   
> > destination
> >
> > Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
> >pkts bytes target prot opt in out source   
> > destination
> >   0 0 ACCEPT all  --  anyvif+anywhere 
> > anywhere
> >   3   192 ACCEPT all  --  anylo  anywhere 
> > anywhere
> >  12   812 MASQUERADE  all  --  anyany anywhere 
> > anywhere
> >
> > Chain PR-QBS (1 references)
> >pkts bytes target prot opt in out source   
> > destination
> >   0 0 DNAT   udp  --  anyany anywhere 
> > 10.137.4.1   udp dpt:domain to:10.137.2.1
> >   0 0 DNAT   tcp  --  anyany anywhere 
> > 10.137.4.1   tcp dpt:domain to:10.137.2.1
> >   0 0 DNAT   udp  --  anyany anywhere 
> > 10.137.4.254 udp dpt:domain to:10.137.2.254
> >   0 0 DNAT   tcp  --  anyany anywhere 
> > 10.137.4.254 tcp dpt:domain to:10.137.2.254
> >
> > Chain PR-QBS-SERVICES (1 references)
> >pkts bytes target prot opt in out source   
> > destination
>  Hi, I don't think I am using Network Manager to connect, that is I went 
>  only by the Qubes VPN wiki but while trying to diag the problem I read 
>  about /etc/resolv.conf in some other doc while searching so thought I'd 
>  try (obviously no luck).
> 
>  As for the sudo sg qvpn -c ping whateversite, does returning one thing 
>  back and hanging count for anything? I am thinking not as I am not able 
>  to connect to the net via the VpnVM.
> 
>  Any thoughts on the DNS dnat rules?
> >>> Pinging from my vpn vm is probably the same as yours, now that I've
> >>> checked it: I get a DNS response but the pings themselves aren't 
> >>> permitted.
> >>>
> >>> I think the real problem is shown in your PR-QBS chain above. You see
> >>> that the 'to' addresses on the right are still pointing to a Qubes
> >>> internal subnet '10.137.x.x'. Something about the DHCP fetching of your
> >>> DNS servers or the way qubes-vpn-handler.sh is executing is not working.
> >>> You can verify this by taking the IP address for 'whateversite' and
> >>> pinging it from your appvm (connected to vpn vm)... that should work
> >>> even though DNS doesn't.
> >>>
> >>> Cause of the problem should be a misconfigured .ovpn (the 3 lines for
> >>> scripting) or the qubes-vpn-handler.sh script itself can't execute
> >>> because the execute flag is not set, or the shebang at the start was
> >>> left out, etc.
> >>>
> >>> Chris
> >> well you are right about being able to ping an IP from the appvm that is 
> >> connected to the vpnvm, it works fine.
> >>
> >> As for the misconfigured .opvn I can't make heads or tails of that as the 
> >> first time I just used the exact same file that I had backed up, I 
> >> rechecked it and I think its ok (I also got a new pre-configured one from 
> >> my vpn provider, c/p the needed edits in, and still get the same error). I 
> >> checked the permissions user of the two files and I think they are ok?
> >>
> >> -rw-r--r-- 1 root root  423 Jul 21 21:28 openvpn-client.ovpn
> >> -rwxr-xr-x 1 root root 1089 Jul 10 21:15 qubes-vpn-handler.sh
> >>
> >> I didn't quite follow you about the shebang? What parts at the begining do 
> >> you think might have been left out? Are you refering to the configuration 
> >> of the VM when I was creating it? (like setting as a proxyvm etc?)
> 
> The shebang refers to

Re: [qubes-users] Firefox profile seems to leak between DispVMs

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-06-18 14:54, IX4 Svs wrote:
> Qubes R3.1, Fedora 23 template, fully updated.
> 
> I launch a new disposable Firefox, which creates a new DispVM and
> displays [disp42] in the Firefox window title. All normal so far.
> 
> I hit CTRL+t to open a new Firefox tab and - I can't believe my
> eyes - the "new tab" page is full of thumbnails of web pages I have
> visited in other DispVMs, which have long been shut down.
> 
> sudo xl list from dom0 confirms disp42 is the only DispVM currently
> running.
> 
> How can such data leakage from one DispVM to another be possible?
> Yes, I am adamant, 100% certain that I have not visited the web
> sites showing up in the "new tab" page from the TemplateVM that my
> DispVM is based upon.
> 
> Any thoughts?
> 
> Thanks,
> 
> Alex
> 

This issue is now being tracked here:

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

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

iQIcBAEBCgAGBQJXl6uHAAoJENtN07w5UDAwpJ8QAI+YMuCE+LmJuqsrFWyq++Sn
LGR+Ug7ZILUfoKypRmtYlYaAZZa7HoB1xyiJSsDtof/YGdmGMGHIUVJsmskr6+by
i+wdVpfpBlnd2kw9UZP2rKNL+PJ1thBxJ3QfFzrHvxp/RHg4C6OGdEcamqPdIYje
7yynSpwIazkRk1r6JJeTqUqBZZ8fGAmfPCbr59QSBXrVaz0gNU/DVO0amXL3DDwN
bFZSrMF0WG16RvuKJMMb7UZlcyxrRjvI+wZNTV6Z9vHUrbxRYuz5dbxT/cNRoI/Q
NOzXtJ15nQxBgeaC+zE7V3OIRwst8cyn8ALXS7fL0PEfM/CMBV59GH7OiSFMycaQ
ksGbHGg7cz8tzQYvIzuEYqvoq8G3mY+uXT9HDGpGuHG13i/6WN/iyW9yvo16u2pu
I/SvYURqqXa0v0KtYtV2NVGVAjQafh3ciJ9DWKhjbLgSanjjUUACKu6z8qL2qNsx
uORK/Xo4Lk5HmpGIbJTBJhcxYnor+DeedTyV3UxLfRcEHJ9h5OYS0w08KGbVyQ/T
r52OeURaF/wXjRgMr0yyAIOcnbpkNG60mZpeqm8Fq4uxGXK+bENE0Ca1jq/ai10Q
OTCiTX52oSFkVBHzksSZaVyuzXtdks0fKjFw36jmurzgsRmyWOODc2RXz3HCV2VO
yomMGY3fWioipeJ0RR7k
=oZJr
-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/3be36582-aba0-1eb5-a7f3-ea9aa141bda0%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] disposableVM not really disposable

2016-07-26 Thread cubit

Heyya

I have discovered my disposableVM Firefox is not really disposable as history 
persists between sessions.

This came to notice as I have recently customized my browser, setting up a new 
start page and removing the hello and pocket buttons.  Though I have noticed 
similar issues before customization though did not think to check if history 
was being stored.

Over the last couple of days each time I start Firefox I get the "Well, this is 
embarrassing." error with a restore session tab for my home page.  I also get 
two other tabs to Mozilla pages => The first run page and a bit ironically a 
page showing the private browsing mode.

I opened the history tab today to discover I have 3 days worth of history 
stored in the browser.

I can work around this by doing a qvm-create-defalult-dvm   
but I would like to know what is the best way to fix this permanently.


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

Re: [qubes-users] Re: Qubes Security Bulletin #24 (Critical bug)

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2016-07-26 08:58, Bill Wether wrote:
> On Tuesday, July 26, 2016 at 8:06:25 AM UTC-4, Joanna Rutkowska 
> wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Dear Qubes users,
>> 
>> We have just released a new Qubes Security Bulletin (QSB #24)
>> for a critical bug in the Xen hypervisor:
>> 
>> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/ 
>> qsb-024-2016.txt Please install the updates, immediately.
>> 
>> Regards, joanna.
> 
> Yikes, not again.
> 
> Thanks for the prompt notice and quick action, Joanna et al.
> 
> Re: ditching PVM for Qubes V4:
> 
> Could you give us AMD fans a word or two on what the new hardware 
> requirements are going to be?  I have a few 2011-ish Magny Cours 
> Opteron boxes that I'd like to keep running Qubes on.
> 
> Thanks
> 
> BillW
> 

The updated requirements for Qubes R4.x-certified hardware are
explained here:

https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/

Although the requirements for Qubes-certified hardware are likely to
be more stringent than that minimum requirements for running Qubes at
all, this may still be helpful for you to know.

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

iQIcBAEBCgAGBQJXl6DxAAoJENtN07w5UDAw5qwP/1bMU3+AzsuSjfaqp/e4iAjE
n2vigqQlYUMJyAQyGp/CFaaTe2othdYxLdOlUP90DzZmULvJe4O82j3hwHUjDk8s
MyUqzxBcFEJXvdPOFGgeiZefEeVcuw0VIY6oTxkpGcoYd8xBOHF0QX3wWIPgMBbe
K0WW9s2NHoPOtL7M/4NlGHLYt9zhOZsi1SuFe1jIRU/Pha44P7IB4E9yk8xin+AI
2ZuYTg++yFk4MXPV+X8VqJlU2lOmqAOaQL9kBlBkxWGoRlw7BTW2TXjKGGPZVc3a
2LliUWjBFnG/BFrbrWBmfYlqcuy3lpVI8XK64BE9fAsTPUkYgoCyjkfEq9U2A+UX
b05O8rJnPD4RRZ4px6IBHsm/0HAtQHjGRSTLB8qw/LV7qyKiNECTA7p+Z402rlL6
C2PO77iTVtY8gVjeBR55ch3jSCdfcoYmneMSdpkS+0RUUC4bq6b55H9AAsxqAfQn
3HT1sggwCtOZ72QcNHCEHSsqckQAQVcnxHJabtCq4lh1jQnFGp4akD/p166H6xM9
WRL/NTvRHb8zurxPDgZSxbcVs5xIbtWBLy7/ZxAFSpbMjPQp1KYlBmd/fkAFd8Nm
HDBhtH3T5by9Iy+R9sSO9vWC/olGqh5bUr8Nq65pGsMsWYkNn0uG914jMruEGbSJ
20LiUsD/jNwE09SGlK5h
=TU3b
-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/80f00ea1-b982-6ac5-d818-7b9b6ee0d7e8%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Bill Wether

On Tuesday, July 26, 2016 at 8:06:25 AM UTC-4, Joanna Rutkowska wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear Qubes users,
> 
> We have just released a new Qubes Security Bulletin (QSB #24) for a critical 
> bug
> in the Xen hypervisor:
> 
> https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt
> 
> Please install the updates, immediately.
> 
> Regards,
> joanna.

Yikes, not again.

Thanks for the prompt notice and quick action, Joanna et al.

Re: ditching PVM for Qubes V4:

Could you give us AMD fans a word or two on what the new hardware requirements 
are going to be?  I have a few 2011-ish Magny Cours Opteron boxes that I'd like 
to keep running Qubes on.

Thanks

BillW

-- 
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/3cb61675-7bf2-4b32-bdc3-379c06f26d03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Niels Kobschaetzki


On 16/07/26 08:58, Bill Wether wrote:

On Tuesday, July 26, 2016 at 8:06:25 AM UTC-4, Joanna Rutkowska wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Qubes users,

We have just released a new Qubes Security Bulletin (QSB #24) for a critical bug
in the Xen hypervisor:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt

Please install the updates, immediately.

Regards,
joanna.


Yikes, not again.

Thanks for the prompt notice and quick action, Joanna et al.

Re: ditching PVM for Qubes V4:

Could you give us AMD fans a word or two on what the new hardware requirements 
are going to be?  I have a few 2011-ish Magny Cours Opteron boxes that I'd like 
to keep running Qubes on.


Yeah, I was wondering about the same. I am using a Lenovo Thinkpad X201
and wondered if Qubes 4 will still run on the machine. 


Niels

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

Re: [qubes-users] How to log all the websites accessed by a VM

2016-07-26 Thread R.B.

On 07/26/2016 12:58 AM, Franz wrote:

On Mon, Jul 25, 2016 at 5:40 PM, R.B. > wrote:

shortened a bit...

Hi Franz,

The way I use it:

- Make sure Marek's perl script is in the vm you want to monitor.
Preferably in /home/user.
- Make sure the firewall is set to "Deny network access except..."
by default.
- Open a terminal in Dom0.
- Enter the command:
qvm-run --pass-io YourVM 'sudo tcpdump -vni eth0 port 53 or icmp |
perl ./firewall-learn.pl '

Thanks for the example, this goes a little more, in dom0 I reach the step:
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes

but then instead of
qvm-firewall -a debian-8-multimedia-dvm 104.20.30.3 tcp 443 that I get
on dispVM terminal

I get nothing more appearing on Dom0 terminal.

On the other hand if I try to use Marek suggestion adding "cat" with
something like
qvm-run --pass-io disp16 'cat sudo tcpdump -vni eth0 port 53 or icmp |
perl ./firewall-learn.pl '

Hi Franz,

I tried it your way and it won't give immediate results. Looks like some
bucket of 262144 bytes has to be filled with enough packets before
tcpdump passes the data. After some effort requesting for a site
repeatedly, the buffer gets dumped finally ;-)

Could not find a quick way to remedy this though.

Greetings,

--
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/ee1e78f3-f076-415b-ad73-9272afe60eb0%40reboli.nl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to log all the websites accessed by a VM

2016-07-26 Thread Steve Coleman

Another hack to avoid having to manually type in the addresses is done 
with the attached script. Its like Mareks solution, but does the parsing 
on the dom0 side and the syntax is a little easier. It does the remote 
tcpdump command in the vm and the results are returned through the 
pass-io mechanism. With the -A option the script then generates the 
qvm-firewall add commands to its stdout.

Then, if you want to add that address to the firewall you simply copy 
and paste the lines you want from that dom0 command terminal window into 
another dom0 command window, and the address is added to the firewall 
without any manual typing. If you want, you can add a netmask (e.g. 
address/24) to an IP in the target window before pressing enter.

[user@dom0 ~]$ qvm-fwdenied -A 
qvm-firewall  -add 
ec2-54-200-125-198.us-west-2.compute.amazonaws.com any

qvm-firewall  -add 104.244.43.140 any
qvm-firewall  -add 104.244.43.44 any
qvm-firewall  -add 
ec2-54-148-80-75.us-west-2.compute.amazonaws.com any
qvm-firewall  -add 
ec2-52-88-118-150.us-west-2.compute.amazonaws.com any
qvm-firewall  -add 
ec2-52-25-189-162.us-west-2.compute.amazonaws.com any

...

Note that these appear in batches on the console because tcpdump is in a 
mode where it exits after some number of captured packets have been 
filtered, with the default set to 200 packets. By default it will 
repeatedly restart tcpdump for another batch. The -C ### option allows 
that default number of packets to be changed.

It would be far better if the script was made to be multi-threaded so 
the output of tcpdump could be read while another thread outputs the 
commands and asks the user if each entry should be added or not. I just 
have not had time to look into that yet. its obviously a work in progress.

Also it logs everything to /var/tmp/qvm-fwdenied.log if you need to look 
at what happened in your last session.

On 07/25/2016 02:14 PM, Franz wrote:

On Mon, Jul 25, 2016 at 2:51 PM, Marek Marczykowski-Górecki
> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Mon, Jul 25, 2016 at 02:46:55PM -0300, Franz wrote:
> On Mon, Jul 25, 2016 at 1:24 PM, Marek Marczykowski-Górecki <
> marma...@invisiblethingslab.com
> wrote:
> > On Mon, Jul 25, 2016 at 12:06:54PM -0300, Franz wrote:
> > > On Mon, Jul 25, 2016 at 11:11 AM, Marek Marczykowski-Górecki <
> > > marma...@invisiblethingslab.com
> wrote:
> > > > On Mon, Jul 25, 2016 at 09:37:10AM -0400, Steve Coleman wrote:
> > > Anyway regarding Marek script I tried it in a dispVM, it writes:
> > > tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size
> > > 262144 bytes
> > >
> > > but then if on the same dispVM I use firefox to go to a gmail account 
or
> > > another account, nothing appears on the terminal.
> > >
> > > I even looked if anything changed on dispVM firewall rules, but found
> > > nothing different.
> > >
> > > So how is this script working?
> >
> > I've just tried and it is still working. It should output list of
> > blocked destinations in format of qvm-firewall commands ready to load
> > into Qubes firewall.
> >
> ,
> "blocked destinations"?  This makes me think that I should block
> destinations somehow before running the script. Is that so?

Yes, change VM firewall to deny by default.

ok now it works, it outputted a list of addresses. But I have to paste
this list on firewall rules of that VM and this is on Qubes Manager that
is on Dom0, so normal copy paste between VMs does not work.

I can only imagine of writing the addresses on a text file, then copying
the file to Dom0, using

|qvm-run --pass-io  'cat /path/to/file_in_src_domain' >
/path/to/file_name_in_dom0|

opening the file in Dom0 (which seems half prohibited) and finally
copying the adresses to Qubes Manager.

Otherwise I'll have to digit manually the addresses to Qubes Manager.

Which is the suggested way to do that?

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

iQEcBAEBCAAGBQJXllGTAAoJENuP0xzK19cswBgH/A0OxAIaR7hzEfET8uAcNeiC
IjTNevVwL/z1ymB4HLwdQmOi3AQ5q8db/AoMd37AC06yzxEJkEQzt5HsMbnEK4UI
SFlKbKr5t7/eyK9R7B6dQH2dBL69ODZf8wQWl5T3oEJj3cZOCLOkAQZcjNHgPefU
AX2cKoi3q7TLxy810f08o+KicA2VclBA5Q66tf6GSoFG44VWfBtxZgkHTZ/s9aWW
cUvNfHIZtSZNiIOEJKLHP3y7tLAFZXOvdtIqIo2/jxWIJSc+47ypPxpOSiAdiA79
erUry7spy9ta5GNlblBf5fSGaQaYRBeEGl91+b++pX/zTg1/sMbv3hoCFpVHYnI=
=XmDi
-END PGP SIGNATURE-

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

Re: [qubes-users] Qubes Security Bulletin #24 (Critical bug)

2016-07-26 Thread Eva Star




Dear Qubes users,

We have just released a new Qubes Security Bulletin (QSB #24) for a critical bug
in the Xen hypervisor:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-024-2016.txt

Please install the updates, immediately.


Thanks. Undated successfully on Q3.2rc1

--
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/6e67a4e2-52ed-c5af-7862-6ddf74e2541e%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Cryptsetup LUKS Nuke Option

2016-07-26 Thread J.M. Porup

On Fri, Jul 22, 2016 at 07:39:40PM -0400, Chris Laprise wrote:
> But there is no need to patch LUKS to accomplish this, and using only
> passphrases as the trigger mechanism is probably too cumbersome in some
> situations anyway.
> 
> This could be scripted with better results and flexibility for the end user,
> obviating any need to meddle with LUKS code.
> 
> If there is already an issue# for a 'panic button' type of feature request,
> I'd suggest linking this thread to it.

This code already exists:

https://github.com/offensive-security/cryptsetup-nuke-keys

jmp

-- 
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/20160726135123.GB1121%40fedora-21-dvm.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Nautilus is broken