Re: [qubes-users] How to change date and time format in Thunderbird

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2019-08-15 11:25 AM, galt...@gmail.com wrote:
> I've installed thunderbird today and all is fine except that dates
> are shown in US format: MM/DD/YY. How can I change this to UK
> format: DD/MM/YY?
> 
> I googled and found that thunderbird gets its setting from the OS.
> 
> Thank you.
> 

This is a known bug in Thuderbird:

https://bugzilla.mozilla.org/show_bug.cgi?id=1426907

I managed to get ISO dates by following the workaround in this comment:

https://bugzilla.mozilla.org/show_bug.cgi?id=1426907#c144

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl13Iv8ACgkQ203TvDlQ
MDAHww/9GSAVh1LDxZL+ni0cVAUklANkN7uXGVHpsDV4KPyciJw6IUFa2iz3Upuw
IXdW5btHFo8WhhOdOjHteq9FIdzjinYpkqu4FobTmfscXtvK+CB8Z5tqKoa9yM+o
PKehp6UodLnuJaPM3rzXaDrbZSRVIxXvXvGfhGP9QDGCbDz0euPTJO26U34Tt8+u
eercnVqqoLTA9hXy2onOUUuWih+6OcNOixqG8s1XROJqE6yS7hDWI+i8YnLxGpiW
mbSYTvPHuWfV3gx3ZAiPBWDPLXGidQ/DZEzkb4fMhvWkCmiTY4K4Le68zohmdZcn
AdinIVBkyHNnp22XrM/k5SiommS6NAZlcDGpxxP1Bcx+CSu9bQ6/RLyUr/naKZuQ
4i687ex0C4Hi0KaD9NqbIVILp771pJNvnL2CO0739w07PRTnOHJta6cYoy/UtPio
u72ZeAT7H2+zsj692njxvuSl2gJ606mgljTJRQxKL5OVkeRsK+rfbX1pGo5w252q
/ptIOlCzSSMe4qbB7iur8atlVsoUj99unnrCE0HTg6TptygWRs4iFMP8q/Wj2pf1
NEjhbNzR6/hNSC2dUmu8uoJqtRUObCLW5SzNgqcUXprnmPGpnJVXqklkHOz8YKqZ
Rw7f6kNj33XHvd5V9YcI+bRAyNHom053SWsxjdEnhISjfI/3DeM=
=ETz/
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ea9e65ab-38a0-10a4-721e-58f0a200a2b0%40qubes-os.org.

