Re: [qubes-users] Proprietary application needs activation in each VM. But DVM?

[7v5w7go9ub0o]

On 08/31/2017 08:57 PM, Unman wrote:

On Thu, Aug 31, 2017 at 02:49:22PM -0300, Franz wrote:

On Thu, Aug 31, 2017 at 11:26 AM, Unman  wrote:


On Thu, Aug 31, 2017 at 07:20:29AM -0300, Franz wrote:

A proprietary application (Softmaker Office) even if installed in

template

then needs activation in each VM. After activation it puts some files in
home folder and works as expected and it is all OK.

But Disposable VM? Any activation is lost at next start. Is there a way

to

have the activation files persistent in the home folder?

Best
Fran


Start the DispVM template and activate the application there.
touch  ~/.qubes-dispvm-customized
regenerate the DispVM template

It's covered here:
www.qubes-os.org/doc/dispvm-customization



Thanks unman, but nothing seems to change after that.  I activated the
application inside DispVM, Also changed some "open with" nautilus
defaults. Than
created the empty file in DispVM, closed the DispVM and regenerated the
DispVM in dom0.  Correct?


If by DispVM, you mean the DispVM template, then that's exactly right.

When you open a terminal in a disposableVM, can you see the 
.qubes-dispvm-customized
file that you created in the dispVm template? (When I customise a dispVM
Template I always create a file that isn't hidden, listing the changes.
That way I can be sure that subsequent changes are being captured.)

If this is the case, then it's possible that your application is
checking some feature that ISN'T common between the disposableVMs - disk
signatures, MAC address perhaps?



In the old days, one could run a script which would start a generic 
dispvm; copy in (from, say, vault) the necessary executable and user 
files necessary to run a program; and start the dispvm.


When all done, the script would be signaled to copy any updated user 
files (typically text) back to the vault.



--
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/e68d271c-64c6-9da6-4d62-4490208bbef5%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Android-x86 6.0 (Marshmallow) on HVM, relatively usable for app debugging

[7v5w7go9ub0o]

On 08/25/2017 10:07 AM, Alex wrote:

Following up on my previous post on setting up Android 6.0 as a Qubes
HVM for app debugging purposes, I'm fixing some of the things that were
left unsolved, namely:
  * screen goes to unrecoverable standby after little time
  * fix vga settings in grub config
  * enable adb via tcp
  * allow VNC connections

