Re: [qubes-users] https://www.qubes-os.org/doc/vpn/

2017-05-22 Thread Jean-Philippe Ouellet
On Sat, May 20, 2017 at 1:36 PM, fooyreb  wrote:
> Helo,  So, I've setup a proxyVM for the VPN, via the "CLI version"
> https://www.qubes-os.org/doc/vpn/
>
> However, when I suspend Qubes, and wakeup Qubes, the networking is lost,
> I then have to shut down or alter the network choice for 2-3 AppVMs that
> use it and restart the ProxyVM, I'd rather not do this.
>
> Is there some argument or tweak to change this type behaviour, or is
> this by design, that this happens?   for my "security"  :)
>
> I'd include the log, if I knew where to find the right one .
>
> sorry if this isn't too qube-y of a question, maybe it is 

Maybe you want some kind of auto-reconnect or reconnect triggered on
suspend/resume [1]?

[1]: https://wiki.archlinux.org/index.php/Power_management#Sleep_hooks

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


Re: [qubes-users] Debian 9 and Fedora 24 Should I be upgrading to these?

2017-05-22 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-23 00:01, yreb-qusw wrote:
> On 05/22/2017 05:56 PM, Andrew David Wong wrote:
>> You might want to check that it's really a Fedora 24 template
>> (and not still Fedora 23).
> 
> sorry Andrew, I'm no clue-by, you know, unless it's spelled out
> in a tutorial , I usually am gonna have to ask
> 
> re: how do I know which version the template is?   how would I know
> 
> 

Try:

$ cat /etc/redhat-release

How did you upgrade the TemplateVM from Fedora 23 to Fedora 24? Did
you follow this guide?

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

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

iQIcBAEBCgAGBQJZI8j7AAoJENtN07w5UDAwMekQAJexmNcsLs33cbUWQfjUaVjR
sRM3sHHsTVHsi3ldVZvUNtY+H7YVCyotaOAisbHFjdAHEM1qRCBN+WxMOLZKvDyb
jPBEHa2OSqhp3KhVn/JayTBNSiH0TYfDg0R1WXxk6AbAxbDPyc92H38yE6ni62e3
IdiurPhMc0+/pfhU1GtpWBaAb5rJZQj9ituPqtQKNtF3EyFxkj6TaPJtbDjKEAjV
CY1qxkPbmYnD0w8KXcHAaJfwe6SIWA897pStdWa3WmF2lJ6bir9+D99o6FyojQ1C
aT++juIYpfQjEFoa3J8scN2e8fbii1jGhfrALJMuQULN6GSqn3BVj/NhWtS01m4K
XtZ1ojexOsFz7XkcWbZSQhSPYQUAl2XxCEf6VC8yCimNC5ji9lfBODsCHAHhxMI4
mlMyfEw4gQ4E11yIlYcDkCpUvl72BM4K8U/nJLitFGi2hnyp34PO3XseAshbZLiW
CAITpGhkNS86T5PVWpjy77jQGX6XCVNS45M6mVzTKUl7raYAQQwKGnlvPOAUstZw
ixFFPUROEnMDfwZ5/mxysDHxJyJBY8sHnDvlujIDw8nhQPbBy3Xer8pNat0J37lg
qhHYah+NDVxk56bkoHobPw6uSCBza5gElUuAPei2RZmgBR43Jap/PwjfjJLuglza
WblQoQ/YhxXX6O7Io/sU
=JJwQ
-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/21176d49-beea-ce6e-f4e0-e3491782253d%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to check integrity about DVD

2017-05-22 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-22 23:13, Jean-Philippe Ouellet wrote:
> On Tue, May 16, 2017 at 9:41 PM, Andrew David Wong  wrote:
>> On 2017-05-16 16:42, h...@e.shapoo.ch wrote:
>>> I verified signature about qubes ISO file by gpg.Then I burned it to DVD.
>>> But I can't trust that DVD was burned without corruption.
>>> So I want to verify integrity against the DVD too.
>>>
>>> Is someone know how to verify signature against DVD?
>>>
>>>
>>> At moment, I want my privacy to be protected.
>>> https://mytemp.email/
>>>
>>
>> I'm not aware of a method to gpg --verify an ISO directly from a DVD
>> after it has been burned, but you can re-create the ISO from the DVD,
>> [1] then gpg --verify the re-created ISO. [2]
>>
>>
>> [1] 
>> https://www.thomas-krenn.com/en/wiki/Create_an_ISO_Image_from_a_source_CD_or_DVD_under_Linux
>>
>> [2] If you're worried that the re-created ISO might not truly represent
>> what's on the DVD because you're worried that your software environment
>> might be compromised and lying to you, then I'd point out that the same
>> compromised software environment could also lie to you about the results
>> of verifying the DVD directly.
> 
> IIRC it is legal and works as expected to pass a block device as the
> file to be verified with gpg, e.g.
> $ gpg --verify Qubes-R3.2-x86_64.iso.asc /dev/sr0
> 

I could never get it to work for some reason.

> However, I know I have just done:
> $ sudo cat /dev/sr0 | sha256sum -
> and compared against a known-good hash.
> or
> $ sudo head -c $((1024*1024*4)) /dev/sr0 | sha256sum -
> in the case of larger devices (like flash drives) which do not report
> a certain size (like burned DVDs), and then verified that the rest of
> the media is zeroes (dd skip=...) because I'm paranoid like that and
> don't know what might read past the end of intentionally written data
> and what parsers it might reach.
> 
> I'm happy to be corrected, but I do not see the need for re-creating
> an ISO on your disk unless you find your DVD to be wrong and want to
> do some forensics.
> 

I mean, either way you're reading the contents of the disc. It's just a
matter of whether you write them (back) to the disk or pipe them
directly to whichever program is doing the verification, right? I don't
see any meaningful security gain from piping directly, since a
compromised environment could still be lying to you. Since I make lots
of mistakes, though, I'd probably prefer to have it on the disk so that
I don't have to re-read the whole disc when I inevitably screw up the
verification step the first time. :)

> Non-write-once media, or media with embedded computing capability and
> persistent and mutable state (like flash drives) have other concerns
> however.\
> 
> Cheers,
> Jean-Philippe
> 


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

iQIcBAEBCgAGBQJZI8giAAoJENtN07w5UDAwpugP/RNrf1MQD34UhqENsuvbLcJx
uI+MGYXcQLHLwdi42VdWnwQmwX6gcUISp3O58yFAcT7wRUL/5ZfatrtKyFiPlDAZ
3Y/EVXsvlnLMOuqkoKOpzIMH9vM8HjmBDr12PW2wsy2bKxHetkoKMWbkOZXNEjhk
uldVde04/oX1U4aCgRLfICeYoGd66cgM+93IKTnRKf6p1gF8zAzx41NX6jskWYPx
9Q1cvm64ruAGuYNMobWJDyjQV7kni1iS35Y8ll1h4BAcUDDGoG1tM7239hW3KDPR
PF7SBGZPn9XTzb2GqsphZOYeRNVE8C5JN6Ld8slfW1xhI9WYNo7IvddSYvlQfhdc
0pxXkG8WutknUZVXoKbtnl9Y4uIgpXPFQQHuPH2FOjN/C8T8v2vgFg5p6g5N8uls
4zbm+/TGh9I7Hb/2vILR5uR/uEx04P0l0dp2wHJF4Zkc4/MBM4XIRhk7HnlDAyLW
pJhRRmLzLLUoiFq08kApp3NyMH/DImC4FyNLqvqWsaoddf4b/5lf64M6RATIkr/x
1zipb0k54/+T62IQLgPq24MdIFJk8p8XpMpn0nRhEOSRkmZfqOrN7NfNyeRGQVbt
JU6TsoYcZW+Q5syBNCN22xbr0aJSfvw9+ccBisPKIV6heaEMsU85gJCZat6HTREI
JMLhZEoUnrTxYXr3ieuI
=nHiv
-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/cc3da9ba-160c-7039-c56e-ea8bdb0b5ab5%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-22 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-22 23:49, Jean-Philippe Ouellet wrote:
> On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong  wrote:
>> On 2017-05-14 03:51, Holger Levsen wrote:
>>> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
> you really dont protect your gpg key with a passphrase??
 See: https://www.qubes-os.org/doc/split-gpg/