Re: [qubes-users] SWAPGS Side Channel Attack

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2019-09-09 9:45 AM, Simon Gaiser wrote:
> [Now with Inline-PGP such that google group doesn't break the signature]
> 
> sergei.puti...@gmail.com:
>> Is Qubes affected by the SWAPGS attack?
> 
> From the Bitdefender "white paper" [1] (They reported this vuln.):
> 
> "A quick analysis of the Hyper-V kernel and of the Xen hypervisor kernel
> revealed that the SWAPGS instruction is not used, so exploitation is
> impossible."
> 
> [1]: 
> https://businessresources.bitdefender.com/hubfs/noindex/Bitdefender-WhitePaper-SWAPGS.pdf
> 
>> I haven’t found a statement or Security Advisory from Xen. But it
>> seems Xen still hasn’t even fixed the original Spectre v1 yet:
>> https://xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
>> At the time of original Spectre, v1 was deemed very hard to exploit on
>> Xen, but new variants of v1 like v1.1 and SWAPGS may invalidate that
>> hypothesis.
> 
> For Spectre variant 1 my understanding is that they are not aware of a
> exploitable code path in Xen. But they are working on hardening. For
> example grep the commit log for array_index_nospec or see [2] for an
> arbitrary example where they discuss this during review.
> 
> In the long run I hope there will be some compiler assisted technique
> instead of manual review, which likely misses cases. But something like
> this is not in place currently. See [3] for a description of the
> non-public gcc plugin from grsecurity which implements this approach.
> 
> [2]: 
> https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00982.html
> [3]: https://grsecurity.net/respectre_announce.php
> 
> Simon
> 

Thanks for the informative reply, Simon!

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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl13IJgACgkQ203TvDlQ
MDDHYw/+KbvGX2gn65Nx331LlnJmc2CgSFXA3t6B53tqomDtGsXY+YK6jRqMXYgW
J1END4kYleHw4zF/Qs2VhGmO0JvRFoASpMFGHJWyavMFzWz0PbStvnYAkJrjm9ay
eZC91/jdbGgw/5ssyS1wtyD74YAc3vKMwTtmLLztrXfDv8v1V48vCKOcH44K2z/h
MzcV1yoqw5zPus4ycDwdudBIwjaNT4+fnMymSJ6+wDjCAkRWi+7eWqVE8WHzIXMu
tR3hC+mXWU2Qzmq77PbhTXpq1lp275i4tABEOcXM4lhtopl5HP6B6YLkkIjWqYNv
sJsTDFgM7S1IqwFp1ypL9xzGHkqEns5zYmaNklGxJ8Oh6QJlZYbrZ6Zjciq3w+s8
DDipLpmXgT8TFKGN4mmW7U0UjK3a9jeBBxFYRZxRJNFd6h1WkVTm4V/MBKzW7yp+
yUooSSprIxv6mEMS3WVV7l9bQbPLdbqmbel9GLqyali+0t4yEftQME7tk9OWvbuP
caUop7Ock1rDtnnlasTYkNWX9hH0sXHAdjcfQlcKi96+w6eg4R9kvrOyLU3rxWHF
EmWQv+rLNSd9MKyL8aCb2dIVV6nk/n6yqlQ0AeiUhNrjIbnkja7E0lPZAWdAwWgY
OCCHMZmjebseram7hcElk6CJtO6I5yPz5uNbKterNFOX5eGf2X4=
=WvGu
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/87020902-5091-40c7-41a4-8ba7633a44c2%40qubes-os.org.

Re: [qubes-users] Re: using static dispVM for sys-net

[rec wins]

On 9/9/19 11:32 AM, Sven Semmler wrote:
> On 8/17/19 3:55 PM, rec wins wrote:
>> how to store the wifi credentials in custom-dvm-template ?
> assuming you created sys-net using the a dvm template named
> dvm-fed-30-min and know the PCI identifier of your wireless interface
> (the one you assigned to sys-net)
> 
> 
> 1) qvm-shutdown --all --wait
> 2) qvm-prefs dvm-fed-30-min virt_mode hvm
> 3) qvm-prefs dvm-fed-30-min provides_network true
> 4) qvm-pci attach dvm-fed-30-min --persistent dom0:
> 5) qvm-start dvm-fed-30-min
> 6) once started use the NetworkManager in the tray to enter your WiFi
> credentials
> 7) qvm-shutdown --wait dvm-fed-30-min
> 8) qvm-pci detach dvm-fed-30-min dom0:
> 9) qvm-prefs dvm-fed-30-min provides_network false
> 10) qvm-prefs dvm-fed-30-min virt_mode pvh
> 11) start sys-net
> 
> /Sven
> 


actually I stored them in the main Fedora Template that the
custom-dvm-template  was based on

found the proper file and format from another connection somewhere

perhaps not secure, my method, but seems to work


ty for the steps on your method , I know someone else had been also asking

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e8ba37d2-3a9d-55a0-c601-bcd1923938e1%40riseup.net.

Re: [qubes-users] Re: using static dispVM for sys-net

[Sven Semmler]

On 8/17/19 3:55 PM, rec wins wrote:
> how to store the wifi credentials in custom-dvm-template ?
assuming you created sys-net using the a dvm template named
dvm-fed-30-min and know the PCI identifier of your wireless interface
(the one you assigned to sys-net)