First, we fix the screen timeout. That's relatively easy:
  * Open Settings
  * Go to "About Tablet"
  * Tap 8 times over the build number (until you're a developer)
  * Go back to settings
  * Go to newly added "Developer Options"
  * Enable "Stay awake"

Then we need to setup TCP connection to our work appvm (or the one in
which Android Studio is installed and will be used). These steps are
adapted from qubes-os.org/doc/firewall
  * Gather IP addresses (qubes ones) for work and android-6
  * Open a shell in sys-firewall
[sys-fw]$ sudo iptables -I FORWARD 2 -s  -d  -j ACCEPT
[sys-fw]$ sudo iptables -I FORWARD 2 -s  -d  -j ACCEPT
  * Open a shell in work appVM
[work]$ sudo iptables _I INPUT -s  -j ACCEPT
  * Firewall in Android-x86 already allows connections, so test:
[work]$ ping 
[android-terminal-emulator]$ ping 
  * Should be able to ping. If this is the case, follow instructions in
qubes-os.org/doc/firewall to ensure persistence of these settings in
both work appVM and sys-firewall.

Now we can configure the ADB TCP port for remote debugging:
  * inside Android open the terminal emulator again if closed
[android-terminal-emulator]$ su
[android-terminal-emulator]# setprop service.adb.tcp.port 
[android-terminal-emulator]# stop adbd
[android-terminal-emulator]# start adbd
  * check from work appVM (Android studio and the tools should have
already been installed, so that you have "adb" available)
[work]$ adb connect :
  * Should say "connected to 10.137.xx.yy:"
If this is the case, you now have a friendlier connection for your system!

Now our Android HVM will have to be booted from dom0 command line, but
we can make it easier by persisting the vga= config in grub. To do that,
we must restart Android and:
  * from the GRUB menu select the second line (Debug Mode)
  * boot will stop at a temporary root MirBSD Korn shell
  * give it a couple of Enter keys to clear logs out of the way
  * now type:
[android]# mount -o rw,remount /mnt
[android]# cd /mnt/grub
[android]# vi menu.lst
  * edit the file as to append the VGA parameter
 * press "i", move the cursor, add text
  * save and quit
 * press Esc, then type ":wq"
  * exit the shell TWICE and android will try to complete its boot
 * but because we did not set the "vga" parameter in the debug line,
it will most likely fail
 * kill the VM from VM Manager

Now we can start the android vm with a relatively easy dom0 command, it
will automatically and quickly boot to a relatively usable android
(sometimes some google background service will crash) with no problems
with screen timeouts. The only problem remaining is the mouse, that can
be bypassed with a VNC connection.

Problem is, our Android is x86 and most VNC servers out there are for
ARM devices. There is an x86 build of android-vnc-server at
http://xmodulo.com/how-to-run-vnc-server-on-android-x86.html but it has
not PIE enabled (some exploit protection) so Marshmallow will refuse to
load it.

Now you have TWO paths available:
one is
  * download the android-vnc-server project
  * update it and compile it for x86 with PIE
  * load it into our HVM and use it to connect

the other is
  * patch the /system/bin/linker executable in Marshmallow to avoid PIE check
  * load the already compiled assembly found at previous link
  * use it to connect

I went through the second path, since I'm more of a reverse engineer
than a library archaeologist, and really don't like the idea of trying
to compile things from the past with obscure (to me) options.

I found a nice explanation at
https://forum.xda-developers.com/google-nexus-5/development/fix-bypassing-pie-security-check-t2797731/page13#127
about a guy that did exactly this patch for Android 5.1. Following his
steps I disassembled /system/bin/linker from our Marshmallow HVM and
found that the 4 bytes to patch for the check are at 0xD25A (file
offset): they start with 0x0F 0x85. Patch the 4 bytes with four NOPs
(0x90), save, and replace the linker with your patched version.
  * put the new linker in /storage/emulated/0/linker_new
  * restart the Android HVM in Debug mode again
  * once there the layout of the FS is completely different
 * find linker_new inside /mnt/android-6.0-r1/data/media/0/
 * copy it over to /android/system/bin
 * chmod it to 755
  * exit TWICE from the MirBSD shell and kill HVM
  * start android normally (via the qvm-start custom command, as usual)
  * push droidvnc_x86 you downloaded from the link above into the VM
[work]$ adb push droidvnc_x86 /storage/emulated/0/
[work]$ adb shell
[adb]$ su
[adb]# mv /storage/emulated/0/droidvnc_x86 /system/bin/
[adb]# chmod 

Re: [qubes-users] Problem installing Qubes on Lenovo Thinkpad T450s

[7v5w7go9ub0o]

On 08/07/2017 04:16 PM, Janik Besendorf wrote:

Hi,

I have a T450s and followed the instructions here
https://www.qubes-os.org/doc/thinkpad-troubleshooting/ for the UEFI
options but when I select "Install Qubes" in the bootmanager the
installer start loading image files but then reboots the laptop.

A friend of my once had the same problem with a T450 and told me that he
needed an older kernel in order to install Qubes. Does anyone know more
about that?

greetings,

Janik Besendorf


Sorry, can't answer your question.

Recent update, ICYDK: 



--
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/7e53d92c-a6f6-e201-1091-6cbfa3fb4484%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes Canary #12

[7v5w7go9ub0o]

On 06/05/2017 01:42 PM, Andrew David Wong wrote:



> 1. The date of issue of this canary is June  2, 2017.



>
> 5. We plan to publish the next of these canary statements in the first
> two weeks of September 2017. Special note should be taken if no new canary
> is published by that time or if the list of statements changes without
> plausible explanation.




Thanks for the note.

IIUC, the canary system is now quarterly and three months until the next 
canary. That also means that a back-door and gag order could be placed 
into effect against Qubes today, and users would be clueless about it 
'til September - up to three months of user jeopardy if there are Summer 
updates.

The cautious user will reason that his system updates should be only 
applied immediately before the Quarterly canary; thereby assuring - 
after the canary is issued - that his quarterly update(s) was not 
back-doored. This could be a disaster if an accidentally flawed update 
happened to get out.

Please consider *increasing* the frequency of canaries - not decreasing. 
Alternatively, consider issuing additional canaries shortly after 
important system updates, and scheduling "minor" system updates a week 
before the quarterly canary.

A weekly canary would be much more useful and reassuring, as I wouldn't 
have to wait to do updates. Also, ISTM weekly would be easier for ITL to 
manage.

-- 
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/59358008.01d1370a.26783.520c%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Kicking the sudoers dead horse

[7v5w7go9ub0o]

On 03/14/2017 06:08 AM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-12 15:09, 7v5w7go9ub0o wrote:

On 03/12/2017 12:45 PM, Andrew David Wong wrote:

On 2017-03-11 19:41, Unman wrote:

On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:

On 03/11/2017 11:56 AM, Unman wrote:

On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:

7v5w7go9ub0o:

Yep! And ISTM this is an argument for using dispvms to
handle mail (or any other WAN-exposed client/server):
start a dispvm; copy mail client and mail "file" into
it; do your mail; copy out and save the updated mail
file (which is text); flush away the dispvm - all
handled by a script(s).

How do you figure that's less of a pain in the ass than
typing a sudo password?


You're missing the point - that procedure is trivial to set
up in Qubes and addresses real security concerns. Just
putting a password on root access, or requiring some dom0
interaction doesn't.

This is important - security IS a pain in the ass. Qubes
can make it less so.


Yes, sm8ax1 got you there. :)

DispVMs are nice to have when we think that certain
operations carry threats. But its ridiculous to expect a
typical user to do a majority of their tasks in them.


No, it isn't ridiculous to expect a typical user to work in
disposableVMs. I've set up a number of users with a range of
experience, and they are very comfortable with this. If the
implementation is kept hidden generally speaking everything
goes fine. Some scripting to make things easier, and support
is probably no greater than usual ,except for "that funny copy
thing". I've said this before.

Set up right I don't think that Qubes is outrageously difficult
to use, even with disposableVMs doing most of the heavy
lifting. But that's a separate issue.



Agree with all of this. Working in a DispVM (e.g. browser, or mail)
is the same experience as working in a VM. Only difference is
clicking a script to start it up; inform the script of the DispVM
to work in; and telling the script to shutdown (copy updates) at
the end - in my case by entering a 



I'd be interested in hearing more about this (in a separate
thread, perhaps).

In particular, no one has, to my knowledge, attempted to rebut
the arguments I advanced against the "doing everything in
DispVMs" approach here:

https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J

RATS!  I missed that.



Granted, that was almost two years ago, and some of the things I
wrote there no longer apply. However, I still haven't seen a
strong case made *in favor* of this approach to begin with. I
would like to see one.


This is the first I've seen your 4/1/15 note - sorry - wish we
could have discussed it then.

I also forwarded that message to you directly and invited you to have
an offline discussion about it (shortly after receiving no reply from
you on-list), but no worries.