>>>
>>> oh wow :(
>>>
 Why is that a problem? It's only visible in dom0. If an attacker is in
 dom0, it's already game over.
>>>
>>> no, the world is not black and white.
>>>
>>> If an attacker steals your computer while it's unlocked, all your gpg
>>> encrypted stuff is wide open.
>>>
>>> If an attacker steals my computer while it's unlocked, my gpg encrypted
>>> stuff is still locked. Surely the attacker can now install as many 
>>> backdoors as
>>> they want, but as long as I don't type my gpg passphrase into that computer
>>> anymore, it should be pretty safe.
>>>
>>
>> You're conflating two distinct problems:
>>
>> (1) Passphrases I've typed in dom0 are available in cleartext in
>> dom0.
>> (2) Data-at-rest is not encrypted while Qubes is booted and the screen
>> is unlocked.
>>
>> We could solve (1) without solving (2). If we did that, it would solve
>> the `ps` + qvm-backup problem (the first problem you mentioned), since
>> my backup would be encrypted, and the thief wouldn't have access to the
>> backup decryption passphrase.
>>
>> (2) is the second problem you mentioned. Solving (2) is distinct from
>> solving (1), but in order for the solution to (2) to be satisfactory, we
>> also have to solve (1) (or make sure no similar problem arises for
>> per-VM encryption), since otherwise my data-at-rest passphrase could be
>> obtained via (1).
>>
>> I think the right approach to (2) in Qubes is per-VM encryption [1]
>> (probably with LUKS instead of GPG, and certainly not relying on public
>> key crypto, though hopefully we're all already in agreement on the
>> latter point). If I'm in an untrusted physical environment, I should be
>> able to work with less sensitive VMs without decrypting sensitive VMs,
>> and if someone steals my unlocked laptop, they shouldn't be able to gain
>> access to the encrypted sensitive VMs. That's the goal, anyway.
>>
>>
>> [1] https://github.com/QubesOS/qubes-issues/issues/1293
> 
> Solving 1 is not a simple matter of patching some things to pass
> passwords on stdin instead of argv or env vars, it would still be a
> mostly trivial matter for an attacker to just make a core dump and run
> strings on it. Rather, I believe a proper solution to 1 would require
> that dom0 to some degree distrust whoever is physically at the
> keyboard. A "kiosking" of Qubes, if you will.
> 
> Also, I do not agree on your assessment about symmetric crypto being
> obviously the way to go. I think there is value in being able to
> initiate a backup from inside a hostile environment (think: someplace
> with cameras everywhere watching any passphrase you would enter),
> which would make sense to implement by encrypting to an asymmetric
> keypair for which the private half is only in a separate physical
> environment. (Sure, yes, use a symmetric algo for the bulk encryption
> and just encrypt that with the asymetric algo... not my point.) You
> would not be able to decrypt your own backups until you had regained
> access to the private half, but you would be able to start backups
> without needing to divulge your backup secret at the same time. In
> this scheme you would also have another keypair with the secret part
> on your laptop in order to sign the backup (authenticating it with an
> asymmetric signature without requiring a passphrase at backup-creation
> time). I've made this argument before, but perhaps never presented it
> well enough. Expect a PoC in the hopefully not-too-distant future.
> 

Encrypting a backup to a public key, where the private key is not and
never has been accessible to the machine creating the backup? You have
to admit that's a pretty remote edge case for Qubes, which is supposed
to be a trusted single-user system.

I'm not denying such edge cases exist, but it should be obvious that
statements like, "You should use symmetric crypto for your backups" are
not meant to apply in such remote edge cases. Rather, they're meant to
apply in the vast majority of cases in which they make sense. If we
tried to qualify every statement to make it perfectly accurate across
all domains of possibility, we'd never be able to say anything.

(By the way, just because a camera's watching everything you type
doesn't necessarily mean you have to use asymmetric crypto. You could
use, e.g., a preshared keyfile instead.)

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

iQIcBAEBCgAGBQJZI8aTAAoJENtN07w5UDAwwgoQALjoWMYgAMey/q1vrEwKnYse
xJ1hpSTiq1VpmQJ3AcPZTwUEXQ80JQs2jKn+8r/LyayxvyUoo5v83mJZ/3/R7UV3

Re: [qubes-users] ANN: qubes-pass — an inter-VM password manager and store for Qubes OS

2017-05-22 Thread Jean-Philippe Ouellet
On Sun, May 14, 2017 at 4:20 PM, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 2017-05-14 03:51, Holger Levsen wrote:
>> On Sat, May 13, 2017 at 02:55:12PM -0500, Andrew David Wong wrote:
 you really dont protect your gpg key with a passphrase??
>>> See: https://www.qubes-os.org/doc/split-gpg/
>>
>> oh wow :(
>>
>>> Why is that a problem? It's only visible in dom0. If an attacker is in
>>> dom0, it's already game over.
>>
>> no, the world is not black and white.
>>
>> If an attacker steals your computer while it's unlocked, all your gpg
>> encrypted stuff is wide open.
>>
>> If an attacker steals my computer while it's unlocked, my gpg encrypted
>> stuff is still locked. Surely the attacker can now install as many backdoors 
>> as
>> they want, but as long as I don't type my gpg passphrase into that computer
>> anymore, it should be pretty safe.
>>
>
> You're conflating two distinct problems:
>
> (1) Passphrases I've typed in dom0 are available in cleartext in
> dom0.
> (2) Data-at-rest is not encrypted while Qubes is booted and the screen
> is unlocked.
>
> We could solve (1) without solving (2). If we did that, it would solve
> the `ps` + qvm-backup problem (the first problem you mentioned), since
> my backup would be encrypted, and the thief wouldn't have access to the
> backup decryption passphrase.
>
> (2) is the second problem you mentioned. Solving (2) is distinct from
> solving (1), but in order for the solution to (2) to be satisfactory, we
> also have to solve (1) (or make sure no similar problem arises for
> per-VM encryption), since otherwise my data-at-rest passphrase could be
> obtained via (1).
>
> I think the right approach to (2) in Qubes is per-VM encryption [1]
> (probably with LUKS instead of GPG, and certainly not relying on public
> key crypto, though hopefully we're all already in agreement on the
> latter point). If I'm in an untrusted physical environment, I should be
> able to work with less sensitive VMs without decrypting sensitive VMs,
> and if someone steals my unlocked laptop, they shouldn't be able to gain
> access to the encrypted sensitive VMs. That's the goal, anyway.
>
>
> [1] https://github.com/QubesOS/qubes-issues/issues/1293

Solving 1 is not a simple matter of patching some things to pass
passwords on stdin instead of argv or env vars, it would still be a
mostly trivial matter for an attacker to just make a core dump and run
strings on it. Rather, I believe a proper solution to 1 would require
that dom0 to some degree distrust whoever is physically at the
keyboard. A "kiosking" of Qubes, if you will.

Also, I do not agree on your assessment about symmetric crypto being
obviously the way to go. I think there is value in being able to
initiate a backup from inside a hostile environment (think: someplace
with cameras everywhere watching any passphrase you would enter),
which would make sense to implement by encrypting to an asymmetric
keypair for which the private half is only in a separate physical
environment. (Sure, yes, use a symmetric algo for the bulk encryption
and just encrypt that with the asymetric algo... not my point.) You
would not be able to decrypt your own backups until you had regained
access to the private half, but you would be able to start backups
without needing to divulge your backup secret at the same time. In
this scheme you would also have another keypair with the secret part
on your laptop in order to sign the backup (authenticating it with an
asymmetric signature without requiring a passphrase at backup-creation
time). I've made this argument before, but perhaps never presented it
well enough. Expect a PoC in the hopefully not-too-distant future.

Regards,
Jean-Philippe

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


[qubes-users] Re: internet connection not working

2017-05-22 Thread aforete


aforete:
> My internet connection is not working, except in whonix. This seems
> similar to the issue referenced in the faq:
> https://www.qubes-os.org/doc/user-faq/#my-qubes-lost-internet-access-after-a-templatevm-update-what-should-i-do
> But the proposed fix does not work.
> I reinstalled qubes, but I still can't open any websites (and the answer
> in the faq doesn't work after reinstallation).
> 
Well, the problem went away on its own, I don't know why. In the couple
of days while I had problems, I was able to update dom0 and the
templates, and also use internet in other appvm, by making a whonix-gw
vm the netvm and likewise changing the update vm in the global settings.
I'm quite relieved if a bit puzzled.

-- 
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/5d060365-7e2f-351d-3c5d-5c9880342aed%40cock.li.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] how to check integrity about DVD

2017-05-22 Thread Jean-Philippe Ouellet
On Tue, May 16, 2017 at 9:41 PM, Andrew David Wong  wrote:
> On 2017-05-16 16:42, h...@e.shapoo.ch wrote:
>> I verified signature about qubes ISO file by gpg.Then I burned it to DVD.
>> But I can't trust that DVD was burned without corruption.
>> So I want to verify integrity against the DVD too.
>>
>> Is someone know how to verify signature against DVD?
>>
>>
>> At moment, I want my privacy to be protected.
>> https://mytemp.email/
>>
>
> I'm not aware of a method to gpg --verify an ISO directly from a DVD
> after it has been burned, but you can re-create the ISO from the DVD,
> [1] then gpg --verify the re-created ISO. [2]
>
>
> [1] 
> https://www.thomas-krenn.com/en/wiki/Create_an_ISO_Image_from_a_source_CD_or_DVD_under_Linux
>
> [2] If you're worried that the re-created ISO might not truly represent
> what's on the DVD because you're worried that your software environment
> might be compromised and lying to you, then I'd point out that the same
> compromised software environment could also lie to you about the results
> of verifying the DVD directly.

IIRC it is legal and works as expected to pass a block device as the
file to be verified with gpg, e.g.
$ gpg --verify Qubes-R3.2-x86_64.iso.asc /dev/sr0

However, I know I have just done:
$ sudo cat /dev/sr0 | sha256sum -
and compared against a known-good hash.
or
$ sudo head -c $((1024*1024*4)) /dev/sr0 | sha256sum -
in the case of larger devices (like flash drives) which do not report
a certain size (like burned DVDs), and then verified that the rest of
the media is zeroes (dd skip=...) because I'm paranoid like that and
don't know what might read past the end of intentionally written data
and what parsers it might reach.

I'm happy to be corrected, but I do not see the need for re-creating
an ISO on your disk unless you find your DVD to be wrong and want to
do some forensics.

Non-write-once media, or media with embedded computing capability and
persistent and mutable state (like flash drives) have other concerns
however.\

Cheers,
Jean-Philippe

-- 
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/CABQWM_AjWCoQG5-XtTMJb%3DuCkwN2o-tJJZMoThFgjyG%2BmXx4tA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Debian 9 and Fedora 24 Should I be upgrading to these?

2017-05-22 Thread Andrew David Wong
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-05-22 19:47, fooyreb wrote:
> well the mac complaint just auto disappeared, however now in a terminal
> in fedora 24 template , I am getting references to fedora 23  , is this
> correct ?
> 
> Or do I need to do whatever the version for fedora is of  apt-get update
> or dist-upgrade?
> 
> 
> [user@fedora-24 ~]$ sudo dnf install chromium
> Qubes OS Repository for VM (updates)171 kB/s | 473 kB
> 00:02
> Fedora 23 - x86_64  2.6 MB/s |  43 MB
> 00:16
> Fedora 23 - x86_64 - Updates3.1 MB/s |  25 MB
> 00:08
> Last metadata expiration check: 0:00:08 ago on Mon May 22 14:40:27 2017.
> Dependencies resolved.
> 
>  Package Arch   Version   Repository
>   Size
> 
> Installing:
>  chromiumx86_64 54.0.2840.90-3.fc23   updates
>   31 M
>  chromium-libs   x86_64 54.0.2840.90-3.fc23   updates
>   41 M
>  chromium-libs-media x86_64 54.0.2840.90-3.fc23   updates
>  1.4 M
>  libXScrnSaver   x86_64 1.2.2-9.fc23  fedora
>   28 k
>  u2f-hidraw-policy   x86_64 1.0.2-1.fc23  updates
>   22 k
> 
> 
> I said "no"  for now, not wanting to break anything  I do still have
> the old Fedora 23  template VM, just in case, but I'm doubting that
> matters ??
> 
> cc: qubes-group,  ADW
> 

You might want to check that it's really a Fedora 24 template (and not
still Fedora 23).

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