1) qvm-shutdown --all --wait
2) qvm-prefs dvm-fed-30-min virt_mode hvm
3) qvm-prefs dvm-fed-30-min provides_network true
4) qvm-pci attach dvm-fed-30-min --persistent dom0:
5) qvm-start dvm-fed-30-min
6) once started use the NetworkManager in the tray to enter your WiFi
credentials
7) qvm-shutdown --wait dvm-fed-30-min
8) qvm-pci detach dvm-fed-30-min dom0:
9) qvm-prefs dvm-fed-30-min provides_network false
10) qvm-prefs dvm-fed-30-min virt_mode pvh
11) start sys-net

/Sven

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/deb437f3-7595-bb7f-e912-61d7af9ca91f%40SvenSemmler.org.


signature.asc
Description: OpenPGP digital signature

[qubes-users] Re: Behaviour of qvm-open-in-(d)vm

[Sven Semmler]

On 8/16/19 8:37 AM, Phil Knüfer wrote:
> qvm-open-in-vm still works like the older tools, that is, it takes two
> parameters (VM name + file name or URL to be opened), but then still
> shows the GUI prompt where the user needs to pick the destination VM.

This depends on the contents of your /etc/qubes-rpc/qubes.OpenURL

See https://www.qubes-os.org/doc/disposablevm/

/Sven

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cddfb295-3bd0-822e-fec8-dca5f3080a78%40SvenSemmler.org.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] How to change date and time format in Thunderbird

[Sven Semmler]

On 8/15/19 11:25 AM, galt...@gmail.com wrote:
> I googled and found that thunderbird gets its setting from the OS.

You want to google for the command line commands: locale and localectl
as well as /etc/locale.conf

/Sven

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b8e65b89-e7dc-874a-b482-27eb0155edcc%40SvenSemmler.org.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Trouble building RTL8821CE WiFi drivers

['awokd' via qubes-users]

muhammad19238...@gmail.com:
> I am trying to build these drivers on a debian-9 template based vm(my own 
> sys-net, I rather debian than fedora, and I have already tried and got the 
> same result on fedora). The drivers are found here 
> https://github.com/tomaspinho/rtl8821ce . I installed these easily on other 
> Debian systems and had no such issue. If i try build with the 
> DKMS-install.sh provided, I get this error: pastebin.com/aX9kmZg3 and in 
> the make.log, pastebin.com/XiFfzGWG . If i try build with make, I get this 
> error: pastebin.com/w1QDw5w6 . I looked around and found some related 
> issues on github but lacked solutions at least that I saw, but I need these 
> drivers urgently so apologies if this is common knowledge.
> 
https://www.mail-archive.com/qubes-users@googlegroups.com/msg27754.html

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c4245d52-3428-7861-69a9-ee9b3e09538b%40danwin1210.me.

[qubes-users] Trouble building RTL8821CE WiFi drivers

[muhammad19238219]

I am trying to build these drivers on a debian-9 template based vm(my own 
sys-net, I rather debian than fedora, and I have already tried and got the 
same result on fedora). The drivers are found here 
https://github.com/tomaspinho/rtl8821ce . I installed these easily on other 
Debian systems and had no such issue. If i try build with the 
DKMS-install.sh provided, I get this error: pastebin.com/aX9kmZg3 and in 
the make.log, pastebin.com/XiFfzGWG . If i try build with make, I get this 
error: pastebin.com/w1QDw5w6 . I looked around and found some related 
issues on github but lacked solutions at least that I saw, but I need these 
drivers urgently so apologies if this is common knowledge.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/566468b3-4638-42ab-9639-3bce325ecca2%40googlegroups.com.

Re: [qubes-users] SWAPGS Side Channel Attack