Dang! Sorry again!!





You have the basic idea except for the vital point of what happens
at end of DispVM session (copying as few as possible user files
back to a VM or Vault). I take your point 4 on space, and point 6
on RAM and CPU usage.

I disagree on critical point 5.

For example running a browser in a VM is indeed "more secure" than
  running it in a VM because only specific updated files (bookmarks
- places.sqlite) are retained and copied back to the vault at end
of session; no other user-land files (and surprise relics) are
copied back; this is contrary to what is presumed in that write up.
If if the bookmarks weren't changed, simply flush the DispVM away.

Doing mail in a DispVM is also "more secure" for the same reason -
only specific updated files are retained at end of session - no
other user-land files (and relics) are copied back to a VM. This is
key, and why this is more secure.


I think I understand the setup now. I agree that this is technically
more secure in the sense that your inter-session persistent attack
surface is reduced (fewer persistent files; a greater number of files
are "templatized"). However, it seems like a very minor security gain
for a huge cost in initial setup and inconvenience (see below).




Do you
agree that the security gain is relatively minor, or do you have some
reason to think that it is significant?


Aha!!

The key issue!!

1. Is the security gain very minor? (and is its huge cost in initial 
setup and inconvenience worth it?)


(Heh as a side, of course the same questions can be asked of Qubes 
itself - for users who use their computers to check their text-only 
email and don't go "surfin", the realized security gain likely doesn't 
appear to outsiders worth the cost. Box gets infected, go get a new one 
for 2 or 3 hundred.)


My DispVM is no more resistant to a WAN attack than an AppVM.  One is 
really asking the value (security gain) of eliminating persistence, if a 
bug is ingested.


I subscribe to a number of Usenet

Re: [qubes-users] Kicking the sudoers dead horse

[7v5w7go9ub0o]

On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>>> On 03/11/2017 11:56 AM, Unman wrote:
>>>> On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
>>>>> 7v5w7go9ub0o:
>>>>>> Yep! And ISTM this is an argument for using dispvms to
>>>>>> handle mail (or any other WAN-exposed client/server):
>>>>>> start a dispvm; copy mail client and mail "file" into it;
>>>>>> do your mail; copy out and save the updated mail file
>>>>>> (which is text); flush away the dispvm - all handled by a
>>>>>> script(s).
>>>>> How do you figure that's less of a pain in the ass than
>>>>> typing a sudo password?
>>>>>
>>>> You're missing the point - that procedure is trivial to set up
>>>> in Qubes and addresses real security concerns. Just putting a
>>>> password on root access, or requiring some dom0 interaction
>>>> doesn't.
>>>>
>>>> This is important - security IS a pain in the ass. Qubes can
>>>> make it less so.
>>>>
>>> Yes, sm8ax1 got you there. :)
>>>
>>> DispVMs are nice to have when we think that certain operations
>>> carry threats. But its ridiculous to expect a typical user to do
>>> a majority of their tasks in them.
>>>
>> No, it isn't ridiculous to expect a typical user to work in
>> disposableVMs. I've set up a number of users with a range of
>> experience, and they are very comfortable with this. If the
>> implementation is kept hidden generally speaking everything goes
>> fine. Some scripting to make things easier, and support is
>> probably no greater than usual ,except for "that funny copy thing".
>> I've said this before.
>>
>> Set up right I don't think that Qubes is outrageously difficult to
>> use, even with disposableVMs doing most of the heavy lifting. But
>> that's a separate issue.

Agree with all of this. Working in a DispVM (e.g. browser, or mail) is
the same experience as working in a VM. Only difference is clicking a
script to start it up; inform the script of the DispVM to work in; and
telling the script to shutdown (copy updates) at the end - in my case by
entering a 



> I'd be interested in hearing more about this (in a separate thread,
> perhaps).
>
> In particular, no one has, to my knowledge, attempted to rebut the
> arguments I advanced against the "doing everything in DispVMs"
> approach here:
>
> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J


RATS!  I missed that.


>
> Granted, that was almost two years ago, and some of the things I wrote
> there no longer apply. However, I still haven't seen a strong case
> made *in favor* of this approach to begin with. I would like to see one.
>
> - -- 
> Andrew David Wong (Axon)


This is the first I've seen your 4/1/15 note - sorry - wish we could
have discussed it then. You have the basic idea except for the vital
point of what happens at end of DispVM session (copying as few as
possible user files back to a VM or Vaulted user configuration). I take 
your point 4 on
space, and point 6 on RAM and CPU usage.

I disagree on critical point 5.

For example running a browser in a VM is indeed "more secure" than
running it in a VM because only specific updated files (bookmarks -
places.sqlite) are retained and copied back to the vault at end of
session; no other user-land files (and surprise relics) are copied back;
this is contrary to what is presumed in that write up. If if the
bookmarks weren't changed, simply flush the DispVM away.

Doing mail in a DispVM is also "more secure" for the same reason - only
specific updated files are retained at end of session - no other
user-land files (and relics) are copied back to a VM. This is key, and
why this is more secure.

   At startup, the user configuration file (.Thunderbird) is copied into
the DispVM, followed by the latest volatile user data files.

(If there is need to permanently change something in the user
configuration - I haven't in years - one simply starts up the
DispVM/tbird proggy, makes the configuration change doing no mail,
Usenet, etc., and promptly copies the newly changed, whole user
configuration back to the vault, followed by immediate shutdown.)

Also disagree on your second part of 6; I've been using this and other
DispVM scripts since Q2.0 or Q2.1; I've become lazy as they just work!
Infrequently I'll get a "failed to start" DispVM message, in which case
I'll start one manually 