iQIcBAEBCgAGBQJZI7LdAAoJENtN07w5UDAw1agQAMhmsNFp72jCPwYfkJTqNU/r
+KcFDA6RUGJax8oWm+Sm0065NeS+xTiG2mqDYpnt3jjSKR4I+ogiuax1zOq64Sj6
EgKxdrKKrNvicuSEqXYh/HWBUdnAMYxW3SqKsyRWiPBM6HTaTjg+7OVY37AacW93
ga615nrNUR12p7mQsuiDUP7keuwt7cpHnYpSRd1LjSdiHl1xsfa0gcbHUUYiChFT
Lhz9abRgWqWl6x+5BK7T1ix886oi/GsL/Yx3kPcIyfX60CgzPLjvtnoe2MjYseM+
sk0kFhgHhNwf7UEPW2GsY/jwbT+kO+Bfw+nuyHk+5pmMP2CYyzSENQaEZeAmNDwD
jPvUBk8HUUI8QtDAVokOCGAZH0CO+KRen6p+Xj6FgJNJnz4Z6hKyX8DV98AJitfw
IVKDYdP2JqZ3UxuJIH8+7DYjQLpHInwjrfRTj9KKJOLqyd9pmhf2gAmNjudaiDuN
1lKaDdO220CP92aHcHI1rgyo+S/asfImZjPCOL8zQzvtMV/SHr3wP4Azqnqqj5Ce
J5u7XbX6oDXYUNJTrVqabwoysYnQn9/ZAanJgjerpvgGEiA+cp4M4rW0bgDBrE1f
/t1ZirTXxxzm4a7LIIEDSL7UoH4ISt2LXhHg3ClNc530RdzI+UF32fpKN+y4GSl+
e55Ufs9YU8M8TsOYEgKe
=Hq1t
-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/46a0b40b-c5af-3121-991b-801c05aa8a04%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Games on Qubes + Whonix

2017-05-22 Thread Jean-Philippe Ouellet
On Mon, May 15, 2017 at 9:40 AM,   wrote:
> Hello! I'm a beginner and maybe ask a stupid question. I know that Qubes OS 
> itself does not support 3D graphics. But can I play games (Steam) if I 
> connect to Qubes Whonix as a virtual machine? It's a Linux distribution and 
> it itself supports Steam. Here it is about Qubes + Whonix: 
> https://www.whonix.org/wiki/Qubes.
> Thank you!

Steam itself works no problem (I've used it in a StandaloneVM). Games
are hit and miss.

Software rendering performance seemed high enough for most 2d games
and even some old / non-demanding 3d games (ancient Unreal games were
"playable"). Really can't say I've spent a lot of time playing them
though, it was more an afternoon project of "Hmm... I wonder if this
works..." than anything else. I'm not a gamer, and my tolerance for
poor gaming performance is quite likely higher than most.

Input grabbing is indeed an issue though as Vit points out.

I should mention this was all on linux, with Windows-only things run
in Wine. I never personally tried on windows HVMs, but they seem
somewhat sluggish even for basic non-game tasks so I'd imagine it
wouldn't be great unless you passed through a dedicated GPU and USB
controller with separate input devices or something.

Cheers,
Jean-Philippe

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


Re: [qubes-users] Windows 7 HVM Install

2017-05-22 Thread Jean-Philippe Ouellet
On Mon, May 15, 2017 at 5:24 PM, Sam Hentschel  wrote:
> Hey all!
>
> Decided to try out making a windows 7 install just in case I needed it
> for school.
>
> I downloaded a 64-bit windows 7 enterprise iso and proceeded with the
> installation doing:
>
> $ qvm-create win7 --hvm --label green  #as in the qubes-docs
> $ cp /var/lib/qubes/appvms/win7/win7.conf ~/ # to change xen to 
> cirrus for graphics
> $ qvm-start --cdrom:dispXX:/home/user/Downloads/win7_sp1_64.iso
> --custom-config=win7.conf
>
> The first install went fine, I got it to boot up the first time and
> tried to load the windows tools:
>
> $ sudo qubes-dom0-update qubes-windows-tools
> $ qvm-start --custom-config=win7.conf --install-windows-tools
>
> However, something messed up and it wouldn't get passed the start up
> screen after that (I don't think it actually installed the windows tools
> as I didn't see the disk show up).  I tried using all the combinations
> of commands I had for qvm-start before I gave up.  I deleted it using
> qvm-remove and retried to make the windows 7 hvm.
>
> I followed the same steps above; however, when I got to the first
> qvm-start I get the following:
>
> --> Loading the VM (type = HVM)...
> Traceback (most recent call last):
>   File "/usr/bin/qvm-start", line 136, in 
> main()
>   File "/usr/bin/qvm-start", line 120, in main
> xid = vm.start(verbose=options.verbose, 
> preparing_dvm=options.preparing_dvm, start_guid=not options.noguid, 
> notify_function=tray_notify_generic if options.tray else None)
>   File 
> "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line 335, 
> in start
> return super(QubesHVm, self).start(*args, **kwargs)
>   File 
> "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1952, 
> in start
> self._update_libvirt_domain()
>   File 
> "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 764, 
> in _update_libvirt_domain
> raise e
> libvirt.libvirtError: operation failed: domain 'win7' already exists 
> with uuid 27a11689-a44e-4442-b11a-112b2728c511
>
> If I run the command without the --custom-config option it starts, and
> hangs at startup as usual; so I'm guessing its a problem with my config?

I've seen this happen when qubes-manager / libvirt / xen get out of
sync. "Simplest" fix is to reboot.

Otherwise, I'd do in dom0:
$ killall qubes-manager # or right-click the tray icon -> Exit
$ xl list # check for win7 vm
$ ls /var/lib/qubes/appvms # check for win7 dir
$ grep win7 /var/lib/qubes/qubes.xml # should produce no results
$ sudo systemctl restart libvirtd # this is what really matters
and re-launch qubes-manager from the Q menu

It's a bug, but I haven't found time to look into it. If you know how
to reproduce reliably, definitely open an issue.

Cheers,
Jean-Philippe

-- 
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/CABQWM_AZ-a8OHc9-8YdY_9DTavB27zB%3DXNXoLDqQiYy-6ChFLw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Help adding documentation to Qubes Repository

2017-05-22 Thread Jean-Philippe Ouellet
On Sat, May 13, 2017 at 4:22 PM, Andrew David Wong  wrote:
> On 2017-05-13 14:27, Zbigniew Łukasiak wrote:
>> This is something I am also struggling with - but shouldn't there
>> be a sign-off line in all the commit comments as described in
>> https://www.qubes-os.org/doc/license/ ?
>
> No, that only applies to Qubes OS code.

Except in practice it doesn't apply there either. See comments in #2517 [1].

[1]: https://github.com/QubesOS/qubes-issues/issues/2517#issuecomment-266658039

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


Re: [qubes-users] Why should I clone a template?

2017-05-22 Thread Jean-Philippe Ouellet
On Sat, May 20, 2017 at 8:43 PM, Todd Lasman  wrote:
> The dogma, as I understand it, is that it's safer to clone a template, make
> changes to the clone, then base your AppVM's off of that cloned template.
>
> - From the Qubes website:
> "It is highly recommended to clone the original template, and make any
> changes in the clone instead of the original template. The following command
> clones the template. Replace your-new-clone with your desired name..."
>
> My question is, why? It seems to me that if you ever needed the original
> template back, you could just download it again from the repository. Am I
> missing something?

Two reasons personally:

1) If you find yourself wanting to create an additional template in
the future not inheriting the changes of your existing templates, it
is convenient to have a minimal / default template around to clone in
order to guarantee a fresh start.

2) Testing if some observed behavior is also present in a "default" vm
before reporting issues upstream.

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


Re: [qubes-users] VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