[Simon Gaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

[Now with Inline-PGP such that google group doesn't break the signature]

sergei.puti...@gmail.com:
> Is Qubes affected by the SWAPGS attack?

- From the Bitdefender "white paper" [1] (They reported this vuln.):

"A quick analysis of the Hyper-V kernel and of the Xen hypervisor kernel
revealed that the SWAPGS instruction is not used, so exploitation is
impossible."

[1]: 
https://businessresources.bitdefender.com/hubfs/noindex/Bitdefender-WhitePaper-SWAPGS.pdf

> I haven’t found a statement or Security Advisory from Xen. But it
> seems Xen still hasn’t even fixed the original Spectre v1 yet: 
> https://xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
> At the time of original Spectre, v1 was deemed very hard to exploit on
> Xen, but new variants of v1 like v1.1 and SWAPGS may invalidate that
> hypothesis.

For Spectre variant 1 my understanding is that they are not aware of a
exploitable code path in Xen. But they are working on hardening. For
example grep the commit log for array_index_nospec or see [2] for an
arbitrary example where they discuss this during review.

In the long run I hope there will be some compiler assisted technique
instead of manual review, which likely misses cases. But something like
this is not in place currently. See [3] for a description of the
non-public gcc plugin from grsecurity which implements this approach.

[2]: https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00982.html
[3]: https://grsecurity.net/respectre_announce.php

Simon


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAl12ZYgACgkQkO9xfO/x
ly8fVhAAytcPEKgHfchZFSx8b4q0yGijnM2PVS5z7zbYchQtZ3xkgf+6ZxGwauay
buD22CE2B+ZMWhgnS3VW5fB28dHQAQeU2BO51zcP8EatlvkVVC8lRa1jzuPKsON5
q2YGarwUott3/tcjL8iOsU9FPfmHbV2mu/hFzt2ZpgqWBGghmtvjpeNzXb+XM1LV
ohQoMIS+bRr4IjXpOUlsWCyLF1grpKEB6EfMSCC/o14A8iZqvSMo23nhF0adQwcp
5qZn7Lg572YcSJI7YxjT5D+6f4tIRS3V4yjYbIw2catOz6CozGQfYnX766jPKFFp
CnESPKs5EMk7+ayDaOjAvx79/jNjR3aBlajbyg5gkXc5qTj8Zm7MeTy8qnJ4zv4I
FrnBcFu1l1/wPWzYvk53ES90XnuRixE2MMHQf/NW5HId6Gn4pWUBkmL5pivoEG5L
1tWT/bAHpnQ50m3UsmP+SJ0K3+mqqoCJgsRh/zcwhtlgABCJl7sst8uCRNsgU9rX
YGMVR1kjS2EI8BWwGwGK0wEkKVkmUmNGwRJUTgwA7dgpBEE/tZ6letKM0mF8F40b
U3SGdYPrM/OAHlMJijq5MpKXMiKOFemRg4RVDEV3fK8FEEhzN10K3l2TP6PjxaW+
pA/Du6CKFOvXG2pyPrzUwjhdrp4RuQKwdvtHdkdi0UHQEs1mekY=
=7n0V
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e4c345f9-7645-2853-5e12-2b70d8f823f9%40invisiblethingslab.com.

Re: [qubes-users] SWAPGS Side Channel Attack

[Simon Gaiser]

sergei.puti...@gmail.com:
> Is Qubes affected by the SWAPGS attack?

>From the Bitdefender "white paper" [1] (They reported this vuln.):

"A quick analysis of the Hyper-V kernel and of the Xen hypervisor kernel
revealed that the SWAPGS instruction is not used, so exploitation is
impossible."

[1]: 
https://businessresources.bitdefender.com/hubfs/noindex/Bitdefender-WhitePaper-SWAPGS.pdf

> I haven’t found a statement or Security Advisory from Xen. But it
> seems Xen still hasn’t even fixed the original Spectre v1 yet: 
> https://xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
> At the time of original Spectre, v1 was deemed very hard to exploit on
> Xen, but new variants of v1 like v1.1 and SWAPGS may invalidate that
> hypothesis.

For Spectre variant 1 my understanding is that they are not aware of a
exploitable code path in Xen. But they are working on hardening. For
example grep the commit log for array_index_nospec or see [2] for an
arbitrary example where they discuss this during review.

In the long run I hope there will be some compiler assisted technique
instead of manual review, which likely misses cases. But something like
this is not in place currently. See [3] for a description of the
non-public gcc plugin from grsecurity which implements this approach.

[2]: https://lists.xenproject.org/archives/html/xen-devel/2018-07/msg00982.html
[3]: https://grsecurity.net/respectre_announce.php

Simon

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/06688f5c-e93d-3089-bbd5-33f9f8d7c336%40invisiblethingslab.com.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

[donoban]

On 9/9/19 1:31 PM, 'Heinrich Ulbricht' via qubes-users wrote:
> Above sole change to restore.py did solve the problem for me. Note that
> I tweaked the parameters a bit to give it more time. With this change
> the initial sleep duration was about 2 seconds. The temp directory
> slowly filled up and the sleep duration increased to about 11 seconds
> and stayed there, keeping everything in balance. Looking at the task
> manager I saw the checkpoint was hit about every 5 seconds. That's an 11
> second sleep every 5 seconds.
> ...
Great, nice to know.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9aff9bb0-c645-7281-805f-b3c96cbe0aad%40riseup.net.

Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

[Pablo Di Noto]

Hello,


> > It is clear that despite ticking the check boxes from the auditor point 
> of 
> > view with this idea, I would be willingly violating the internal rules 
> they 
> > have setup, and maybe risking the company certification in case of a 
> deeper 
> > review after an incident. Despite the overall lack of consideration for 
> > specific (and arguably better) security setups, doing this hack will 
> have 
> > me connecting to our internal networks and avoiding the endpoint 
> security 
> > scan the applications really using them. 
>
> The auditors might be satisfied if you are able to explain how Qubes 
> itself is a compensating control on the limited file scanning ability of 
> your AV, but doing so could be a challenge. 
>

Yes, it is challenge in many levels. Been thru five companies during their 
PCIDSS certification, for instance, and the way the whole business work is 
to promote the usage of know things, despite their real security value.

To give and rough idea, a relatively patched Windows machine will always be 
seen as a more compliant endpoint device that using Chromebook.
If Google is not yet able to get that into the "nobody got fired by" circle 
despite having a huge financial backing and a decent usage track , imagine 
the relatively obscure OS we love.

On the bright side, all auditors I spoke to are either a) aware of Qubes as 
state of the art in secure endpoint (given a decently trained user, that 
is) or b) Amazed when told and show how it works.
 