Re: [qubes-users] Kicking the sudoers dead horse

[7v5w7go9ub0o]

On 03/12/2017 12:45 PM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-03-11 19:41, Unman wrote:
>> On Sat, Mar 11, 2017 at 08:47:05PM -0500, Chris Laprise wrote:
>>> On 03/11/2017 11:56 AM, Unman wrote:
>>>> On Sat, Mar 11, 2017 at 04:43:41PM +, sm8ax1 wrote:
>>>>> 7v5w7go9ub0o:
>>>>>> Yep! And ISTM this is an argument for using dispvms to
>>>>>> handle mail (or any other WAN-exposed client/server):
>>>>>> start a dispvm; copy mail client and mail "file" into it;
>>>>>> do your mail; copy out and save the updated mail file
>>>>>> (which is text); flush away the dispvm - all handled by a
>>>>>> script(s).
>>>>> How do you figure that's less of a pain in the ass than
>>>>> typing a sudo password?
>>>>>
>>>> You're missing the point - that procedure is trivial to set up
>>>> in Qubes and addresses real security concerns. Just putting a
>>>> password on root access, or requiring some dom0 interaction
>>>> doesn't.
>>>>
>>>> This is important - security IS a pain in the ass. Qubes can
>>>> make it less so.
>>>>
>>> Yes, sm8ax1 got you there. :)
>>>
>>> DispVMs are nice to have when we think that certain operations
>>> carry threats. But its ridiculous to expect a typical user to do
>>> a majority of their tasks in them.
>>>
>> No, it isn't ridiculous to expect a typical user to work in
>> disposableVMs. I've set up a number of users with a range of
>> experience, and they are very comfortable with this. If the
>> implementation is kept hidden generally speaking everything goes
>> fine. Some scripting to make things easier, and support is
>> probably no greater than usual ,except for "that funny copy thing".
>> I've said this before.
>>
>> Set up right I don't think that Qubes is outrageously difficult to
>> use, even with disposableVMs doing most of the heavy lifting. But
>> that's a separate issue.



Agree with all of this. Working in a DispVM (e.g. browser, or mail) is 
the same experience as working in a VM. Only difference is clicking a 
script to start it up; inform the script of the DispVM to work in; and 
telling the script to shutdown (copy updates) at the end - in my case by 
entering a 


> I'd be interested in hearing more about this (in a separate thread,
> perhaps).
>
> In particular, no one has, to my knowledge, attempted to rebut the
> arguments I advanced against the "doing everything in DispVMs"
> approach here:
>
> https://groups.google.com/d/msg/qubes-users/nDrOM7dzLNE/Kr5W3BUkcG4J

RATS!  I missed that.


> Granted, that was almost two years ago, and some of the things I wrote
> there no longer apply. However, I still haven't seen a strong case
> made *in favor* of this approach to begin with. I would like to see one.
>
> - -- 
> Andrew David Wong (Axon)
>


This is the first I've seen your 4/1/15 note - sorry - wish we could 
have discussed it then. You have the basic idea except for the vital 
point of what happens at end of DispVM session (copying as few as 
possible user files back to a VM or Vault). I take your point 4 on 
space, and point 6 on RAM and CPU usage.

I disagree on critical point 5.

For example running a browser in a VM is indeed "more secure" than 
running it in a VM because only specific updated files (bookmarks - 
places.sqlite) are retained and copied back to the vault at end of 
session; no other user-land files (and surprise relics) are copied back; 
this is contrary to what is presumed in that write up. If if the 
bookmarks weren't changed, simply flush the DispVM away.

Doing mail in a DispVM is also "more secure" for the same reason - only 
specific updated files are retained at end of session - no other 
user-land files (and relics) are copied back to a VM. This is key, and 
why this is more secure.

  At startup, the user configuration file (.Thunderbird) is copied into 
the DispVM, followed by the latest volatile user data files.

(If there is need to permanently change something in the user 
configuration - I haven't in years - one simply starts up the 
DispVM/tbird proggy, makes the configuration change doing no mail, 
usenet, etc., and promptly copies the newly changed, whole user 
configuration back to the vault, followed by immediate shutdown.)

Also disagree on your second part of 6; I've been using this and other 
DispVM scripts since Q2.0 or Q2.1; I've become lazy as they just work! 
Infrequently I'll get a "failed to start" DispVM message, in which case 
I'll start one manually and

Re: [qubes-users] Kicking the sudoers dead horse

[7v5w7go9ub0o]

On 03/11/2017 12:10 PM, Alex wrote:
> On 03/11/2017 12:14 PM, Chris Laprise wrote:
>> On 03/11/2017 04:20 AM, Alex wrote:
>>> the only really read-write directories (their changes are actually
>>> persisted) are /home and /usr/local.
>> That is enough to be able to persist.
> Yes, and that doesn't even need root :) So, both having root or not,
> there is some degree of persistence attainable.
>
> Installing via DNF or any other package manager is an easy route to put
> files in the relevant "system" directories, but since these are not
> persisted, it's actually more convenient, from a malware point of view,
> to just place them in the home of the user and set up some kind of
> autostart (eg bashrc, or systemd user units, or gnome autostarts).




Yep! And ISTM this is an argument for using dispvms to handle mail (or 
any other WAN-exposed client/server): start a dispvm; copy mail client 
and mail "file" into it; do your mail; copy out and save the updated 
mail file (which is text); flush away the dispvm - all handled by a 
script(s).

Don't retain potentially infect-able user files; stop, flush, and 
restart frequently.

Paranoids accessing dangerous mail servers can run multiple mail clients 
in multiple dispvms so that if one is compromised, only that 
correspondence is lost - one could also run Samhain to monitor unusual 
behavior.