2017-05-22 Thread Unman
On Mon, May 22, 2017 at 10:33:30PM -0300, Franz wrote:
> @Unman,
> 
> 
> On Mon, May 22, 2017 at 5:05 PM, Unman  wrote:
> 
> > On Mon, May 22, 2017 at 04:39:50PM -0300, Franz wrote:
> > > Many thanks Unman for trying so hard to help me :-))
> > >
> > > >
> > > > The next error arose because you were using the qvm-prefs command
> > > > incorrectly.
> > > >
> > > > And so I dont understand what you mean by "gives the same error".
> > > >
> > > >
> > > It is the first one, in the heading,  the second is just syntax that you
> > > properly corrected, but even after the correction and after running
> > > qvm-prefs without errors, then trying to start the VM I fall again to the
> > > first error.
> > >
> > >
> > > > In you  other post you say that you can start a VM when you set the
> > > > networking to none - this makes me wonder if you have not yet reset the
> > > >
> > > >
> > > It seems the end of  your paragraph is lacking.
> > >
> > >
> > > > Can you check that you have done this
> > >
> > >
> > > If you mean rebooting, yes I rebooted many times.
> > >
> > >
> > > > and then try to explicitly start
> > > > from a terminal the upstream proxies ?
> > > >
> > >
> > >  I do not know what upstream proxies are, but if you means something like
> > > qvm-start 
> > > then I always get the heading error, unless the VM is not connected to
> > > network. In this last case it starts normally.
> > >
> > >
> > > > If I haven't understood exactly what your current problem is please can
> > > > you explain in more detail.
> > >
> > >
> > > Unman, the problem is that  in the past it was easy to fix this error
> > > simply pointing each VM to a different kernel, on the contrary now this
> > > workaround does NOT work anymore. Worse than that I cannot even make dom0
> > > recognize that I plugged in some USB stick, so even taking a backup (that
> > > luckily finished successfully)  out of dom0 is problem.
> > >
> > >
> > > > and perhaps provide the output from
> > > > qvm-start?
> > > >
> > > >
> > > qvm-start sys-net
> > > ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.
> > 38-11/vmlinuz
> > >
> > > qvm-start personal
> > > --> Starting NetVM sys-firewall
> > > --> Starting NetVM sys-net
> > > ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.
> > 38-11/vmlinuz
> > >
> > > result: nothing started
> > >
> > > But many thanks again for your strong patience
> > >
> >
> > So this suggests that you have not yet changed the kernel for sys-net,
> > yet you say that the qvm-prefs command runs without errors.
> > 1. Run qvm-prefs sys-net kernel.
> >
> 
> the above  command is interesting because it gives 4.4.38-11 while Qubes
> Manager gives 4.4.67-12
> 
> 
> > 2. Then qvm-prefs sys-net kernel -s 
> >
> 
> qvm-prefs sys-net kernel  -s 4.4.67-12
> 
> 3. Then qvm-prefs sys-net kernel.
> >
> 
> Important change here:
> 
> I get 4.4.67-12
> 
> 
> > 4. Then qvm-start sys-net
> >
> >
> Hurrah!!! you dit it, it started. Now everything works again.
> 
> 
> So what means all that?
> 
> 1. The kernel identification provided by Qubes Manager is not reliable and
> cannot be trusted
> 2. The qvm-prefs does work, but must be run for each VM, while when you
> first taught me to use it, I understood that it could be used once for all
> VMs.
> 3. When something like that happens the best thing to do is to look for the
> commands that may help: had I known that qvm-prefs sys-net kernel gives the
> actual kernel used I would had been able to find the answer. Simply
> trusting Qubes manager was not enough.
> 
> I have no words to thank you Unman. You are methodical, one step after the
> other in the proper order, never loosing faith that a rational simple
> answer exists, even if we are perhaps thousands of kilometers far away.
> Many thanks
> Fran
> 

I'm glad that you were able to solve your problem in the end.
This looks ike an interesting bug in Qubes Manager - I'll raise an issue
for it, although the redesign in r4 may resolve it in any case.

unman

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


Re: [qubes-users] VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

2017-05-22 Thread Franz
@Unman,


On Mon, May 22, 2017 at 5:05 PM, Unman  wrote:

> On Mon, May 22, 2017 at 04:39:50PM -0300, Franz wrote:
> > Many thanks Unman for trying so hard to help me :-))
> >
> > >
> > > The next error arose because you were using the qvm-prefs command
> > > incorrectly.
> > >
> > > And so I dont understand what you mean by "gives the same error".
> > >
> > >
> > It is the first one, in the heading,  the second is just syntax that you
> > properly corrected, but even after the correction and after running
> > qvm-prefs without errors, then trying to start the VM I fall again to the
> > first error.
> >
> >
> > > In you  other post you say that you can start a VM when you set the
> > > networking to none - this makes me wonder if you have not yet reset the
> > >
> > >
> > It seems the end of  your paragraph is lacking.
> >
> >
> > > Can you check that you have done this
> >
> >
> > If you mean rebooting, yes I rebooted many times.
> >
> >
> > > and then try to explicitly start
> > > from a terminal the upstream proxies ?
> > >
> >
> >  I do not know what upstream proxies are, but if you means something like
> > qvm-start 
> > then I always get the heading error, unless the VM is not connected to
> > network. In this last case it starts normally.
> >
> >
> > > If I haven't understood exactly what your current problem is please can
> > > you explain in more detail.
> >
> >
> > Unman, the problem is that  in the past it was easy to fix this error
> > simply pointing each VM to a different kernel, on the contrary now this
> > workaround does NOT work anymore. Worse than that I cannot even make dom0
> > recognize that I plugged in some USB stick, so even taking a backup (that
> > luckily finished successfully)  out of dom0 is problem.
> >
> >
> > > and perhaps provide the output from
> > > qvm-start?
> > >
> > >
> > qvm-start sys-net
> > ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.
> 38-11/vmlinuz
> >
> > qvm-start personal
> > --> Starting NetVM sys-firewall
> > --> Starting NetVM sys-net
> > ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.
> 38-11/vmlinuz
> >
> > result: nothing started
> >
> > But many thanks again for your strong patience
> >
>
> So this suggests that you have not yet changed the kernel for sys-net,
> yet you say that the qvm-prefs command runs without errors.
> 1. Run qvm-prefs sys-net kernel.
>

the above  command is interesting because it gives 4.4.38-11 while Qubes
Manager gives 4.4.67-12


> 2. Then qvm-prefs sys-net kernel -s 
>

qvm-prefs sys-net kernel  -s 4.4.67-12

3. Then qvm-prefs sys-net kernel.
>

Important change here:

I get 4.4.67-12


> 4. Then qvm-start sys-net
>
>
Hurrah!!! you dit it, it started. Now everything works again.


So what means all that?

1. The kernel identification provided by Qubes Manager is not reliable and
cannot be trusted
2. The qvm-prefs does work, but must be run for each VM, while when you
first taught me to use it, I understood that it could be used once for all
VMs.
3. When something like that happens the best thing to do is to look for the
commands that may help: had I known that qvm-prefs sys-net kernel gives the
actual kernel used I would had been able to find the answer. Simply
trusting Qubes manager was not enough.

I have no words to thank you Unman. You are methodical, one step after the
other in the proper order, never loosing faith that a rational simple
answer exists, even if we are perhaps thousands of kilometers far away.
Many thanks
Fran

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


Re: [qubes-users] Lenovo X1 Carbon 1.gen

2017-05-22 Thread Jean-Philippe Ouellet
On Sun, May 21, 2017 at 10:00 AM, Finsh  wrote:
> i recently got interested in the Qubes and i'm thinking on installing it
> on a Lenovo X1 Carbon 1gen Type: 3460-1F4.
>
> I couldn't find this specific Model in the HCL, are there any known issues?

I also ran on a 1st gen X1 (lenovo type 3443, 16gb ram, some
2xxx-series i7, 256gb disk) for a few months on stock BIOS. I only
switched to a newer (4th gen) X1 because I had a hardware failure on
my old one. If I didn't need to resume being productive immediately I
would have preferred to fix the old one rather than replace it,
especially so in hindsight given that I just lived with broken
suspend/resume for a while on my 4th gen (fixed now).

All hardware was well-supported IIRC, and it was more than adequate
performance-wise, even for my usual workload of ~10 simultaneous VMs
and lots of compiling stuff.

The fact that it allegedly runs coreboot almost makes me wanna try to
fix it and go back to it! :) IIRC it even had external USB ports on
separate USB controllers whereas my 4th-gen X1 does not. Overall a
solid Qubes laptop, would recommend.

Cheers,
Jean-Philippe

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


Re: [qubes-users] Debian 9 and Fedora 24 Should I be upgrading to these?

2017-05-22 Thread fooyreb
Andrew David Wong:
> On 2017-05-21 23:47, fooyreb wrote:
>> Andrew David Wong:
>>> We strongly recommend that you upgrade from EOL versions in 
>>> TemplateVMs. (This is not necessary in dom0.)
>>>
>>> Fedora 23 is EOL. Therefore, we recommend upgrading to Fedora 
>>> 24.
> 
>> Andrew, thx for the reply
> 
>> 1) I'm sorry, I don't see what you mean by  "not necessary in 
>> dom0"
> 
> 
> Please read the page I linked. It is explained there.
> 
>> 2) OK I went thru the steps: 
>> https://www.qubes-os.org/doc/template/fedora/upgrade-23-to-24/
> 
>> without any issues  except  now  sys-whonix  and  my CLI VPN 
>> Proxy-VM are complaining during startup : "error starting VM: 
>> invalid argument network device with mac 00:16.etc already exists
> 
>> However, the VMs  otherwise seem to be working and started
>> normally ..
> 
> 
> Check the NetVM of each VM. It may be that some VM is trying has some
> other VM as its NetVM and is trying to start that VM. But it may not
> be able to start because the devices is already assigned to another VM
> that's running. Check your devices tab in the VM settings for those
> VMs. You may have the wrong devices assigned.
> 

well the mac complaint just auto disappeared, however now in a terminal
in fedora 24 template , I am getting references to fedora 23  , is this
correct ?

Or do I need to do whatever the version for fedora is of  apt-get update
or dist-upgrade?


[user@fedora-24 ~]$ sudo dnf install chromium
Qubes OS Repository for VM (updates)171 kB/s | 473 kB
00:02
Fedora 23 - x86_64  2.6 MB/s |  43 MB
00:16
Fedora 23 - x86_64 - Updates3.1 MB/s |  25 MB
00:08
Last metadata expiration check: 0:00:08 ago on Mon May 22 14:40:27 2017.
Dependencies resolved.

 Package Arch   Version   Repository
  Size