> For a really ugly hack, you might be able to readonly loop mount -pool00 
> (and -root?) into a network connected AppVM running your AV, so it could 
> scan them as large files. This breaks the Qubes security model pretty 
> thoroughly, but would make auditors happy I guess. You'd at least have 
> the benefit of continuing to use Qubes.


I soon have the annual company meeting, and may find a suitable stop to 
discuss this with my managers.
Will be an interesting talk, for sure.

Thanks for the idea, will check how S1 deals with images and raw 
filesystems.

Cheers,
///Pablo

 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/42eda180-f125-4ea5-a2ed-e1440db2786d%40googlegroups.com.

Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

['awokd' via qubes-users]

Pablo Di Noto:

> It is clear that despite ticking the check boxes from the auditor point of 
> view with this idea, I would be willingly violating the internal rules they 
> have setup, and maybe risking the company certification in case of a deeper 
> review after an incident. Despite the overall lack of consideration for 
> specific (and arguably better) security setups, doing this hack will have 
> me connecting to our internal networks and avoiding the endpoint security 
> scan the applications really using them.

The auditors might be satisfied if you are able to explain how Qubes
itself is a compensating control on the limited file scanning ability of
your AV, but doing so could be a challenge.

For a really ugly hack, you might be able to readonly loop mount -pool00
(and -root?) into a network connected AppVM running your AV, so it could
scan them as large files. This breaks the Qubes security model pretty
thoroughly, but would make auditors happy I guess. You'd at least have
the benefit of continuing to use Qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6cb2cb03-6b0f-c966-8a87-590eb1773aac%40danwin1210.me.

Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