>
>>> As the others already stated there could be problems for the
>>> actually running session, i.e. the rogue command could siphon all
>>> your data to a remote location, but it would be only able to access
>>> data in that AppVM and not the others. This action would not need
>>> any root access, because all data is from the very same user that
>>> downloaded/started the rogue program in the first place, so it
>>> already has access.
>>>
>>> The only advantage that root access would give could arguably be
>>> persistance (i.e. installation, as you suggested with DNF), but
>>> that advantage is fake and will vanish on AppVM reboot.
>> Disagree there. Root access would bestow greater ability to launch
>> attacks against VM isolation. That would be rare in of itself, but
>> the chance for improved security comes for free.
> And that's the point where I agree with you, I overlooked the
> exploitability of Xen virtual devices in my original answer. Software
> running as root has easier access to the Xen para-vm communication
> devices, and that may lead to crossing the VM isolation.
>
>
>> There is another, much bigger issue: We don't want our systems to
>> become a zoo of infected VMs with malware thrashing about in them
>> (and on our networks!) with us as zookeepers. That would be
>> irresponsible.
>>
>> Qubes' abilities should not be framed in a way that would encourage
>> that. Even if isolation works 100% of the time, we should view that
>> as the opportunity to remove and prevent malware---preferably with
>> some help from the guest OS.
>>
>> Put another way: If VMs were teeth, would you prefer to have one
>> cavity this year, or seven?
> That's a gross oversimplification of the situation. In Qubes there are
> several AppVM that are "all created equal", but to the user there MUST
> be some difference, and he is advised to make use of the colored labels
> to emphasize and remind these differences.
>
> While I don't certainly want to have all red-labeled VMs (i.e. the
> malware zoo situation you propose), I'm pretty sure I will not trust
> some VMs because they are used with dangerous websites/software. I will
> consider them dangerous even with passwordless sudo disbled, because
> there may be some 0-day that has been exploited for a local privilege
> escalation that makes sudo a non-problem.
>
> I make sure to periodically purge those VMs (which I named dump-0,
> dump-1, etc to even remember that they are not to be trusted and because
> when I forget why they are here (hence, the cryptic name) they can be
> safely deleted), and because of the periodic update restart cycles all
> other AppVMs are not always on, so malware cannot rely on system level
> persistence there. In those "safer" appVMs, I don't open suspicious
> e-mails nor visit doubtful websites; activities that I try to perform in
> the unsafe AppVMs.
>
> TL;DR: there's no malware disadvantage if there is no passwordless sudo
> in Qubes (it can persist as the user, and can still see all the files of
> that user), and there's very little advantage (temporary persistence in
> "system" directories) that may even become a decoy of some sort with
> passwordless sudo being enabled.
>
> In my humble opinion, this absence of actual advantages or disadvantages
> makes the whole situation irrelevant from a security standpoint. There
> are other issues that should be taken into account for a more complete
> answer than just security as holy grail, and they can safely be
> introduced in the decision when the security outcome is the same. They
> range from "is having to remember several different root/sudo 

Re: [qubes-users] Qubes 4 Release Date

[7v5w7go9ub0o]