Installing:
 chromiumx86_64 54.0.2840.90-3.fc23   updates
  31 M
 chromium-libs   x86_64 54.0.2840.90-3.fc23   updates
  41 M
 chromium-libs-media x86_64 54.0.2840.90-3.fc23   updates
 1.4 M
 libXScrnSaver   x86_64 1.2.2-9.fc23  fedora
  28 k
 u2f-hidraw-policy   x86_64 1.0.2-1.fc23  updates
  22 k


I said "no"  for now, not wanting to break anything  I do still have
the old Fedora 23  template VM, just in case, but I'm doubting that
matters ??

cc: qubes-group,  ADW


-- 
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/d29ef3b0-1e93-caae-777c-e8258b671ec1%40riseup.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] postfix

2017-05-22 Thread bbrr3332
On Friday, March 10, 2017 at 3:37:24 PM UTC, Ted Brenner wrote:
> On Thu, Mar 9, 2017 at 9:24 PM, Ted Brenner  wrote:
> 
> 
> 
> 
> 
> On Thu, Mar 9, 2017 at 6:57 AM, Unman  wrote:
> 
> 
> On Wed, Mar 08, 2017 at 08:36:11PM -0600, Ted Brenner wrote:
> 
> > On Wed, Mar 8, 2017 at 9:32 AM, Ted Brenner  wrote:
> 
> >
> 
> > > On Wed, Mar 8, 2017 at 9:15 AM, Unman  wrote:
> 
> > >
> 
> > >> On Tue, Mar 07, 2017 at 09:56:02PM -0600, Ted Brenner wrote:
> 
> > >> > Hi all,
> 
> > >> >
> 
> > >> > I'm trying to setup postfix following this guide
> 
> > >> > . But I'm not able to get a few
> 
> > >> > things to work.
> 
> > >> >
> 
> > >> > First, the commands I added to /rw/config/rc.local don't seem to run.
> 
> > >> > Namely, it doesn't appear to be mounting the /usr/local/etc/postfix
> 
> > >> > directory in /etc/postfix. Also postfix doesn't appear to be running on
> 
> > >> > startup. How do we tell if that gets run correctly?
> 
> > >> >
> 
> > >> > Thanks!
> 
> > >> > Ted
> 
> > >> >
> 
> > >>
> 
> > >> Other have pointed out that you need to set the executable bit on
> 
> > >> rc.local.
> 
> > >> You might want to cnsider instead the use of bind-dirs :
> 
> > >> www.qubes-os.org/doc/bind-dirs which provides similar functionality.
> 
> > >>
> 
> > >
> 
> > > Thanks all. Yes, this was the issue. Still can't get postfix to work but
> 
> > > that now appears to be due to missing the aliases.db.
> 
> > >
> 
> > > Is there a reason rc.local isn't executable by default?
> 
> > >
> 
> > > --
> 
> > > Sent from my Desktop
> 
> > >
> 
> >
> 
> > Quick follow up. What user is running rc.local? Is it root or user? I
> 
> > assume it is user since I'm seeing a permission denied when the call to run
> 
> > postfix tries to access the aliases.db file. So should I throw a sudo in
> 
> > front of the command to start postfix in the rc.local file? Or should I
> 
> > change the permissions on aliases.db? Per the instructions I'm also doing a
> 
> > mount command but that succeeds. Which is odd since if I try it as user, it
> 
> > fails saying only root can do it. Which is why I ask which user is running
> 
> > rc.local.
> 
> >
> 
> It's root - you could see this by appending:
> 
> echo `whoami` >> /home/user/rc_perms
> 
> But I suspect you already know this.
> 
> 
> 
> What are the permissions on aliases.db?
> 
> What template are you using and do you have selinux enabled?
> 
> 
> 
> 
> 
> 
> Thanks Unman. I'm using Fedora-24 and selinux is not enabled. aliases.db is 
> owned by root:root with rw-r--r--.  
> 
> 
> -- 
> 
> Sent from my Desktop
> 
> 
> I think the source of my problem was that postfix does some initial 
> configuration on its first launch. This requires the postfix-files file. But 
> that didn't get copied to /usr/local/etc/postfix which is mounted over 
> /etc/postfix. Once I added that file it launched successfully which appears 
> to have properly set up the aliases.db file so now all appears to be well. 
> Perhaps I'll submit a PR to update the postfix page to include copying 
> postfix-files to /usr/local/etc/postfix.
> 

I've come across this too and created a PR for the docs: 
https://github.com/QubesOS/qubes-doc/pull/427

-- 
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/ab7b2861-8891-4b8a-a69a-9eed9fcec3d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

2017-05-22 Thread Unman
On Mon, May 22, 2017 at 04:39:50PM -0300, Franz wrote:
> Many thanks Unman for trying so hard to help me :-))
> 
> >
> > The next error arose because you were using the qvm-prefs command
> > incorrectly.
> >
> > And so I dont understand what you mean by "gives the same error".
> >
> >
> It is the first one, in the heading,  the second is just syntax that you
> properly corrected, but even after the correction and after running
> qvm-prefs without errors, then trying to start the VM I fall again to the
> first error.
> 
> 
> > In you  other post you say that you can start a VM when you set the
> > networking to none - this makes me wonder if you have not yet reset the
> >
> >
> It seems the end of  your paragraph is lacking.
> 
> 
> > Can you check that you have done this
> 
> 
> If you mean rebooting, yes I rebooted many times.
> 
> 
> > and then try to explicitly start
> > from a terminal the upstream proxies ?
> >
> 
>  I do not know what upstream proxies are, but if you means something like
> qvm-start 
> then I always get the heading error, unless the VM is not connected to
> network. In this last case it starts normally.
> 
> 
> > If I haven't understood exactly what your current problem is please can
> > you explain in more detail.
> 
> 
> Unman, the problem is that  in the past it was easy to fix this error
> simply pointing each VM to a different kernel, on the contrary now this
> workaround does NOT work anymore. Worse than that I cannot even make dom0
> recognize that I plugged in some USB stick, so even taking a backup (that
> luckily finished successfully)  out of dom0 is problem.
> 
> 
> > and perhaps provide the output from
> > qvm-start?
> >
> >
> qvm-start sys-net
> ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz
> 
> qvm-start personal
> --> Starting NetVM sys-firewall
> --> Starting NetVM sys-net
> ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz
> 
> result: nothing started
> 
> But many thanks again for your strong patience
> 

So this suggests that you have not yet changed the kernel for sys-net,
yet you say that the qvm-prefs command runs without errors.
1. Run qvm-prefs sys-net kernel.
2. Then qvm-prefs sys-net kernel -s 
3. Then qvm-prefs sys-net kernel.
4. Then qvm-start sys-net

That was what my missing paragraph conclusion said.

If there's a discrepancy between the result returned at 3 and 4, there's
something seriously amiss, but at least we will know where to look.

unman

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


Re: [qubes-users] How do I get Qubes 4.0 pre-release/dev build?

2017-05-22 Thread Unman
On Mon, May 22, 2017 at 10:20:54AM -0700, img2s...@gmail.com wrote:
> Le mercredi 30 novembre 2016 18:34:34 UTC+1, Jean-Philippe Ouellet a écrit :
> > On Wed, Nov 30, 2016 at 11:49 AM,   wrote:
> > > Can someone tell me where I can get the files? Any tips or hints when it 
> > > comes to running the latest build?
> > 
> > I am not aware of any publicly-available full "development builds",
> > however qubes-builder[1] makes it very easy to build them yourself..
> > 
> > [1]: https://www.qubes-os.org/doc/qubes-builder/
> 
> hello, could you explain me how to use qubes-builder please?
> i want to try qubes 4.0, don't know how to do it.
> thanks
> 

Did you read the doc that was linked?
What is it that you don't understand?

There is additional information in the doc folder, and the example
configs are (generally) well commented.

The basic idea is that qubes-builder will allow you to specify *what*
you want to build (either using the setup script, or providing your own
builder.conf based on the examples, and then download the sources,
verify them and allow you to build individual packages or full
templates as you wish.

You can get started by following the instructions on the linked page, or
in the building-archlinux-template document.
I would strongly suggest that you do a basic build first, using the
./setup script, and then run make and look at the available build
options.
Once you have done a quick build (use a minimal flavour), change the
release to 'master' and start building from there.

If you encounter specific problems ask again

cheers

unman

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


Re: [qubes-users] VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

2017-05-22 Thread Franz
On Mon, May 22, 2017 at 2:10 PM, Unman  wrote:

> On Sat, May 20, 2017 at 11:27:01PM -0300, Franz wrote:
> > On Sat, May 20, 2017 at 7:49 PM, Unman 
> wrote:
> >
> > > On Sat, May 20, 2017 at 07:34:28PM -0300, Franz wrote:
> > > > On Sat, May 20, 2017 at 7:20 PM, Unman 
> > > wrote:
> > > >
> > > > > On Sat, May 20, 2017 at 04:27:24PM -0300, Franz wrote:
> > > > > > Hello,
> > > > > >
> > > > > > the usual trick of selecting other kernel in Qubes manager does
> not
> > > work
> > > > > > running
> > > > > > qvm-prefs -s kernel default
> > > > > > gives
> > > > > > A VM with the name 'kernel" does not exist in tne system
> > > > > >
> > > > > > ls /var/lib/qubes/vm-kernels/
> > > > > > gives
> > > > > > 4.4.55-11 4.4.62-12 4.4.67-12
> > > > > >
> > > > > > However one of the VMs does correctly starts. this one shows it
> is
> > > using
> > > > > > 4.4.55-11
> > > > > >
> > > > > > Best
> > > > > > Fran
> > > > >
> > > > > You are supposed to include the name of the qube you want to work
> on
> > > > > when using qvm-prefs.
> > > > > If you want to run against a number of qubes just script it with a
> bash
> > > > > script iterating over the names.
> > > > >
> > > > > unman
> > > > >
> > > >
> > > > Many thanks Unman, following your suggestion  I do not get errors
> with
> > > the
> > > > qvm-prefs command, but the same trying to start the VMs I get the
> same
> > > > error that makes the heading of this thread.
> > > >
> > >
> > > The recent update provided a new kernel - Qubes only maintains 3
> > > recent kernels, so one has been deleted. That's why you get this error.
> > > (A number of people have reported this.)
> > > You should be able to set the default kernel as you have tried - if
> this
> > > doesn't work for you just set one of the kernels that you DO have
> > > explicitly.
> > >
> > > unman
> > >
> >
> >
> > this is the first thing that I tried using Qubes manager. It worked in
> the
> > past when after an update the same thing happened, But it is not working
> > anymore now as I reported in the first post. None of the available
> kernels
> > work.
> >
> > I even tried to create a standalone as a workaround, but it gives the
> same
> > error.
> >
> > best
> > Fran
>
> Hello Fran
>
> It's not clear to me what error you are reporting.
> The error in the subject line arises because the recent upgrade
> deleted the kernel that you have allocated to a qube.
>

Many thanks Unman for trying so hard to help me :-))