[Pablo Di Noto]

Hello,
 

> > > I think you may be overstating the problem of running anti-virus on 
> > > Qubes. If you could find an AV that updates its virus definitions via 
> > > signed RPMs, then it can be made to work without a lot of effort. 
> > > 
> > 
> > The issue in this case is two fold: The designated ~antivius~ endpoint 
> > protection solution (Sentinel One in our case) offers no support for 
> > Fedora, specially an oldish one like F25. Also, the whole compliance 
> point 
> > is to have the endpoint report frequently its compliance status, which 
> dom0 
> > would not do. 
> > And, of course, this solution has its own update mechanism, so it cannot 
> be 
> > made work with the RPM proxy Qubes offers. 
>
> 1) Create a standalone VM called sys-net-work based on Debian. 
> 2) Install your AV there. 
> 3) When you are at work boot that one and map your firewall to it instead 
> of 
> the standard sys-net. 
>
> This is equivalent to a non hypervisor OS as sys-net is the root of the 
> system and through it flows all network traffic. 
>
> This should check your management's tick box as sentinel will report back 
> that it is running. 
>
> And it should meet your needs as you can stay on qubes OS and additionally 
> remap to sys-net when you are home so you need not run their closed source 
> "security" software when you are not obliged to. 
>
>
That is, indeed, a clever hack.
I did not think about installing the endpoint security software on a 
`sys-net` role VM.

Fortunately my organization is ran by very bright technical people, with 
whom I interact everyday. 
It is clear that despite ticking the check boxes from the auditor point of 
view with this idea, I would be willingly violating the internal rules they 
have setup, and maybe risking the company certification in case of a deeper 
review after an incident. Despite the overall lack of consideration for 
specific (and arguably better) security setups, doing this hack will have 
me connecting to our internal networks and avoiding the endpoint security 
scan the applications really using them.

Thanks a lot for you idea!
Regards,
///Pablo

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68612fc1-99b2-4924-bca0-5186942b8d36%40googlegroups.com.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

['Heinrich Ulbricht' via qubes-users]

>
>
>
> THIS is the place to insert the checkpoint operation for the un-tar (line 
> 913ff in restore.py 
> 
> ):
>
> tar1_command = ['tar',
> '-ixv',
> '--occurrence=1',
> '--checkpoint=2',
> '--checkpoint-action=exec=\'sleep "$(stat -f --format="(((%b-%a)/%b))*120" 
> /var/tmp | bc -l)"\'',
> '-C', self.tmpdir] + filelist
>
> This seems to be a non-interruptable tar operation that is pushing 
> thousands of chunk files into the temp location with the other processes 
> having no chance to process them in time. I'll follow up with details.
>


Above sole change to restore.py did solve the problem for me. Note that I 
tweaked the parameters a bit to give it more time. With this change the 
initial sleep duration was about 2 seconds. The temp directory slowly 
filled up and the sleep duration increased to about 11 seconds and stayed 
there, keeping everything in balance. Looking at the task manager I saw the 
checkpoint was hit about every 5 seconds. That's an 11 second sleep every 5 
seconds.

To summarize this is what I did to restore:
* copy the 700 GB backup file to a new temporary AppVM in storage pool *1 *(I 
had to free some space there...) [HDD]
* mount the private storage of this new AppVM to dom0
* modify *restore.py* as described above (added checkpoint, left */var/temp* 
unchanged as temporary location which is on a SSD)
* set the default storage pool to storage pool *2 *[HDD]
* used the "Restore Backup" UI to select the backup file
* start the restore operation and wait until it successfully finished