On 03/07/2017 08:04 AM, qube...@tutanota.com wrote:
> Back in July 16 Joanna announced 
> (http://qubesos4z6n4.onion/news/2016/07/21/new-hw-certification-for-q4) 
> that Qubes 4 was due to be released later that year in Sept 16.
> Has Qubes 4 been scrapped? Anyone any idea if/when it will be released?


Their priority is to get it right; their response to 
questions/complaints like this have historically been that it'll be 
released when it's ready.

Given the number of users now using or wanting to use Qubes, the range 
of their technical abilities, and that the new users want to use Qv4 as 
plug-and-play full production, ITL would be smart to take their time on 
releases from now on and get them *very* right.

-- 
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/58bee562.90d1370a.70dea.253b%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to destroy files without leaving any traces ?

[7v5w7go9ub0o]

On 10/27/2016 12:14 PM, Manuel Amador (Rudd-O) wrote:

On 10/26/2016 04:46 PM, maritnez wrote:

you have a file that contains sensitive banking data and would like to delete 
it without leaving any traces on your system.

you can 'move it to trash'
which moves it to the trash

you can then press the delete button in your trash container but
is this really securely deleting the file without any chance of recovering it?


how to delete files without leaving ANY trace from it?


Here is what happens when you do that in a VM, assuming the data is
stored in /home or /rw:

1. VM file moves to trash.

2. you empty the trash in the VM.

3. In 5 seconds, the VM kernel's ext4 file system commits the metadata
change to /dev/xvdb, and discards the data blocks that were occupied by
the file.

4. The discard makes its way to dom0's
/var/lib/qubes/appvms/vm/private.img by way of the loopback device that
was connected to the VM in representation of the private.img file.

5. Since loopback devices honor discard, and since loopback devices
mapping files issue PUNCH_HOLE or zero out the relevant data on the
file, that means the discard operations make their way into private.img
as either blocks zeroed out or PUNCH_HOLE operations.

6. The dom0 file system hosting that private.img file can do any number
of things about these incoming operations:

6.1. If ext4: after 5 seconds, the discard operation makes its way to
the underlying block device; this may be 100% ineffectual in rotational
devices that do not support discard, and may also be 100% ineffectual in
the case of SSDs as they may decide to forego deleting the data and just
add those disk regions to a fresh pool of writable flash (while keeping
the "zeroed" data hidden from you. but certainly not from governments)

6.2. If ext4 on top of LVM: ask someone else, as I'll put it bluntly: I
do not know what that shit does, and I do not know if anyone knows.

6.3. If ZFS or btrfs: the file system code will do copy on write, which
means the blocks will still be available in some other region of the
disk, until they get overwritten by new writes.  Worse still, if the
data you just tried to zero out in the VM actually happens to be in a
file system snapshot of dom0, then by definition it will not ever get
deleted, until you kill the snapshot and zero out all storage on the
devices.

It's more complex than that, though.

First rule of thumb: IF you wrote X to disk, THEN be sure X is going to
be there.

Second rule of thumb: IF you read data chunk X with a program at some
point, THEN it's likely that X is going to be on disk too, because of
swap (read -> memory -> swapout -> disk).

The way to get around these rules of thumb is (a) make sure that data
always hits the disk encrypted (b) make sure to never ever let any
adversary read from that disk while unencrypted, or obtain the key to
that disk.

The takeaway: deleting data is REAL HARD.  You better have a good
encryption password.

The honest, cheap-to-execute answer to your question is: get a blowtorch
and torch the individual data-bearing parts of the drive, until each
part changes color, and then some.  Don't breathe the magic smoke coming
out of these parts — it may kill you.




(Heh... "magic smoke", eh!?)

(Newbie question:) Is there a possibility of using "mlock" to block 
swap;  working entirely in ram - de-crypting the imported subject file 
using "tmpfs" interim files, then exporting the updated, encrypted 
subject file back to vault (or out the door)? I'd guess this would leave 
you vulnerable only to someone hands-on dumping your memory? I'd presume 
doing all of this in a DispVM would preclude some "relic" remaining in a 
Domain. (One wouldn't want any (encrypted) relics in case of a 
rubber-hose interrogation and demand for passwords.)


p.s. Thank You for your helpful postings here!!


--
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/f5303c85-6554-68ce-2901-2b8b69ffcd1b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Future plans for KDE on Qubes?

[7v5w7go9ub0o]

On 10/23/2016 09:38 AM, Achim Patzner wrote:

Hi!


After a few months of severe suffering from xfce on a HiDPI display I
gave in and installed @kde-desktop-qubes on my system – and I'm pretty
sure I don't want to see xfce for the next few years. Title bars have a
usable size (something that cannot be configured in xfce without
building your own themes), icon aren't scaled randomly and fonts are
finally looking as they should. And third-party software like Softmaker
Office is finally working as expected. So: Will there be support for KDE
beyond Qubes 3.2 or will I have to plan for carrying a third machine for
my office work space?


+1

Never thought I'd admit it, but KDE (despite its legendary (and today 
overstated) bloat and complexity) - actually works rather well.



--
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/ca85a02c-7443-c020-fb54-d3bb00e55e0f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Most Secure way to encrypt your usb stick ?

[7v5w7go9ub0o]

On 10/22/2016 12:09 PM, lakschmi wrote:

have sensitive data on your usb stick?

whats the best way to encrypt/decrypt it?



normally I use whonix-ws pgp and encrypt every file but Id rather have a 
different method


I can't help you - sorry - but I suspect someone might ask:

1. Do you need to have individually-encrypted files?

2. If yes, are they the same key?

3. Would mounting the USB stick as an encrypted volume be satisfactory?

is there a way to install the tails os ecryption system in qubes os?
I prefere it over the whonix workstation system.



Can't help here either. But you might get some interesting replies if 
you indicated WHY you would prefer tails over whonix - understanding 
that R4.x may allow you to run the two whonix components as DispVMs.



--
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/73702be7-816d-106a-2164-331ab7da202e%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[7v5w7go9ub0o]

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

It gives me great pleasure to release the first iteration of the
leakproof Qubes VPN.

https://github.com/Rudd-O/qubes-vpn

This package allows you to set up a leakproof OpenVPN VM on your Qubes
OS system. All VMs attached to the VPN VM are automatically and
transparently routed through the VPN. DNS requests do not hit the NetVM
they get routed through the VPN instead.

Users and developers welcome to contribute to the project in any way you
can!



(Nice documentation!)

TU, Sir!

--
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/f182d02e-b143-ad31-7d93-b1f4076baf2f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts about installed software

[7v5w7go9ub0o]

On 10/12/2016 02:22 PM, Robert Mittendorf wrote:

Am 10/12/2016 um 04:00 PM schrieb 7v5w7go9ub0o:



On 10/11/2016 09:30 AM, Robert Mittendorf wrote:
Software that you don't need is a security risk as it imposes 
additional attack surface - we all know that.
Besides exploits those tools might cause additional threat (e.G. 
RDP- VNC-, SSH-Clients)

So you better do not install non-universal software* in a template VM.
*software that is not needed in every VM which is based on that 
template


So where to put non-universal software?

- user-space: allows malware to persist easily, because of 
persistent write rights. And does not allow usage of standard 
repositories
- other (cloned) TemplateVM: You need to make sure that you keep all 
templates up-to-date for security reasons, you need much more 
storage space and cause more ssd aging




Interesting!!

Since r2.x, I've run each of my user apps in individual, dedicated, 
dynamically-configured DispVMs; using scripts that: start up a new 
DispVM, copies the application-specific files from the vault into the 
DispVM; runs the application, copies any updated data (data only) 
back from the DVM to the folder in the vault; discards the DVM. Of 
course the vault remains offline, and programs are never invoked 
within the vault; it is used exclusively to store data that is 
accessed safely in dispvms.


If a DVM becomes compromised or corrupted I simply dispose of the 
DispVM and start anew. No worries about quiet infections of appvm 
user files, as only updated data (in most cases txt files) is 
retained from the DispVM back to the vault.