>
> The next error arose because you were using the qvm-prefs command
> incorrectly.
>
> And so I dont understand what you mean by "gives the same error".
>
>
It is the first one, in the heading,  the second is just syntax that you
properly corrected, but even after the correction and after running
qvm-prefs without errors, then trying to start the VM I fall again to the
first error.


> In you  other post you say that you can start a VM when you set the
> networking to none - this makes me wonder if you have not yet reset the
>
>
It seems the end of  your paragraph is lacking.


> Can you check that you have done this


If you mean rebooting, yes I rebooted many times.


> and then try to explicitly start
> from a terminal the upstream proxies ?
>

 I do not know what upstream proxies are, but if you means something like
qvm-start 
then I always get the heading error, unless the VM is not connected to
network. In this last case it starts normally.


> If I haven't understood exactly what your current problem is please can
> you explain in more detail.


Unman, the problem is that  in the past it was easy to fix this error
simply pointing each VM to a different kernel, on the contrary now this
workaround does NOT work anymore. Worse than that I cannot even make dom0
recognize that I plugged in some USB stick, so even taking a backup (that
luckily finished successfully)  out of dom0 is problem.


> and perhaps provide the output from
> qvm-start?
>
>
qvm-start sys-net
ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

qvm-start personal
--> Starting NetVM sys-firewall
--> Starting NetVM sys-net
ERROR: VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

result: nothing started

But many thanks again for your strong patience

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

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

[qubes-users] Re: R3.2: suspended laptop, cannot login

2017-05-22 Thread Eric Duncan
For the record, I still don't know what happened with this install.  It was 
from a USB stick, without verification.  Perhaps it was a corrupted install 
(3rd install, btw from the same USB stick).

Recently I switched to a USB3 stick, and made sure to 'verify' before 
installing.

This time the password prompt comes up after the blank screen.  So it is all 
fine now.

I'll chalk it up to a bad installation.

On Friday, May 5, 2017 at 7:38:43 PM UTC-4, Eric Duncan wrote:
> New install, system went into suspend.  Upon resume:
> 
> - I cannot login / there is no login box.  
> - Window days that says XScreenSaver 5.35, dom0, "Authentication Failed!" <- 
> I haven't done anything to authenticate.
> - Username: "user" (my username), but there is no Password box.
> 
> How do I type a password?  I tried typing just into the black void, but it 
> just flashes the screen and constantly re-displays that XScreenSaver window.
> 
> More info...
> 
> I just installed Qubes OS R3.2 and can't wait to get my Arch and Debian 
> testing stuff running next to each other along with BlackArch and Whonix.  
> Y'all just combined my 4 laptops into one!  :)
> 
> I literally just logged in.  I closed the laptop screen, which put the laptop 
> into suspend, to move to a new room where I can focus on my newfound glory.
> 
> Except, when I open the screen I am showing a black screen with XScreenSaver 
> and my username telling me "Authentication Failed!"  Except, I haven't tried 
> to log in yet.
> 
> If it matters:
> 
> - Installed to USB3 stick
> - Current booted up on Asus G750JW
> 
> How do I get back into Qubes OS?

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


Re: [qubes-users] which things are, and which things are not encrypted on the disk.

2017-05-22 Thread Unman
On Mon, May 22, 2017 at 10:34:18AM -0700, blacklight wrote:
> On Sunday, 21 May 2017 03:03:50 UTC+2, Andrew David Wong  wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2017-05-18 02:55, Zrubi wrote:
> > > On 05/18/2017 09:48 AM, pandakaas...@gmail.com wrote:
> > >> I recently came across this PDF file stating that dom0 and the
> > >> hypervisor (Xen) are stored unencrypted on the disk, because the
> > >> disk wouldnt be able to boot(According to the PDF). but as far as I
> > >> know, only /boot and GRUB are stored unencrypted.  so is this PDF
> > >> file wrong, or was I wrong (or both?).
> > > 
> > >> Here you have a link to the file, you can find it on page 7: 
> > >> http://www.cs.uu.nl/docs/vakken/b3sec/Proj15/QubesOS.pdf
> > > 
> > > 
> > > The Xen itself and the dom0 kernel (located in /boot) are both
> > > unencrypted.
> > > 
> > > This can be the reason using TPM and AEM:
> > > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
> > > https://www.qubes-os.org/doc/anti-evil-maid/
> > > 
> > 
> > And everything except /boot is encrypted with LUKS by default.
> > In particular, the contents of dom0 are also encrypted. See:
> > 
> > https://www.qubes-os.org/doc/custom-install/
> > 
> > - -- 
> > Andrew David Wong (Axon)
> > Community Manager, Qubes OS
> > https://www.qubes-os.org
> > -BEGIN PGP SIGNATURE-
> > 
> > iQIcBAEBCgAGBQJZIOdoAAoJENtN07w5UDAwoZ8QAJijXJxCcIM2Ze/yTtxMUef/
> > h3ROYup2mjHCscn2SOTRqmUj4Aa/aIByILaj1OAOEWzsRDb5Y/r6Vizjakg0dibK
> > HOfmIkTFFmbkeA8kHd2w5z7OrBiQCUcDt1rCz11CDgA1YWmLD/4sWigU2OK9J68h
> > 9mj5mvwMbv7w4XE+O11LZww9SICBfV5y1akC3AdOS4Qasb7ujdx15X/rOlHEdcIQ
> > iZUVO9NmpFpQ/DWCzW/6BY1b+2rRV2HEd9KwRgRTexQ3AEfo+RY7i74PWbpHRtnS
> > FVREing5ogQe2R4F/9d1gYepHPw4YAThc0h8ZPjeHC4K67SxdcIHOL3ISbuxtSPL
> > c4pPHGvg8+lXzZ9JX1nYie5qvD8rK4dC+G78wWgba77fuCwTkjtGJR2ZUT5LaA3U
> > bnAAwSRO3IcJnd3ZK//uXqlJKyvxk/mNzT7AlG53FbZ92zghcBRc8wI0bS6tY76A
> > uCFN8P8qi9VuszQoJhxsTxe99yXz97M9VvoLY0CQC8I5HJFJEv73RTHFlchQZG8+
> > U8X/rq+y02RoRHLCwl3KEc8aYOZCMt9EC4p5VGeljlClo5mBSArujDkGEYTPJfk5
> > GV5vy2wU3m8s8CBC3J9wx/8c0gBufqXplfjrR3JwyoaEY2a6gFKpEF2U3KwmaLlW
> > Negatcg+YVAMvXotcROJ
> > =8WSK
> > -END PGP SIGNATURE-
> 
> So the notion in the pdf file stating that dom0 is unecrypted is wrong i 
> understand? also, what about xen, is it located in /boot or is it also 
> encrypted?
> 

Yes, there's a fair bit in that paper that's wrong, and this certainly
is. But it's just a student paper isn't it?
Xen is included in /boot and is therefore unencrypted in a standard
install.

unman

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


[qubes-users] HCL - HP Pavilion

2017-05-22 Thread Michael
I bought a new laptop and just took the SSD drive out of the old laptop
and put it into the new laptop.  I turned the laptop on and booted up
like nothing had changed...  Worked seamlessly

-- 
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/8a31a350-3b10-fe93-fe0f-31f5420b6b22%40SIL.ORG.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-HP-HP_Pavilion_Notebook-20170522-134914.yml
Description: application/yaml


Re: [qubes-users] which things are, and which things are not encrypted on the disk.