There were other proposed solutions I did not try:
* dd the old HDD content to a new HDD, make the new Qubes installation 
recognize it
* LVM mirroring
* use Chris' pre-release script
* slow down qfile-dom0-unpacker (<- this solution came in as slowing down 
the tar process was already working)
* attach USB drive to dom0 and restore from there (<- I choose to not 
attach a USB drive)

I would've tried those next had the restore operation with modified 
*restore.py* failed. In my view the out-of-the-box solution has the lowest 
security and maintenance risks.

Thank you to all who helped me getting this done! And good to hear there is 
currently work being done to make this smoother in the future (by Chris & 
Marek - should you synchronize?).

Note: While fiddling around I discovered that the restore operation cannot 
be canceled: https://github.com/QubesOS/qubes-issues/issues/5304

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0a61520e-24a7-4dfa-84c0-135873103b5a%40googlegroups.com.

Re: [qubes-users] Cant connect hard drive to appvms?

[donoban]

On 9/6/19 5:32 PM, Stumpy wrote:
> I am hoping to copy things from the external usb hard drive (sata drive
> in a usb dock).
> 
> When i connect my external usb drive to the computer i get the popup
> that its recognized, both sdc and sdc1.
> 
> When i attach it via qubes devices it doesnt say or give any errors.
> 
> When i try to access it on the appvm that i connect it to it does not
> show up in nautilus like say my flash usb devices, nor does it show as
> being mounted when i check for mounted devs via the terminal
> 
> yet.
> 
> On dom0 i can see the drive, i can access the drive, and modify the
> contents but of course this is not a good idea.
> 
> I have not tried qvm-usb, qvm-device, or qvm-block as i am not familar
> with them but at this point am open to trying them (any docs on how to
> use them?)
> 

Could you check 'sudo dmesg' on the AppVM? If you see something like
'/dev/xvdi1' you could try mounting it with:
'sudo mount /dev/xvdi1 /some/place'

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b9691ef0-deaf-d592-4baf-c5865c476ecf%40riseup.net.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

['Heinrich Ulbricht' via qubes-users]

On Saturday, September 7, 2019 at 10:54:34 PM UTC+2, Heinrich Ulbricht 
wrote:
>
>
>> Can anybody suggest a modification (or hack, however dirty - it's meant 
>> to be temporary) to restore.py so it won't need 700 GB of additional 
>> temporary storage when I try to restore my 700 GB AppVM?
>>
>>
> The best bet I currently have it applying the "sleep trick" (see here 
> ) 
> to line 598ff 
> 
>  
> in *restore.py*.
>
> So this:
> elif inner_name in self.handlers:
> tar2_cmdline = ['tar',
> '-%svvO' % ("t" if self.verify_only else "x"),
> inner_name]
> redirect_stdout = subprocess.PIPE
>
> Would become something like this:
> elif inner_name in self.handlers:
> tar2_cmdline = ['tar',
> '-%svvO' % ("t" if self.verify_only else "x"),
> '--checkpoint=2',
> '--checkpoint-action=exec=\'sleep "$(stat -f --format="(((%b-%a)/%b)^5)*30" 
> /var/tmp | bc -l)"\'',
> inner_name]
> redirect_stdout = subprocess.PIPE
>
>
> Too naive?
>


Quick update on how it is going: I' got the restore operation in an 
equilibrium now.

THIS is the place to insert the checkpoint operation for the un-tar (line 
913ff in restore.py 

):

tar1_command = ['tar',
'-ixv',
'--occurrence=1',
'--checkpoint=2',
'--checkpoint-action=exec=\'sleep "$(stat -f --format="(((%b-%a)/%b)^5)*30" 
/var/tmp | bc -l)"\'',
'-C', self.tmpdir] + filelist

This seems to be a non-interruptable tar operation that is pushing 
thousands of chunk files into the temp location with the other processes 
having no chance to process them in time. I'll follow up with details.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7c409720-bed9-4198-823a-d1f081d91ed2%40googlegroups.com.