After your OP, it dawns on me that one could devise similar scripts 
to start up a "barebones" DVM, dynamically modify it to be a 
dedicated application DVM by copying both the application files AND 
the necessary system (app) files into that DVM. Run the app; copy any 
updated data (data only) back into the vault, and discard the DVM. 
(This is trivial with some apps; e.g. keepassx; but could be involved 
with big complicated apps)


This would keep the DispVMs smaller, and as you point out, with fewer 
attack surfaces.


This would require two AppVMs: a "barebones" DVM (As per Rudd-O's 
"minimal" point, I'll likely use the Qubes default with Firefox 
system and FF "user" files installed), and a second AppVM containing 
and maintaining the system and user application files - it would be 
brought online only for the purpose of package manager updating.


I plan on testing/configuring this way with r4.x.  Thank You for the OP.


Interesting idea. However I would not use the "move to VM" command 
like this, as I experienced those requests getting lost One time files 
were actually deleted, since that time I always use copy instead of move.
This is a problem with Linux (package based setup, dependency hell) - 
in Windows you can run most Tools from their folder which you can 
place anywhere you like. They may create files in other places (like 
the registry), but they mostly run on a system they are copied to.


Depending on how you copy malware still might be able to persist. I 
think about a browser extension, for example.


Robert




Dang! Right you are - I miss-wrote! I do indeed copy; e.g.:

qvm-run -q --pass-io vault 'tar -c -f - keepass' | qvm-run --pass-io $x 
'tar -x -f -'


(where $x is the newly-created DispVM.)

So  I'll add an additional, similar command that would copy the system 
executable (e.g. keepassx) to the DVM, and instead of executing an 
installed app - which I do now:


qvm-run -q $x 'keepassx /home/user/keepass/keepass.kdb' &

I'd start executing a recently-copied app; e.g. something like (./ may 
not be needed):


qvm-run -q $x './home/user/keepass/keepassx 
/home/user/keepass/keepass.kdb' &


Don't know how much this will save me, as I don't have a lot of "stuff" 
installed, but it should reduce DVM size and attack surface(at the 
acceptable cost of dynamically creating DVMs before executions).




In terms of browser extensions, I think they *ARE* an issue, and I 
routinely copy only places.sqlite back to the vault; the rest of the DVM 
is discarded.


IF I do want to update extensions, then I'll start the FF DVM, update 
extensions, ublock, etc.; copy the whole shebang back to the vault; and 
then shutdown - without exposing FF to anything else.






--
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/eb54e356-fb48-a64c-e6dc-dd8d0146841b%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Thoughts about installed software

[7v5w7go9ub0o]

On 10/11/2016 09:30 AM, Robert Mittendorf wrote:
Software that you don't need is a security risk as it imposes 
additional attack surface - we all know that.
Besides exploits those tools might cause additional threat (e.G. RDP- 
VNC-, SSH-Clients)

So you better do not install non-universal software* in a template VM.
*software that is not needed in every VM which is based on that template

So where to put non-universal software?

- user-space: allows malware to persist easily, because of persistent 
write rights. And does not allow usage of standard repositories
- other (cloned) TemplateVM: You need to make sure that you keep all 
templates up-to-date for security reasons, you need much more storage 
space and cause more ssd aging




Interesting!!

Since r2.x, I've run each of my user apps in individual, dedicated, 
dynamically-configured DispVMs; using scripts that: start up a new 
DispVM, copies the application-specific files from the vault into the 
DispVM; runs the application, copies any updated data (data only) back 
from the DVM to the folder in the vault; discards the DVM. Of course the 
vault remains offline, and programs are never invoked within the vault; 
it is used exclusively to store data that is accessed safely in dispvms.


If a DVM becomes compromised or corrupted I simply dispose of the DispVM 
and start anew. No worries about quiet infections of appvm user files, 
as only updated data (in most cases txt files) is retained from the 
DispVM back to the vault.


After your OP, it dawns on me that one could devise similar scripts to 
start up a "barebones" DVM, dynamically modify it to be a dedicated 
application DVM by copying both the application files AND the necessary 
system (app) files into that DVM. Run the app; copy any updated data 
(data only) back into the vault, and discard the DVM. (This is trivial 
with some apps; e.g. keepassx; but could be involved with big 
complicated apps)


This would keep the DispVMs smaller, and as you point out, with fewer 
attack surfaces.


This would require two AppVMs: a "barebones" DVM (As per Rudd-O's 
"minimal" point, I'll likely use the Qubes default with Firefox system 
and FF "user" files installed), and a second AppVM containing and 
maintaining the system and user application files - it would be brought 
online only for the purpose of package manager updating.


I plan on testing/configuring this way with r4.x.  Thank You for the OP.






--
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/84df6c4b-4849-a3ae-fa55-8bd62c79f7c4%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL - Lenovo Thinkpad x260

[7v5w7go9ub0o]

On 08/27/2016 08:09 PM, B, Pat wrote:

Following the Recipe

https://www.qubes-os.org/doc/uefi-troubleshooting/
Note:  The recipe isn't quite correct, it says to hit 'e' from GRUB menu.
The 'e' option is only available after you select
1. Troubleshoot
2. Boot from device


Was able to install and run.

Suspend/Resume is fixed since R3.1
Graphics glitches from R3.1 on gone



Thank you for posting this.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9e891d1e-1257-8b0c-2d47-14204e2e7f64%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Risks of Dual-Boot?

[7v5w7go9ub0o]

On 07/30/2016 09:24 PM, Markus Kilås wrote:
> On 07/30/2016 06:25 PM, Fabian Wloch wrote:
>> didn't found anything
> The issues with unprotected /boot and BIOS is briefly mentioned on the
> below link and it sounds like AEM should be able to at least be able to
> detect a compromise for you:
>
> https://www.qubes-os.org/doc/multiboot/