2017-05-22 Thread blacklight
On Sunday, 21 May 2017 03:03:50 UTC+2, Andrew David Wong  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2017-05-18 02:55, Zrubi wrote:
> > On 05/18/2017 09:48 AM, pandakaas...@gmail.com wrote:
> >> I recently came across this PDF file stating that dom0 and the
> >> hypervisor (Xen) are stored unencrypted on the disk, because the
> >> disk wouldnt be able to boot(According to the PDF). but as far as I
> >> know, only /boot and GRUB are stored unencrypted.  so is this PDF
> >> file wrong, or was I wrong (or both?).
> > 
> >> Here you have a link to the file, you can find it on page 7: 
> >> http://www.cs.uu.nl/docs/vakken/b3sec/Proj15/QubesOS.pdf
> > 
> > 
> > The Xen itself and the dom0 kernel (located in /boot) are both
> > unencrypted.
> > 
> > This can be the reason using TPM and AEM:
> > https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
> > https://www.qubes-os.org/doc/anti-evil-maid/
> > 
> 
> And everything except /boot is encrypted with LUKS by default.
> In particular, the contents of dom0 are also encrypted. See:
> 
> https://www.qubes-os.org/doc/custom-install/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> -BEGIN PGP SIGNATURE-
> 
> iQIcBAEBCgAGBQJZIOdoAAoJENtN07w5UDAwoZ8QAJijXJxCcIM2Ze/yTtxMUef/
> h3ROYup2mjHCscn2SOTRqmUj4Aa/aIByILaj1OAOEWzsRDb5Y/r6Vizjakg0dibK
> HOfmIkTFFmbkeA8kHd2w5z7OrBiQCUcDt1rCz11CDgA1YWmLD/4sWigU2OK9J68h
> 9mj5mvwMbv7w4XE+O11LZww9SICBfV5y1akC3AdOS4Qasb7ujdx15X/rOlHEdcIQ
> iZUVO9NmpFpQ/DWCzW/6BY1b+2rRV2HEd9KwRgRTexQ3AEfo+RY7i74PWbpHRtnS
> FVREing5ogQe2R4F/9d1gYepHPw4YAThc0h8ZPjeHC4K67SxdcIHOL3ISbuxtSPL
> c4pPHGvg8+lXzZ9JX1nYie5qvD8rK4dC+G78wWgba77fuCwTkjtGJR2ZUT5LaA3U
> bnAAwSRO3IcJnd3ZK//uXqlJKyvxk/mNzT7AlG53FbZ92zghcBRc8wI0bS6tY76A
> uCFN8P8qi9VuszQoJhxsTxe99yXz97M9VvoLY0CQC8I5HJFJEv73RTHFlchQZG8+
> U8X/rq+y02RoRHLCwl3KEc8aYOZCMt9EC4p5VGeljlClo5mBSArujDkGEYTPJfk5
> GV5vy2wU3m8s8CBC3J9wx/8c0gBufqXplfjrR3JwyoaEY2a6gFKpEF2U3KwmaLlW
> Negatcg+YVAMvXotcROJ
> =8WSK
> -END PGP SIGNATURE-

So the notion in the pdf file stating that dom0 is unecrypted is wrong i 
understand? also, what about xen, is it located in /boot or is it also 
encrypted?

-- 
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/0eb162c1-40fc-412b-9339-2478f19c9544%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Screen resolution

2017-05-22 Thread Unman
On Sun, May 21, 2017 at 01:39:31PM -0400, 'Misterblue' via qubes-users wrote:
> Good day
> In my linux appVM based on fedora-debian the screen resolution is different 
> with to my laptop. When I browse will be detected that of the appVM or the 
> laptop?
> 
> Best regards
>

Are you sure the resolution is different? With a standard template-based
appVM?
In any case the browser will report that of the appVM.

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


[qubes-users] Re: Transform an HVM into a template ?

2017-05-22 Thread Grzesiek Chodzicki
W dniu poniedziałek, 22 maja 2017 08:47:01 UTC+2 użytkownik Swâmi Petaramesh 
napisał:
> Hi there,
> 
> I have a Qubes Windows HVM which I have installed as a standalone HVM.
> 
> According to the documentation, it is also possible to create Windows 
> AppVMs from a template VM.
> 
> Is there a way I could convert my existing Windows HVM into a "template" 
> so I can derive AppVMs from it ?
> 
> I coudln't find this documented anywhere...
> 
> TIA for any help.
> 
> Best regards.
> 
> ॐ
> -- 
> Swâmi Petaramesh  PGP 9076E32E

Create a new TemplateHVM then copy the private.img and root.img to the 
appropriate folder

-- 
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/eb66d14d-2d0b-485b-9354-9ef2b6c9e8ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] VM kernel does not exist: /var/lib/qubes/vm-kernels/4.4.38-11/vmlinuz

2017-05-22 Thread Unman
On Sat, May 20, 2017 at 11:27:01PM -0300, Franz wrote:
> On Sat, May 20, 2017 at 7:49 PM, Unman  wrote:
> 
> > On Sat, May 20, 2017 at 07:34:28PM -0300, Franz wrote:
> > > On Sat, May 20, 2017 at 7:20 PM, Unman 
> > wrote:
> > >
> > > > On Sat, May 20, 2017 at 04:27:24PM -0300, Franz wrote:
> > > > > Hello,
> > > > >
> > > > > the usual trick of selecting other kernel in Qubes manager does not
> > work
> > > > > running
> > > > > qvm-prefs -s kernel default
> > > > > gives
> > > > > A VM with the name 'kernel" does not exist in tne system
> > > > >
> > > > > ls /var/lib/qubes/vm-kernels/
> > > > > gives
> > > > > 4.4.55-11 4.4.62-12 4.4.67-12
> > > > >
> > > > > However one of the VMs does correctly starts. this one shows it is
> > using
> > > > > 4.4.55-11
> > > > >
> > > > > Best
> > > > > Fran
> > > >
> > > > You are supposed to include the name of the qube you want to work on
> > > > when using qvm-prefs.
> > > > If you want to run against a number of qubes just script it with a bash
> > > > script iterating over the names.
> > > >
> > > > unman
> > > >
> > >
> > > Many thanks Unman, following your suggestion  I do not get errors with
> > the
> > > qvm-prefs command, but the same trying to start the VMs I get the same
> > > error that makes the heading of this thread.
> > >
> >
> > The recent update provided a new kernel - Qubes only maintains 3
> > recent kernels, so one has been deleted. That's why you get this error.
> > (A number of people have reported this.)
> > You should be able to set the default kernel as you have tried - if this
> > doesn't work for you just set one of the kernels that you DO have
> > explicitly.
> >
> > unman
> >
> 
> 
> this is the first thing that I tried using Qubes manager. It worked in the
> past when after an update the same thing happened, But it is not working
> anymore now as I reported in the first post. None of the available kernels
> work.
> 
> I even tried to create a standalone as a workaround, but it gives the same
> error.
> 
> best
> Fran

Hello Fran

It's not clear to me what error you are reporting.
The error in the subject line arises because the recent upgrade
deleted the kernel that you have allocated to a qube.

The next error arose because you were using the qvm-prefs command
incorrectly.

And so I dont understand what you mean by "gives the same error".

In you  other post you say that you can start a VM when you set the
networking to none - this makes me wonder if you have not yet reset the

Can you check that you have done this and then try to explicitly start
from a terminal the upstream proxies ?

If I haven't understood exactly what your current problem is please can
you explain in more detail. and perhaps provide the output from
qvm-start?

unman

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


Re: [qubes-users] How to extract a backup from dom0

2017-05-22 Thread Franz
On Mon, May 22, 2017 at 12:49 PM, Vít Šesták <
groups-no-private-mail--contact-me-at--contact.v6ak@v6ak.com> wrote:

> Do you have Qubes installer anywhere? If so, boot it, choose you want to
> repair the system. You will be prompted for disk encryption password(s). It
> will try to autodetect where your broken installation lies and mount it
> under AFAIR /mnt/sysimage. Then, you can access it or (if you want) chroot
> to it.
>
> With the rescue mode, you probably won't be able to connect to network,
> but USB should work.
>
>
Many thanks to all, I'' try
Best
Fran


> Regards,
> Vít Šesták 'v6ak'
>
> --
> 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/454d8ada-9c4b-4bc9-8abc-415f5d2617ec%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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


[qubes-users] Re: Text-based install inevitably failing on my ASUS GL552VW

2017-05-22 Thread yessiouimc
On Monday, May 22, 2017 at 3:52:48 AM UTC+2, Mike Freemon wrote:
> On 05/21/2017 01:48 PM, Mike Keehan wrote:
> > On Sun, 21 May 2017 09:36:35 -0700 (PDT)
> > yessiouimc-re5jqeeqqe8avxtiumw...@public.gmane.org wrote:
> >> So, I'm using a usb flash drive as my installation source. Whenever I
> >> boot from my usb, I'm greeted with the ususal installation menu with
> >> all the features it normally should have. Whenever I try to install
> >> qubes on my system, the graphical menu tries to load and I can see
> >> the Qubes logo on the light blue background for a split second,
> >> before it disappears and I continue on the text install menu. No
> >> matter what I do, I end up with this error :
> >>
> >> "Encryption requested for LUKS device sda2 but no encryption key
> >> specified for this device."
> >>
> >> Before the installer stops and I have to restart my pc. After reading
> >> up a little bit on the subject, it seems like the text installer
> >> simply doesnt allow you to input the encryption key you want to use,
> >> so it inevitably fails. It seems like this might be due to
> >> incompatibility with my GTX 960M card, where my system attempts to
> >> use it but fails because Qubes is incompatible with it. What should I
> >> do? Something I do know is I could force my system to use intel
> >> graphics, but my BIOS doesn't let me do that anywhere, and I'm scared
> >> of flashing another BIOS, screwing things up and bricking my
> >> expensive device.
> >>
> >> So anyway, thanks in advance to anyone who takes the time to reply,
> >> and regardless I hope you have a nice day.
> >>
> >
> > I had to use EFI to boot the usb stick on my machine - the legacy
> > bios boot always ended up in the text installer.
> 
> Although your hardware is not the same as mine[1], they might be close 
> enough that these comments are helpful.
> 
> Like Keehan, I also found that the BIOS compatibility boot did not work 
> on my hardware.
> 
> The problem is a X startup failure, specifically, "no such file or 
> directory" for /dev/dri/card0.  My VGA controller is an Intel 5916.  No 
> kernel module was loaded for it, thus the error.  And so the installer 
> dropped into text mode.
> 
> I, like you, found that the text installer does not work, for the reason 
> you have already found (unable to specify an encryption key).  I did not 
> pursue that any further.
> 
> My hardware presents two UEFI menu items for the installation USB drive, 
> one with "Partition 1" and one without.
> 
> First, I tried the one without "Partition 1".  The system went into a 
> "menu loop", i.e. the menu of "Test media...", "Install Qubes 3.2", 
> "Troubleshoot...", "Rescue..." would just reappear after selecting 
> "Install Qubes 3.2".  I could not get past it.
> 
> So then I UEFI booted using the "Partition1" menu option of the USB 
> install drive.  Success.
> 
> But the touchpad was not working (e.g. no mouse).  I had to plug in a 
> USB mouse.
> 
> And.. the resolution on the laptop display was only 800x600 (native is 
> 1920x1080).
> 
> Also, the wifi networking did not "just work".  Specifically, I had to 
> manually launch the network manager nm-applet, and create a wiki 
> connection definition.  Not a big deal once I realized that's all it 
> was, but it was a little unexpected.
> 
> The touchpad and screen resolution problems were not resolved until I 
> upgraded to the latest (at the time) unstable kernel.  From my earlier post:
> 
> > The short version: The display issues were caused by using a kernel
> that is "too old" (for this hardware).
> >
> > This hardware requires kernel 4.8.12 (to be more precise, all I can
> say at the moment is that the minimum kernel version for this hardware
> is > 4.4.55 and <= 4.8.12).
> >
> > Kernel 4.8.12 is only available from the unstable repository, so I
> > had
> to get Qubes installed in a "degraded" way before I could issue the
> magic command:
> >
> > qubes-dom0-update --enablerepo=qubes-dom0-unstable kernel
> > kernel-qubes-vm
> 
> One thing for you to watch out for is the nVidia and (if you have it, 
> which I think you do) the nVidia Optimus stuff.  That might potentially 
> create some fun for you.
> 
> 
> [1] 
> https://groups.google.com/forum/?utm_medium=email_source=footer#!msg/qubes-users/BUe4tFfERtA/buazJHIzCQAJ

Thanks for your help. I enabled UEFI, or at least, I think I did, because I 
enabled "fast boot" but if I tried to enable "secure boot" the qubes installer 
would tell me to disable it. I also made sure the BIOS was referring to the 
"partition 1" of my usb device (it already was). Enabling UEFI seemed to do 
more bad than good, since now the qubes installer doesnt even have the blue 
background and it's just grey letters on a black background. It still tossed me 
to the text installer which worked as expected (of course, I couldn't set the 
encryption password because the devs probably didn't code that into the text 
installer in the first place). All of this would be much 

[qubes-users] Re: Suitability for an application testing scenario

2017-05-22 Thread Vít Šesták
VirtualBox inside a VM is not going to work, at least not with x64. It might 
work with x86 (32b).

Virtualization for x64 generally requires virtualization extensions (VT-x or 
so), but they aren't available inside a Qubes VM. Maybe some patches can add 
support for it (look for “nested HVM” or “nested virtualization”), at the cost 
of additional complexity and thus larger attack surface. It reportedly used to 
be impossible to implement x64 virtualization without those extensions. It 
might be possible now, but I haven't seen it being implemented.

Virtualization for x86 (32-bit) guests might work even without virtualization 
extensions. I haven't tried it, though.

If course, emulation (QEMU, DosBox, …) will work, but it is going to be slow.

Regards,
Vít Šesták 'v6ak'

-- 
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/9c54003c-6d3f-4fb3-9806-106a5aa92d2a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How to extract a backup from dom0

2017-05-22 Thread Vít Šesták
Do you have Qubes installer anywhere? If so, boot it, choose you want to repair 
the system. You will be prompted for disk encryption password(s). It will try 
to autodetect where your broken installation lies and mount it under AFAIR 
/mnt/sysimage. Then, you can access it or (if you want) chroot to it.

With the rescue mode, you probably won't be able to connect to network, but USB 
should work.

Regards,
Vít Šesták 'v6ak'

-- 
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/454d8ada-9c4b-4bc9-8abc-415f5d2617ec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to extract a backup from dom0

2017-05-22 Thread Bernhard

> After the recent update I lost all communications out of dom0, no
> network as already described here
> https://groups.google.com/forum/#!topic/qubes-users/unDqbBa_k_Y
> 
>
> Also  USB sticks do not mount anymore even after deleting all
> assignments of 00:1a.0  and 00:1d.00  
>
> But dom0 still works, so made a backup of  all VMs. But how to take
> the backup out of dom0?
Boot a live-linux with built-in LUKS support. Tails for example
(activate root access after boot).
Then "break in" by hand following standard tutorials "how to mount a
luks drive", and copy all
to your usb disc. consider generatinga huge sparse-file, say, BACKUP.enc
then loop-it:
losetup  -f   % findes out a free slot
losetup /dev/loopxxx   BACKUP.enc
Now /dev/loopxxx is a device that can by crypt-setuped by luks in a
standard tutorial way. Mount it, and move your data in.

Bernhard

-- 
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/05617375-2010-3610-db90-0ca9c8e24b46%40web.de.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Suitability for an application testing scenario

2017-05-22 Thread Matty South
On Sunday, May 21, 2017 at 1:02:52 AM UTC-5, David Seaward wrote:
> Hi,
> 
> Previously I've used type II VMs like VirtualBox for application
> testing: install application on the base OS, test features (including
> GUI features, shell integration and system integration), discard
> changes. Additional steps might include: pause/resume the VM, save
> different states of the VM.
> 
> Are Qubes OS VMs suitable for the same purpose? Specifically, is it
> possible to switch from a dom0 view to a VM-only view, rather than VM
> windows appearing in dom0?
> 
> Regards,
> David
> 
> P.S. If this is possible, Qubes OS also seems like a more flexible
> alternative to dual-booting?

Great question, David. I would say if testing could be done in Xen, then it 
could likely be done in Qubes. It's really difficult to mess with dom0 or how 
it looks, so I doubt you will have luck switching views. What guest OS will you 
mainly use for testing?  One option may be, if you're accustomed to Virtualbox 
for Windows for example, setting up a Windows VM how you like it for testing 
and loading a guests in there. I can't comment on the performance of Virtualbox 
inside of a VM though. Has anyone else done 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/64062cda-25cd-4617-8acb-b09d700ece75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] How to extract a backup from dom0

2017-05-22 Thread Franz
After the recent update I lost all communications out of dom0, no network
as already described here
https://groups.google.com/forum/#!topic/qubes-users/unDqbBa_k_Y

Also  USB sticks do not mount anymore even after deleting all assignments
of 00:1a.0  and 00:1d.00

But dom0 still works, so made a backup of  all VMs. But how to take the
backup out of dom0?

I imagine can boot with a live Qubes or live linux distribution and from
there try to find my backup somewhere. But where? Also everything is
encrypted, so how may I decrypt it?

Well, it seems complicated but perhaps there is a tutorial or something.

Any idea?
Best
Fran

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


Re: [qubes-users] Lenovo X1 Carbon 1.gen

2017-05-22 Thread Holger Levsen
On Sun, May 21, 2017 at 07:00:04AM -0700, Finsh wrote:
> i recently got interested in the Qubes and i'm thinking on installing it
> on a Lenovo X1 Carbon 1gen Type: 3460-1F4.
> 
> I couldn't find this specific Model in the HCL, are there any known issues?
 
I've installed Qubes on mine before it ran coreboot and encountered no issues.
(Except that 8gb RAM is a bit too little for my taste.)

> Also i want to combine it withe Coreboot/ libreboot, which got recently

I've not tested installing Qubes since it runs coreboot, mostly because I had
no real opportunity to do so since then…

(But I've seen a X200s where the Qubes installation failed to boot after it
was corebooted…)

So I suppose there is one way to find out: try. You should keep a backup of 
your legacy BIOS anyway… ;-)


-- 
cheers,
Holger

-- 
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/20170522115725.GC22953%40layer-acht.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Digital signature


[qubes-users] Re: Installing qubes-window-tools makes win7 HVM GUI unusable

2017-05-22 Thread Jarle Thorsen
> > I have now found the very slow GUI described in my previous thread 
> > https://groups.google.com/d/msg/qubes-users/gzS8Zc9StxQ/gSwEC-fdFAAJ to be 
> > a direct result of installing the qubes-windows-tools into the VM.
> > 
> > That's why I'm starting a new thread focusing on this problem here.
> > 
> > After initial install of a brand new win7 VM everything works "just fine", 
> > I can drag windows across the desktop even when running VM in max 
> > resolution, without any delay.
> > 
> > However after installing qubes-windows-tools and rebooting it is like I am 
> > running a totally different OS. If I try to drag a window from one place to 
> > the other there is a delay of more than a second before the window is moved 
> > to the new location. Using qubes-windows-tools 3.2.1 or 3.2.2 make no 
> > difference.

I totally didn't expect this, but installing i3 window manager in dom0 (instead 
of default xfce) makes the Windows VM SO much more responsive!

It is still laggy enough that I prefer doing my work via Remmina remote 
desktop, but it is a big step in the right direction!

-- 
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/24d670c6-5c93-4952-aa81-414ea69f49d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Transform an HVM into a template ?

2017-05-22 Thread Swâmi Petaramesh

Hi there,

I have a Qubes Windows HVM which I have installed as a standalone HVM.

According to the documentation, it is also possible to create Windows 
AppVMs from a template VM.


Is there a way I could convert my existing Windows HVM into a "template" 
so I can derive AppVMs from it ?


I coudln't find this documented anywhere...

TIA for any help.

Best regards.

ॐ
--
Swâmi Petaramesh  PGP 9076E32E

--
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/6bba87c8-1ad5-5e1d-4d9b-3d06d1449d24%40petaramesh.org.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to close the CVE-2015-0565 security gap for any RAM-type?

2017-05-22 Thread xet7
Is there list of available hardware that has libre firmware? So it could be 
used with quality RAM ?

-- 
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/8dd75f45-3d63-4a14-a0d0-e1f808f658d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.