Yes; but what about infected firmware other than the BIOS?

e.g. USB controllers?

e.g. Storage firmware?




-- 
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/579d2987.962cc80a.a14ea.8468%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

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

[7v5w7go9ub0o]

On 07/27/2016 03:01 AM, Chris Laprise wrote:

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 



... and if also supported by the MB and BIOS.




--
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/3b0e1a92-cf5e-a904-86f2-d632084ea20f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Question on DMA attacks

[7v5w7go9ub0o]

On 07/15/2016 08:46 AM, Marek Marczykowski-GĂłrecki wrote:
>
> On Thu, Jul 14, 2016 at 07:22:28PM -0700, neilhard...@gmail.com wrote:
>>  From the user FAQ:
>>
>> https://www.qubes-os.org/doc/user-faq/#can-i-install-qubes-on-a-system-without-vt-d
>>
>> "an attacker could always use a simple DMA attack to go from the NetVM to 
>> Dom0"
>>
>> So what does this mean though..?
>>
>> Can they launch this DMA attack from a compromised App VM..?
>>
>> Could they simply do a browser exploit in an App VM, and then do a DMA 
>> attack from there to go to dom0..?
>>
>> Or is it a lot harder than that..?
>>
>> I'm just trying to work out whether it's really worth buying a new laptop 
>> just to get VT-D I currently have VT-X, but not VT-D.
> DMA is mechanism for PCI devices to access system memory (read/write).
> Without VT-d any PCI device can access all the memory, regardless to
> which VM is assigned (or left in dom0). Most PCI devices allow driver to
> request arbitrary DMA operation (like "put received network packets at
> this address in memory", or "get this memory area and sent to the
> network"). So, without VT-d, it gives unlimited access to the whole
> system. Now, it is only a matter of knowing where to read/write to take
> over the system, instead of just crashing. But since you can read the
> whole memory, it isn't that hard.
>
> Now, how it applies to Qubes OS? The above attack requires access to PCI
> device. Which means that can be performed only from NetVM / UsbVM, so
> someone must first break into one of those VMs. But it isn't that hard,
> because there is a lot of complex code handling network traffic. Recent
> bugs includes DHCP client, DNS client etc. Most of attacks on NetVM /
> UsbVM (but not all!) requires being somehow close to the target system -
> for example connected to the same WiFi network, or in case of UsbVM,
> having physical acccess to some USB port.
>
> But, just exploiting a browser in an AppVM isn't enough, as normal AppVM
> do not have any PCI device assigned (unless you do that manually).
>

Thank you for this overview!

I'm still on R2.1, as VT-d on 3.x seems to fail on my Lenovo box. (BTW, 
Lenovo has indicated that BIOS updates are forthcoming).

I'm presuming that VT-d is important enough (I occasionally use open 
hotspots) that I'm best off keeping it and  2.1, foregoing any Qubes/XEN 
updates to 3.x (I'm keeping application software up to date outside of YUM).

So the question becomes, is my reasoning valid?

Are there any 2.1 issues that indicate I should upgrade to 3.x without VT-d?

Thanks in Advance



-- 
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/5788e847.0435c80a.b917c.367b%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Unable to install 3.2-rc1 on Thinkpad T450s

[7v5w7go9ub0o]

On 06/27/2016 09:32 AM, Jeremy Rand wrote:
>
> I don't know if this is your issue, but the instructions are a bit
> ambiguous.  I initially tried adding those params to the end of the
> "kernel" lines, but they had no effect.  You actually need to add the
> params on 2 separate new lines (1 line per param), at the end of each
> section that includes a kernel line.  (I.e. all sections except the
> first one, because it doesn't have a kernel line.)
>
> @Andrew David Wong, any chance those instructions could be made a
> little bit more clear?  I'm totally okay with the fact that I lost a
> few hours debugging this (I'm using a release candidate, after all),
> but I imagine some users might find this frustrating.
>
> Cheers,
> - -Jeremy Rand
>


Thank You both from here (T440P); there is again hope.


-- 
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/577122a2.7028c80a.1929d.d7a8%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Is there a standard procedure to reinstall whonix?

[7v5w7go9ub0o]

On 06/06/2016 10:34 AM, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2016-06-05 23:18, Achim Patzner wrote:
>> Hi!
>>
>>
>> As I've never taken a look at the entire whonix sub-systemI'm a
>> bit clueless myself...
>>
>>
>> Someone who has so completely mesed up his whonix-ws and -gw
>> templates that sys-whonix is not connecting to tor anymore probably
>> needs to set it up anew. Is there a standard way of removing all
>> VMs and downloading clean templates without reinstalling qubes? Or
>> is there a better way to get the templates and then sys-whonix to
>> their original states?
>>
>>
>>
>> Achim
>>
> 1. (Optional) Clone your existing whonix-gw and whonix-ws templates.
>
> 2. Temporarily change all VMs based on whonix-gw and whonix-ws to
> another template (e.g., the ones created in the previous step).
>
> 3. Uninstall the Whonix templates from dom0:
>
> $ sudo yum remove qubes-template-whonix-gw
> $ sudo yum remove qubes-template-whonix-ws
>
> 4. Reinstall the Whonix templates in dom0:
>
> $ sudo qubes-dom0-update --enablerepo=qubes-templates-community \
>   qubes-template-whonix-gw qubes-template-whonix-ws
>
> 5. Change the VMs from step 2 back to (the new) whonix-gw and whonix-ws.
>

Nice, clear response!

-- 
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/575567bf.4286370a.9beba.907f%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.