from:"David Hobach"

Re: [qubes-users] 4.2 issue with pam_sss.so

2024-02-25 Thread David Hobach


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

--
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/de7bbcbf-e17b-4c36-bd4b-07c53b87d81d%40hackingthe.net.


OpenPGP_0x08DEA51AE90C3780.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] DNS -- good practice ?

2023-03-18 Thread David Hobach


Hi Bernhard,

nice to see you're still around. :-)
I hadn't seen you active for a long time, probably I just don't know your nick 
on the forum.


And I ignore if TOR does use "cross checking requests" to detect
manipulation? The question of " best practice " seems non-trivial to me.
Setting up a DNS qube seems a good idea as such, but what kind of
software can trustworthily be run on such a qube??


Personally I use unbound as recursive DNS resolver, but I guess everyone may 
have different trust choices. Anyway that's not specific to Qubes OS.

I also use systemd-resolved in firewall VMs for caching [1].

[1] https://github.com/3hhh/qubes-dns

Best Regards
David


--
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/7723207e-1df1-3542-512c-3cba1c61eeb3%40hackingthe.net.


OpenPGP_0x08DEA51AE90C3780.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] T530 vs T430

2023-01-09 Thread David Hobach


Yes.

--
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/615a-2bc1-7f59-f731-e17a26a4b74d%40hackingthe.net.


OpenPGP_0x08DEA51AE90C3780.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [qubes-users] Qube-Firewall: How to handle changing IPs?

2022-08-11 Thread David Hobach


I mentioned DNS pinning in the very end and posted a working solution there as 
well.
I personally use it since about back then.

--
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/f99c46ba-09d2-f811-80be-63530900943c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] qubes update -- how to hold an old kernel ??

2022-08-06 Thread David Hobach


On 8/5/22 17:00, Peter Palensky wrote:

Update: I can use newer kernels if I remove device "Realtek Semiconductor
Co., Ltd. RTS525A PCI Express Card Reader" from sys-usb VM.
If it _is_ attached to that VM, the entire computer crashes upon sys-usb
start (when newer kernels are in use, it is fine with [very] old ones).

So I guess not having the card reader is my solution towards upgrading to
4.1.1


Hm interesting. That's quite similar to my experience [1].

Maybe some Xen code wrt attaching Express Card Readers broke?
Last somewhat good kernel for me was 5.10.109-1.

[1] https://github.com/QubesOS/qubes-issues/issues/7637

--
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/611befb7-6eb1-db83-be55-fbe84d7a441c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qube-Firewall: How to handle changing IPs?

2022-07-29 Thread David Hobach


See [1]. It happens less often than one might think though.

[1] https://github.com/QubesOS/qubes-issues/issues/5225

--
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/46b3ee63-e024-43f7-9a87-8b11decc0d76%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] dvm considerably slower on R4.1

2022-07-23 Thread David Hobach


You can see your pool driver by executing `qvm-pool`.

And the latest version of my scripts will always be available at [1].

Btw somehow one gets used to the worse performance after a while...

[1] https://github.com/3hhh/qubes-performance

Mine currently looks like this:

Qubes release 4.1 (R4.1)
dom0 kernel: 5.10.109-1.fc32.qubes.x86_64
dom0 Xen: 4.14.5
VM kernel: 5.15.52-1.fc32

Xen:
  qrexec startup: 240 ms
  Qubes DB: 8800 ms
  VM handover: 8901 ms
Linux:
  kernel: 4480 ms
  system: 4298 ms
  user: 178 ms
  system critical-chain:
multi-user.target @4.298s
└─qubes-qrexec-agent.service @4.164s +133ms
  └─systemd-user-sessions.service @4.102s +31ms
└─network.target @4.092s
  └─qubes-network-uplink.service @2.638s +1.447s
└─basic.target @2.544s
  └─sockets.target @2.544s
└─dbus.socket @2.542s
  └─sysinit.target @2.531s
└─systemd-update-utmp.service @2.482s +47ms
  └─systemd-tmpfiles-setup.service @2.349s +122ms
└─local-fs.target @2.317s
  └─run-user-1000.mount @4.773s
└─local-fs-pre.target @1.427s
  └─systemd-tmpfiles-setup-dev.service @1.150s 
+276ms
└─systemd-sysusers.service @1.090s +58ms
  └─systemd-remount-fs.service @1.006s +80ms
└─systemd-fsck-root.service @771ms +233ms
  └─systemd-journald.socket @572ms
└─-.mount @519ms
  └─-.slice @519ms
  qrexec service critical-chain:
qubes-qrexec-agent.service +133ms
└─systemd-user-sessions.service @4.102s +31ms
  └─network.target @4.092s
└─qubes-network-uplink.service @2.638s +1.447s
  └─basic.target @2.544s
└─sockets.target @2.544s
  └─dbus.socket @2.542s
└─sysinit.target @2.531s
  └─systemd-update-utmp.service @2.482s +47ms
└─systemd-tmpfiles-setup.service @2.349s +122ms
  └─local-fs.target @2.317s
└─run-user-1000.mount @4.773s
  └─local-fs-pre.target @1.427s
└─systemd-tmpfiles-setup-dev.service @1.150s +276ms
  └─systemd-sysusers.service @1.090s +58ms
└─systemd-remount-fs.service @1.006s +80ms
  └─systemd-fsck-root.service @771ms +233ms
└─systemd-journald.socket @572ms
  └─-.mount @519ms
└─-.slice @519ms
  qubes.GetDate: n/a
  qubes.WindowIconUpdater: n/a
  qrexec service: 4102 ms
qrexec (1st run):
  exec time: 4602 ms (depends on clock sync)
  return: 5479 ms
qrexec (2nd run):
  exec time: -105 ms (depends on clock sync)
  return: 782 ms
Overall: 23202 ms (excl. 2nd qrexec run)

--
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/640be919-fa6e-b3b9-350f-012fe0f6549e%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] dvm considerably slower on R4.1

2022-07-22 Thread David Hobach


There can be multiple reasons for a slower 4.1 experience. Known ones are:

1. CPU runs at ~800 MHz or so [1]
2. You're a file pool user. File pools were serialized in 4.1, likely dropping 
their performance by ~30-50%. [2]
3. Possibly further issues in 4.1 [2].

[1] https://github.com/QubesOS/qubes-issues/issues/4604
[2] https://github.com/QubesOS/qubes-issues/issues/7075

Anyway it seems that just a few users are affected. Others report 8s VM startup 
performance or less (see forum).

--
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/a0253a4b-57bf-cbb0-0146-d67c962c48e8%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Strategy Question: salt & installation of 3rd party software from web scraped URL - impossible in no-web templates

2022-04-06 Thread David Hobach


You did not, perchance, find a way to run the darn `setupwfc` script
without user interaction/using the defaults?


No, I didn't salt the home install. However usually you can emulate user input via echo 
"y"$'\n'"n" | someprog.
Otherwise there's also programs for that (I've never tried them).

--
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/b42301f7-96fd-9ff6-f3a1-bc66361bc72c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Strategy Question: salt & installation of 3rd party software from web scraped URL - impossible in no-web templates

2022-04-05 Thread David Hobach


A related question: howto transfer a binary file (like the citrix
tarball) to dom0 for integration into the salt setup?

the `qvm-run` and `cat`-based version in the docs does not work in this
case.


Just pack it into one *.tar.gz and then use the qvm-run cat commands to 
transfer it from the source VM to dom0. It works with any file, just not with 
directories - so you need to pack those.

--
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/6dd27483-358f-3c64-3bfc-1f85f2a07382%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Strategy Question: salt & installation of 3rd party software from web scraped URL - impossible in no-web templates

2022-04-05 Thread David Hobach


And the last time I tried Citrix on Qubes, I just installed it to the home 
directory (there was a tarball for download IIRC).

--
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/f8568943-5684-6278-13e3-0bca97cdc7b8%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Strategy Question: salt & installation of 3rd party software from web scraped URL - impossible in no-web templates

2022-04-05 Thread David Hobach


How would you go about this? Just manual downloading the rpm and
installing it into the template does the trick, but I'd vastly prefer a
salty solution.


I tend to download it once, store it with my salt stuff and install it via salt.
This also avoids untrusted download issues / limits them to the first download 
only.

--
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/50998134-2afc-6afe-da43-7b29c47f57f1%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] xrandr often coredumps

2022-01-13 Thread David Hobach


This usually is your screensaver failing to activate after an idle timeout.

It was mentioned on the other forum a few times already.

Not sure whether it's a Qubes bug, probably more a xrandr bug which affects the 
security of Qubes users.

--
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/24f730e4-4635-40ef-3312-cf25a641c7c1%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Default firewall configuration for dns/icmp of VMs with restricted access

2021-12-20 Thread David Hobach


Btw I still consider this hideous firewall GUI an anti-feature and would 
wholeheartedly support anyone complaining about it at qubes-issues.

--
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/724c59af-f79c-5da8-54b8-cacfd2737ae9%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] sys-net dispVM forgetting wifi passwords

2021-12-03 Thread David Hobach


On 12/2/21 8:35 AM, 'Rune Philosof' via qubes-users wrote:

I have installed 4.1rc2 and chose a disposable sys-net, because I could
think of a reason not to.
But now that I have to type in the wifi password again and again, I know a
reason to not choose dispVM for sys-net.


Use a dedicated template for sys-net, e.g. sys-net-dvm and put the wifi 
password there.

File to modify is /rw/config/NM-system-connections/[wifi].nmconnection. 
Actually you can logon once and copy that file over to your template.

Those with salt do it fully automated.

--
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/5b42ab05-110b-ebd4-f8d3-3f19d5055d4c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Disposable VMs starting with a QubesIncoming folder

2021-05-01 Thread David Hobach


On 5/1/21 11:13 AM, TheGardner wrote:

Since several days all my disposable VMs starting with a QubesIncoming
folder (w/a personal folder and three files inside).
Guess I accidentially moved these files to whonix-
ws-15-dvm during a previous Move-to-vm command.

Question now is: how can someone remove these files and clear the -dvm VM
again? Is this somethings to be done in dom0?


Just start the template VM and remove the ~/QubesIncoming 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/78f9849a-4d61-7758-1543-8fc8a46a4f98%40hobach.de.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Recover data from 'private-cow.img'

2021-04-18 Thread David Hobach

On 4/17/21 11:03 PM, Stickstoff wrote:

Hello everyone,

I lost a somewhat important file from a software crash in an appvm.
Within the VM, I couldn't find a way to recover it. I copied the appvm
filesystem containers ('private.img', 'private-cow.img',
'private-cow.img.old').
As I understand it, 'private-cow.img' contains the old version of files
that were changed since last appvm startup.
However, '-cow.img' files contain no filesystem, but "binary patch"
data, thus can't be mounted or read directly or without their
corresponding'.img' files.
I found only little info online. Qubes documentation [1] says about
reverting template 'root-cow.img' changes:

1. Ensure that no other VMs uses this template.
2. Prepare snapshot device with root-cow.img.old instead of root-cow.img
(/etc/xen/scripts/block-snapshot prepare).
3. Replace snapshot device-mapper target with snapshot-merge, other
parameters (chunk size etc) remains untouched. Now kernel starts merging
changes stored in root-cow.img.old into root.img. d-m device can be used
normally (if needed).
4. Waits for merge completed: dmsetup status shows used snapshot blocks –
it should be equal to metadata size when completed.
5. Replace snapshot-merge d-m target back to snapshot.
6. Cleanup snapshot device (if nobody uses it at the moment).
7. Move root-cow.img.old to root-cow.img (overriding existing file).

I tried to apply these steps to 'private.img' and 'private-cow.img', but
already failed with the second step, where I couldn't really figure out
how to use the '/etc/xen/scripts/block-snapshot' script.

Is there any hope to recover an older version of a changed/deleted file
from 'private-cow.img'?
Can anyone give me a pointer how to access its content, aka "apply its
content as a patch to 'private.ig'"?

Use `qvm-volume revert` to go back to previous snapshots for a VM.

For the file pool you cited above there's just one previous revision available
though. It should indeed be in the files you mentioned, but the other doc is
somewhat unrelated.

If you start the VM, the old snaphot will be deleted, i.e. better create a
backup before applying your changes.

Thank you in advance,

Stickstoff

[1] https://www.qubes-os.org/doc/template-implementation/

--
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/4d244dad-3412-d1de-8604-0af23740dc8e%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Re: ANN: Qubes arbitrary network topology

2021-03-17 Thread David Hobach


On 3/16/21 5:26 PM, Manuel Amador (Rudd-O) wrote:

Hello, folks!  I'm here to share this:

https://github.com/Rudd-O/qubes-arbitrary-network-topology 


This software lets you turn your Qubes OS 4.0 machine into an arbitrary network 
topology host. It is ideal to create networks of interconnected VMs with 
arbitrary pathways between them, and minimal effort compared to manually 
setting everything up using xl attach in your dom0 as root.



This looks promising, thanks!

I hope you intend to upstream it in the end or at least go for the 
qubes-community packaging.

--
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/f90464f2-39dc-3de3-3c14-162410e49ebd%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Re: "Improvements in testing and building: GitLab CI and reproducible builds" by Marek Marczykowski-Górecki

2021-03-01 Thread David Hobach


This is good stuff.

Thanks to you guys and to Mozilla for funding it!

--
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/2bf0ce49-987f-732b-9143-daef62aeced0%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] What is the latest version of Qubes (on 23 February 2021)

2021-02-23 Thread David Hobach


On 2/23/21 12:58 PM, load...@gmail.com wrote:

*So could anybody tell me is this the latest version of Qubes OS or
something happened with my update process?*


The packages you mentioned are all pretty dated.

Actually I had a similar issue a few months back when I noticed that Qubes OS 
wasn't updating anymore.

I was using a non-standard update VM though. Going back to the standard update 
VM (sys-fw) fixed it for me.

I recall that there was a similar bug on github for updating over VPN or 
sys-whonix at the time, but I cannot find it anymore.

You might also want to try a different template for the update VM (e.g. Fedora, 
if you're running Debian).

--
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/3cf0ac68-2882-e6a7-81c8-29be3cefd3d8%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] customizing Firefox in disp-vms

2021-01-29 Thread David Hobach

On 1/29/21 7:27 PM, Sven Semmler wrote:

On 1/29/21 3:58 AM, Josefa Hays wrote:

I use dispvm's all the time (both Fedora and Debian dispvms). Thus, I
am quite annoyed to see varios "first run" issues every time i start Firefox in
a disp-vm. I would like to perform the following changes
in the template-vms, preferably from CLI, so I don't have to start
Firefox in the template:

You wouldn't do that in the actual template but in the appvm that serves as a
template for the dispvm:

fedora-32 -> dvm-online -> disp1234

So dvm-online would be the qube that has template_for_dispvms set to true.
Maybe that's what you meant by template, but then I don't see the issue with
running firefox for a moment here (it's the same like running it in any AppVM).
You could even remove the netvm from dvm-online while making those changes.

* disable "first run" wellcome tabs * change startpage
tohttps://duckduckgo.com * In Fedora-30 dispvm: disable the
bookmark-bar in the top

If for some reason you really don't want to run Firefox in your equivalent of
dvm-online, you could do all those things in an actual dispvm instance (i.e.
disp1234) and then move the resulting .mozilla config directory into dvm-online.

I've been poking around in ~/.mozilla/ files and configs, but so far
no luck. Anybody got this working who can share their configs? (Maybe
we could put a guide on in wiki/docs? I guess it is quite a common
"problem" for people that use disp-vm's on a regular basis?)

Both approaches mentioned above will work. I just run firefox in dvm-online but
don't go to any websites. Just make all the settings, plugins etc and then
delete the cache in settings.

You can also manage your settings inside the user.js in dvm-online without
using the GUI.

There's tons of doc and samples on the Internet, see github or e.g. [1].

[1] https://privacy-handbuch.de/download/moderat/user.js

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: wireguard anti leak

2021-01-18 Thread David Hobach

On 1/17/21 11:38 PM, evado...@gmail.com wrote:

Seems it works with rules below. Is it enough to prevent all leaks? Openvpn
has more rules or other rules only drop traffic from proxyvm? Should I
worry about this traffic? Is it the way to block it like openvpn solution
from docs do for wireguard? Thanks

iptables -I FORWARD -o eth0 -j DROP
iptables -I FORWARD -i eth0 -j DROP
ip6tables -I FORWARD -o eth0 -j DROP
ip6tables -I FORWARD -i eth0 -j DROP

воскресенье, 17 января 2021 г. в 21:48:37 UTC, evado...@gmail.com:

I'm successfully run wireguard now with new Fedora kernel. But have the
trouble with leak. Previous openvpn solution use specific qvpn group to
prevent leaks. What is about wireguard? How to setup everything to prevent
leaks if tunnel will down?
Thanks

Simply put a firewall VM in front of your VPN VM and only allow the target VPN
servers via qvm-firewall. Note that the GUI allows DNS and ICMP by default
IIRC, i.e. you'll have to use qvm-firewall directly to implement your rules.

This way you'll avoid messing with the Qubes firewall internals.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: High dom0 CPU usage by qubesd

2021-01-15 Thread David Hobach

Hi Vit,

* I have many VMs in my computer.
* I use i3 with qubes-i3status
* The script qubes-i3status calls command qvm-ls --no-spinner --raw-data
--fields NAME,FLAGS quite frequently.
* The command qvm-ls --no-spinner --raw-data --fields NAME,FLAGS seems to
cause high CPU load. Unfortunately, the process that shows the high CPU
usage is qubesd, not qvm-ls.

What can be improved:

a. Don't use qubes-i3status. Problem solved.
b. Optimize qvm-ls. Not sure how hard it is.

This issue is really old (back from at least 3.2) and caused by each qvm-ls
line relating to one request to qubesd. Actually it was even worse with 3.2.

It should improve with 4.1 though, see [1].

[1] https://github.com/QubesOS/qubes-issues/issues/3293

c. Optimize qubes-i3status. I am not sure about the ideal way of doing
that, but clearly running qvm-ls --no-spinner --raw-data --fields
NAME,FLAGS just to compute the number of running qubes is far from optimal.
One could add --running. And maybe it could have been written without
flags. The script just ignores VMs with the first flag being “0” (maybe in
order to ignore dom0) and the second flag being “r” (probably not needed
with --running).

Filtering might work in the meantime, yes.

BR
David

--
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/e8acbeda-199a-8e1f-1a94-caaa0b4bb120%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] New qubes private storage not LVM anymore

2021-01-11 Thread David Hobach


On 1/11/21 3:40 PM, the2nd wrote:


Hi all,

for some reason my Qubes OS does create new qubes with private storage on
pool "varlibqubes" instead of lvm. It was working before but i dont know
the reason why the behaviour changed.



Maybe you accidentally changed the default_pool setting?

Check `qubes-prefs`.

--
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/0b137915-ba68-35a6-798d-a10f087181d3%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Q: attaching a partition to a VM vs. attaching the whole disk

2021-01-03 Thread David Hobach


On 1/3/21 3:53 PM, unman wrote:

On Sat, Jan 02, 2021 at 06:18:52PM +0100, Ulrich Windl wrote:

Hi!

I have an effect I'm wondering about:
May USB stick has partitions on it, one being FAT having a KeePass DB in it.
When I attach that partition to a VM (eg. vault) and try to access the
partition, I see no mountable disk in the file manager (e.g. from
KeePassXC).
However when I attach the whole stick to the VM, I see all partitions being
offered to mount in the file manager under "Other locations".

Is this the way it should be? I'd like to attach only the partition needed,
but usability forces me to attach the whole stick...


You can mount the partition only on the command-line, maybe it's a UI issue by 
the file manager you use.

Possibly interesting for your use case: https://github.com/3hhh/qcrypt

--
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/e955dd98-09bf-0005-6ab4-2ed97d05d5b0%40hobach.de.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] wireless " intruder "

2021-01-03 Thread David Hobach


On 1/3/21 12:43 PM, haaber wrote:

In particular: How can I log packets while scannning?

If mirage died due to incoming packets, you should see the offensive payload 
with e.g. wireshark.
The attack couldn't be on a lower layer as that is handled by your wifi driver 
in sys-net only.

In companies triangulation tends to be used to find wifi attackers IIRC. So 
you're likely on the right path.

--
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/0297efff-db60-f231-5d36-5b7acb90e5a1%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] wireless " intruder "

2021-01-03 Thread David Hobach

On 1/3/21 12:43 PM, haaber wrote:

Hello, I have a intriguing problem, partially qubes-related. I have a
"intruder" in my wifi network. I have no idea how to physically localise
that offensive antenna, but that is not a qubes subject (if you have any
ideas, they are welcome!). Of course I can just change the SSID and pwd,
but this is not the whole point:

When I portscan the offensive object using nmap (all ports are
filtered.) it counter-fires and kills off my mirage-firewall! That is
fancy. The network structure is

sys-net - mirage-firewall -qubes-firewall - dispVM

and nmap runs in dispVM. I am quite surprised and willing to "play" a
bit with this enemy, but I would need some help. In particular: How can
I log packets while scannning? Is there a way to find out how/why the
mirage firewall (0.7) dies? That suggests a weakness which is relevant
to many of us! Cheers, Bernhard

Your firewalls might interfere with the nmap replies and thus everything is
shown as filtered.

Also the above network setup looks weird (why two firewalls in a chain?).

Maybe nmap causes the mirage death. That wouldn't be a good job by mirage
though and should be reported as bug to the dev.

Anyway I'd recommend doing nmap directly from sys-net or from a VM that is
directly connected to sys-net.

--
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/095226c5-a156-1afc-14be-987e966996ff%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Q: Kernel being used in VM

2020-12-21 Thread David Hobach


On 12/21/20 1:45 PM, Mike Keehan wrote:

On 12/21/20 12:23 AM, Ulrich Windl wrote:

Hi!

I wonder: What sense is in updating the kernel in a VM (e.g. fedora-32) when 
that kernel isn't used when booting the VM?



It's only for standalone VMs IIRC.
Uninstalling them shouldn't hurt if you don't use any standalone VM.


The VM's package manager can be told not to update specified packages,
if that is what you want.


--
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/4e65ac42-63ab-9e65-c7ef-d458927945fc%40hobach.de.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Using Qubes base Salt pillar in user_salt?

2020-12-16 Thread David Hobach


On 12/16/20 9:41 AM, Vasilis wrote:

When using the Salt user configuration located in '/srv/user_salt' what is the 
best way to use the Qubes specific pillars located (for this example) in 
'/srv/salt/_pillar'?


The below script should give you the idea how to do it:

#!/bin/bash
#
# Run the salt configuration of _this_ folder in dom0.
#
# Assumes that you have `user_[formulas|pillar|salt]` directories in _this_ 
folder.
#
# NOTE: If even `sudo qubesctl top.enabled` failed for you, you can try 
re-installing `qubes-mgmt-salt-* salt salt-minion`
#   (first via `sudo qubes-dom0-update`, then via `sudo dnf reinstall`.
#
# Useful info:
# - initially sync all modules etc: sudo qubesctl saltutil.sync_all saltenv=user
# - to enable a state (only needed for everything not in top.sls): sudo 
qubesctl top.enable tripleh.vms saltenv=user
# - to apply a state (set test=true for testing): sudo qubesctl --show-output 
state.apply saltenv=user
# - list enabled states: sudo qubesctl top.enabled saltenv=user
# - local salt doc: qubesctl sys.doc | less (details for e.g. archive: qubesctl 
sys.doc archive)
# - all available grains: sudo qubesctl --targets dom0 grains.items
# - show sls output after jinja: sudo qubesctl --show-output state.show_sls 
vm-install.vim saltenv=user
# - Logs: /var/log/qubes/mgmt-[target-vm].log
# - Further doc:
#   - https://github.com/unman/notes/tree/master/salt (also locally saved here; 
he always refers to the examples/ dir)
#   - https://www.qubes-os.org/doc/salt/
# - The qvm.[module] doc can be found in dom0 inside 
`/srv/salt/_modules/ext_module_qvm.py`.
#   (_Warning_: The `README.rst` appears outdated. --> Only the code has 
current information.)

set -e -o pipefail

#error [msg]
function error {
  local msg="$1"
  >&2 echo "ERROR: $msg"
  exit 1
}

[[ "$(whoami)" != "root" ]] && error "This script must be run as root."

#path of this directory (hopefully...)
SCRIPT_DIR="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"

#saltModSymlink [target]
function saltModSymlink {
  local target="$1"
  local tpath="/srv/user_salt/$target"
  rm -f "$tpath"
  ln -s "/srv/salt/$target" "$tpath"
}

#create user_ symlinks @/srv/ for the saltenv=user (explicitly configured by 
Qubes OS)
echo "Creating user_ symlinks in /srv/..."
for file in "$SCRIPT_DIR"/* ; do
  if [ -d "$file" ] && [[ "$file" == *"user_"* ]] ; then
target="/srv/${file##*/}"

#remove previous instances & update new
rm -f "$target"
ln -s "$file" "$target"
  fi
done

#create module symlinks
echo "Creating Qubes module symlinks..."
saltModSymlink "_grains"
saltModSymlink "_modules"
saltModSymlink "_pillar"
saltModSymlink "_states"
saltModSymlink "_utils"

#sync modules (we just added some via the symlinks above)
#echo "Syncing modules..."
#qubesctl saltutil.sync_all saltenv=user

#call
ret=0
if [ $# -gt 0 ] ; then
  echo "Calling qubesctl saltenv=user with your arguments..."$'\n'
  #e.g. state.show_top is quite useful to see what state is applied where 
(doesn't seem to work for anything != dom0)
  qubesctl --show-output "$@" saltenv=user || ret=$?
else
  echo "Using qubesctl to apply the top.sls state..."$'\n'
  #state.highstate respects the top file, state.sls ignores it (just targets 
anything mentioned as target)
  qubesctl --show-output --all state.highstate saltenv=user || ret=$?
fi

echo ""
echo "All done."
exit $ret


--
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/ae2e7903-1219-4dfb-335c-bd59c14c010a%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Unable to get VPN to ping out. Unable to set up ProxyVM as sys-vpn

2020-11-29 Thread David Hobach

On 11/29/20 12:09 PM, David Hobach wrote:

On 11/28/20 9:26 PM, setemera...@posteo.net wrote:

Documentation followed:
http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

Someone please help me, I'm fucking screaming here every time I try to do the
right thing following documentation or try to figure out why my own OS is
stopping me from doing basic shit.

Hmmm yes the official Qubes doc on VPN is still overcomplicating things a bit
too much and even lacking in some areas.

Here's a simple and probably even better way than the official doc:

1. Set up a network infrastructure such as:

your VPN client VM 1
sys-net -- sys-fw -- sys-vpn -- sys-fw-vpn --|
your VPN client VM 2 etc.

Use `qvm-prefs netvm` and `qvm-prefs provides_network` for that.

2. IMPORTANT: Configure your Qubes Os firewall to only allow traffic from
sys-vpn to your VPN provider.
I.e. `qvm-firewall sys-vpn --raw` should show something like
```
action=accept proto=tcp dst4=[VPN IP]/32 dstports=[port]-[port]
```
in the end. Use `qvm-firewall` and not the GUI as the GUI will allow e.g. DNS &
pings by default IIRC (you need to remove those GUI rules).

If you leave out this step or get it wrong, VPN leaks may be possible.
For testing purposes you could skip this step and implement it after step 3
though.

3. Inside sys-vpn at `/rw/config/rc.local` (autostart file) start your VPN
client, e.g. `openvpn` with whatever config you need.

P.S.: If DNS doesn't work after step 3, you might have to add the following
lines to `/rw/config/rc.local` inside `sys-vpn`:

#[your openvpn stuff here]
echo "nameserver [your DNS server]" > /etc/resolv.conf
/usr/lib/qubes/qubes-setup-dnat-to-ns

That's it. No messing with iptables et al required... ^^
(Actually there's one iptables rule that would improve security by 0,01%, but I
guess it's not really relevant to 99,9% of users.)

Maybe someone should update the official recommendations.

Thank you for taking the time to help me so far. Be well.

You too.

--
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/901294dd-50c1-9d44-9b1c-77219b67a806%40hackingthe.net.

--
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/36d97866-08ea-bc0c-487a-e77ff5e8608a%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Unable to get VPN to ping out. Unable to set up ProxyVM as sys-vpn

2020-11-29 Thread David Hobach

On 11/28/20 9:26 PM, setemera...@posteo.net wrote:

Documentation followed:
http://qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

Someone please help me, I'm fucking screaming here every time I try to do the
right thing following documentation or try to figure out why my own OS is
stopping me from doing basic shit.

Hmmm yes the official Qubes doc on VPN is still overcomplicating things a bit
too much and even lacking in some areas.

Here's a simple and probably even better way than the official doc:

1. Set up a network infrastructure such as:

your VPN client VM 1
sys-net -- sys-fw -- sys-vpn -- sys-fw-vpn --|
your VPN client VM 2 etc.

Use `qvm-prefs netvm` and `qvm-prefs provides_network` for that.

If you leave out this step or get it wrong, VPN leaks may be possible.
For testing purposes you could skip this step and implement it after step 3
though.

3. Inside sys-vpn at `/rw/config/rc.local` (autostart file) start your VPN
client, e.g. `openvpn` with whatever config you need.

That's it. No messing with iptables et al required... ^^
(Actually there's one iptables rule that would improve security by 0,01%, but I
guess it's not really relevant to 99,9% of users.)

Maybe someone should update the official recommendations.

Thank you for taking the time to help me so far. Be well.

You too.

--
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/901294dd-50c1-9d44-9b1c-77219b67a806%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes Awesome WM - Gaps not working

2020-11-25 Thread David Hobach



On 11/25/20 12:15 PM, Hayden Llowarch wrote:

Hi All,
Has anyone got gaps work on the awesome window manager?

I have tried
beautiful.useless_gaps = 5
In the rc.lua file

And
Themes.useless_gaps = 5
In the themes.lua file

Everything I’ve read says this should work, but its not?


It's probably an awesome 4 feature [1]. The dom0 version is still 3.5.

[1] https://github.com/awesomeWM/awesome/pull/279

--
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/953f34dd-3c37-8afb-3ed5-451bac8ef06e%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] screenlock keycombinations

2020-10-27 Thread David Hobach

On 10/27/20 2:37 PM, evado...@gmail.com wrote:

Qubes by default protected from this key combinations?

Backdoor #1: Ctrl-Alt-Backspace.

This keystroke kills the X server, and on some systems, leaves you at a
text console. If the user launched X11 manually, that text console will
still be logged in. To disable this keystroke globally and permanently, you
need to set the DontZap flag in your xorg.conf or XF86Config or
XF86Config-4 file (whichever name is in use on your system). See the manual
for XF86Config (or variant) for more details.

Didn't work with physlock, but I don't have xscreenlock.
I wonder where #2 went. ;-)

Backdoor #3: Alt-SysRq-F.

This is the Linux kernel "OOM-killer" keystroke. It shoots down random
long-running programs of its choosing, and so might might target and kill
xscreensaver, and there's no way for xscreensaver to protect itself from
that. You can disable it globally with: sudo 'echo 176 >
/proc/sys/kernel/sysrq'

I got "This sysrq operation is disabled" for that one.

(As of version 5.41, if xscreensaver is setuid, and you are running
Linux 2.6.37 or newer, xscreensaver attempts to request that the kernel's
out-of-memory assassin not randomly unlock the screen on you, but it's only
a request.)
Backdoor #4: Ctrl-Alt-KP_Multiply.

This keystroke kills any X11 app that holds a lock, so typing this will
kill xscreensaver and unlock the screen. This "feature" showed up in the X
server in 2008, and as of 2011, some vendors are shipping it turned on by
default. How nice. You can disable it by turning off AllowClosedownGrabs in
xorg.conf.

No keypad to test...

Re: [qubes-users] Re: saltstack: user specific pillars in qubes

2020-10-21 Thread David Hobach


On 10/20/20 9:06 PM, David Hobach wrote:

Thank you very much!


I also got this running, thanks!

However when I run

qubesctl --all --show-output state.highstate saltenv=user

I get for my states:
State 'qvm.present' was not found in SLS 'mysls'
Reason: 'qvm.present' is not available.

I guess the custom qvm.* states are not available in the /srv/user_salt folder, 
but only in /srv/salt?

Is there any way to make them available in /srv/user_salt as well?

Side Note: I ran `qubesctl --show-output state.sls qubes.user-dirs` to obtain 
the folders.


For reference I got it running with symlinks this way:

#!/bin/bash
#
# Run the salt configuration of _this_ folder in dom0.
#
# Assumes that you have `user_[formulas|pillar|salt]` directories in _this_ 
folder.
#
# NOTE: If even `sudo qubesctl top.enabled` failed for you, you can try 
re-installing `qubes-mgmt-salt-* salt salt-minion`
#   (first via `sudo qubes-dom0-update`, then via `sudo dnf reinstall`.

set -e -o pipefail

[[ "$(whoami)" != "root" ]] && >&2 echo "This script must be run as root." && 
exit 1

#path of this directory (hopefully...)
SCRIPT_DIR="$(dirname "$(readlink -f "${BASH_SOURCE[0]}")")"

#saltModSymlink [target]
function saltModSymlink {
  local target="$1"
  local tpath="/srv/user_salt/$target"
  rm -f "$tpath"
  ln -s "/srv/salt/$target" "$tpath"
}

#create user_ symlinks @/srv/ for the saltenv=user (explicitly configured by 
Qubes OS)
echo "Creating user_ symlinks in /srv/..."
for file in "$SCRIPT_DIR"/* ; do
  if [ -d "$file" ] && [[ "$file" == *"user_"* ]] ; then
target="/srv/${file##*/}"

#remove previous instances & update new
rm -f "$target"
ln -s "$file" "$target"
  fi
done

#create module symlinks
echo "Creating Qubes module symlinks..."
saltModSymlink "_grains"
saltModSymlink "_modules"
saltModSymlink "_pillar"
saltModSymlink "_states"
saltModSymlink "_utils"

#sync modules (we just added some via the symlinks above)
#echo "Syncing modules..."
#qubesctl saltutil.sync_all saltenv=user

#call
if [ $# -gt 0 ] ; then
  echo "Calling qubesctl saltenv=user with your arguments..."
  qubesctl --show-output "$@" saltenv=user
else
  echo "Using qubesctl to apply the top.sls state..."
  qubesctl --show-output state.apply saltenv=user
fi


P.S.: I also noticed that right after I did
sudo qubesctl --all --show-output state.highstate saltenv=user
I get
```
sudo qubesctl top.enabled
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
'top.enabled' is not available.
DOM0 configuration failed, not continuing
```
(It did work right before.) It doesn't change after a reboot, only reinstalling 
the salt packages helps.
I guess that's not normal?


With the above & a fresh reinstall, this didn't happen anymore. It's odd anyway 
that it happened.

--
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/44f1ebe5-22a1-c6e4-a8a8-b0f4905466a1%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: saltstack: user specific pillars in qubes

2020-10-20 Thread David Hobach

On 10/20/20 6:22 PM, David Hobach wrote:

On 9/13/20 6:57 PM, lik...@gmx.de wrote:

OK, it might have been better if you had NOT modified my example, as you
should then have been able to verify that user pillars can be referenced
in this way.
I always find it better to take one small step at a time when
troubleshooting or trying to learn something new.

In the new case, you are using the user environment. I would try the
following:
/srv/salt/user_salt/get.top
user:
target:
- get

/srv/salt/user_salt/get.sls
get file:
cmd.run:
- name: wget {{pillar['host'] }}

qubesctl --skip-dom0 --targets=target state.apply saltenv=user get

You might like to look at:
https://docs.saltstack.com/en/latest/ref/states/top.html#environments

New environments can be defined in
`/etc/salt/minions.d/f_defaults.conf`, but I rarely do this in Qubes.

unman, as always you pointed me into the right direction. The whole reason it
was not working as I missed up with the directories.

Instead of using:
/srv/user_salt

I was using:
/srv/salt/user_salt

That's why your first example didn't work in my environment and I had to adjust
it.

Now everything is running perfectly with user defined pillars!

Thank you very much!

I also got this running, thanks!

However when I run

qubesctl --all --show-output state.highstate saltenv=user

I get for my states:
State 'qvm.present' was not found in SLS 'mysls'
Reason: 'qvm.present' is not available.

I guess the custom qvm.* states are not available in the /srv/user_salt folder,
but only in /srv/salt?

Is there any way to make them available in /srv/user_salt as well?

Side Note: I ran `qubesctl --show-output state.sls qubes.user-dirs` to obtain
the folders.

P.S.: I also noticed that right after I did
sudo qubesctl --all --show-output state.highstate saltenv=user
I get
```
sudo qubesctl top.enabled
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
'top.enabled' is not available.
DOM0 configuration failed, not continuing
```
(It did work right before.) It doesn't change after a reboot, only reinstalling
the salt packages helps.
I guess that's not normal?

--
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/c808b59e-9f9e-8fcf-acbb-a8971a7b97cd%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: saltstack: user specific pillars in qubes

2020-10-20 Thread David Hobach

On 9/13/20 6:57 PM, lik...@gmx.de wrote:

In the new case, you are using the user environment. I would try the
following:
/srv/salt/user_salt/get.top
user:
target:
- get

/srv/salt/user_salt/get.sls
get file:
cmd.run:
- name: wget {{pillar['host'] }}

qubesctl --skip-dom0 --targets=target state.apply saltenv=user get

You might like to look at:
https://docs.saltstack.com/en/latest/ref/states/top.html#environments

New environments can be defined in
`/etc/salt/minions.d/f_defaults.conf`, but I rarely do this in Qubes.

unman, as always you pointed me into the right direction. The whole reason it
was not working as I missed up with the directories.

Instead of using:
/srv/user_salt

I was using:
/srv/salt/user_salt

That's why your first example didn't work in my environment and I had to adjust
it.

Now everything is running perfectly with user defined pillars!

Thank you very much!

I also got this running, thanks!

However when I run

qubesctl --all --show-output state.highstate saltenv=user

I get for my states:
State 'qvm.present' was not found in SLS 'mysls'
Reason: 'qvm.present' is not available.

I guess the custom qvm.* states are not available in the /srv/user_salt folder,
but only in /srv/salt?

Is there any way to make them available in /srv/user_salt as well?

Side Note: I ran `qubesctl --show-output state.sls qubes.user-dirs` to obtain
the folders.

--
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/94f4ae21-bc4e-d1e6-38ce-94b753ef6437%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: attach encrypted usb drive as block?

2020-08-29 Thread David Hobach




On 8/24/20 7:34 PM, 'Ryan Tate' via qubes-users wrote:


Ryan Tate  writes:

If I attach as a block device, first it doesn't show up in nautilus.


Actually, I found that for some reason as a block device it shows up 
under "Other Locations" in the nautilus sidebar. Once I navigate there 
all is cake. Sorry for the noise.


If you ever need a USB drive for more than one qube, you might be 
interested in qcrypt [1].


[1] https://github.com/3hhh/qcrypt

--
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/768dc6ad-6bc5-b4d1-b493-f2f33081739f%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Can someone help me---again?

2020-08-01 Thread David Hobach


On 8/1/20 1:00 AM, bob ruff wrote:

Someone helped me install Qubes a couple of years ago. I just started
learning it when I was interrupted--for 2 years. Now dom0 is reporting
update expired 455 days ago. Do I need to reinstall Qubes to do updates
etc.?


2 years ago there was 3.2; the current version is 4.0 and cannot be 
upgraded easily from 3.2.


So you should probably reinstall.

--
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/381d5b46-31e0-239a-d4d9-222d8a308d1b%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] safely remove yum from debian tempate?

2020-06-29 Thread David Hobach


On 6/28/20 11:23 PM, Dave C wrote:

I'd like to

sudo apt remove yum

because the yum files in /etc/bash_completion.d/ break things for fossil
(autocomplete appends a space instead of slash after directories when
running fossil).

However, apt warns the following:

The following packages will be REMOVED:
   qubes-core-agent-dom0-updates qubes-vm-recommended yum yum-utils


yum is installed for dom0 updates:
If you use your debian template as netVM, yum will be used to download 
updates for dom0 via the netVM.


So removing any of these packages is certainly not recommended as it may 
break expected base Qubes OS functionality.


Btw, removing thunderbird currently also removes `qubes-vm-recommended` 
in debian templates, which breaks the same Qubes functionality and is 
clearly a bug.


--
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/0cbbc6da-887b-e968-5624-2e7926789d1d%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: Qubes OS & 3mdeb minisummit 2020

2020-05-30 Thread David Hobach


On 5/28/20 10:12 AM, Camille wrote:

edit: all the recordings will be available on 3mdeb youtube channel
 :)


Thanks for that, much appreciated!

--
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/7474b9f4-269b-63dd-3355-832c8b1d5da9%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes OS & 3mdeb minisummit 2020

2020-05-27 Thread David Hobach


On 5/27/20 5:25 PM, Camille wrote:



Hi,
Just short info about official *Qubes OS and 3mdeb minisummit 2020*, where 
qubes and coreboot core developers will discuss status fwupd/LVFS support for 
Qubes,
SRTM and DTRM for Qubes, Anti Evil Maid for Intel coreboot-based platform, 
Anti-Evil-Maid for AMD  and details about building and testing operating system 
on
virtual machines + AMA time.
Live  will be 
transmitted via OBS on 3mdeb YouTube channel. The nearest event starts *tommorow, 
4:00 PM (UTC+02:00)*
All the events are on the public callendar 
.
Details in blogpost  or on qubes 
 and 3mdeb twitter .
btw: it's not a marketing-pitch. Just regular nerds.



Thanks for the heads up!

I'm more interested in the recordings though. I guess most users from 
non-EU continents as well. ;-)


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9a4fc90a-8a90-9bee-1eb6-370d1886f261%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How to mount App-VMs from Outside qubes

2020-05-02 Thread David Hobach


On 5/1/20 6:53 PM, dhorf-hfref.4a288...@hashmail.org wrote:

On Fri, May 01, 2020 at 06:18:10PM +0200, Dieter wrote:

I tried accessing data on an old qubes (3.2) drive that doesnt boot



However after decryption I only see the lvms "qubes_dom0-swap" and
"qubes_dom0-root"



reading from dom0 is no problem but how can I access the other VMs?



mount the dom0 root volume
check for .img files under /var/lib/qubes/

these are loop-mountable volumes


Doesn't that depend on the storage pool being used? Your instructions 
should be valid for file storage pools.


However with Qubes 4 LVM thin storage pools became the default. You 
should be able to find instructions on this forum; there's also [1] 
describing how to do it from dom0.


[1] https://www.qubes-os.org/doc/mount-lvm-image/

--
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/11790649-392d-5680-e2f2-eb70ac767652%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Constant firefox crashes because of Qubes shared memory

2020-04-25 Thread David Hobach




On 4/25/20 12:53 PM, David Hobach wrote:

On 4/25/20 3:00 AM, Guerlan wrote:

I started having constant firefox crashes on my debian9 Qube. I sent the
crash reports to firefox and the said that the problem occurs because of
the shared memory configuration of Qubes, but he don't know how it's
configured.

Can somebody help me fixing this? How can I enlarge the shared memory?


Did you try to enlarge the maximum memory in your disposable VM template 
to 2 GB or so?


In dom0 it's
qubes-vm-settings [your dvm template]

Or do it via qubes manager.

--
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/857f77d6-be6a-b1fe-b015-0ea3d6579f4f%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Constant firefox crashes because of Qubes shared memory

2020-04-25 Thread David Hobach


On 4/25/20 3:00 AM, Guerlan wrote:

I started having constant firefox crashes on my debian9 Qube. I sent the
crash reports to firefox and the said that the problem occurs because of
the shared memory configuration of Qubes, but he don't know how it's
configured.

Can somebody help me fixing this? How can I enlarge the shared memory?


Did you try to enlarge the maximum memory in your disposable VM template 
to 2 GB or so?


--
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/1129557b-2fd2-3f88-1f8c-2cc351f4c7df%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Creating ones own Insurgo

2020-04-15 Thread David Hobach

On 4/15/20 6:05 PM, Catacombs wrote:

I purchased a refurbished Lenovo X 230 Core I5, 4 GB RAM, and a spinning hard
drive, Windows 7 Pro for $228.00.

I ordered 16 GB RAM for about a hundred dollars. I thought the RAM would be
less expensive.

My first mistake was to raise the BIOS/EFI to 2.77. Turns out Intel encrypts
something to prevent one from rolling back the BIOS/EFI.

The option I had before was to run a jailbreak on the Lenovo that should allow
me to neutralize the Intel Management Engines ability to get updates from
Intel. Intel also had a whitelist that limits which WiFi chip it will allow to
be used. I guess to make sure the Intel Management Engine can talk to the
mothership.That jailbreak does not one to take apart the laptop. The
jailbreak is on github 1vyrain. The site says do not attempt to use the
jailbreak unless one has the allowed, correct, lower version of BIOS/EFI or it
will brick it. As I write this I see some folks who say (Lenovo Forum) they
have -done something - to roll back BIOS/EFI to 2.6. So they could use
1vyrain. Jailbreak 1vyrain actually accomplishes two of the big items I
require. Prevent Intel from changing my X230 to something I do not want. And
allow me to use another WiFi chip.

The jailbreak doesn't even require hardware access. So no pi, Pomona etc.

However it cannot disable Intel ME if I recall correctly. Just check
their site.

Flashing the Lenovo X230 BIOS/EFI w
ith an EEPROM is git hub Skulls. Which requires I spend money. And the
documentation for doing that is not obvious, and old.

I decided I should buy a PI to program the X230. I started to buy one from
Amazon and cancelled that when I saw the voltage on the power supply was 2.5
volts and someone said not use 3.3 Or less as the flash might not work
correctly. Someone suggested ADA Fruit for the Pi. But the more complete ones
are not
In stock. I am waiting on Corona money to buy one so I wil keep looking. I had
a link once suggested by Insurgo. But it came from China, and took many weeks
before the Corona started.

My first questions. I had thought while looking at the Skulls there would be an
option for Core I5 versus Core I7. I haven’t seen it so far. Does that matter?

For coreboot it doesn't matter which CPU you have.

For Qubes OS i7 quad core is usually a lot better than i5 dual core on
these old platforms. The latter might make Qubes OS almost unusable.

However you'll have to make sure the CPU supports VT-d. There are some
which don't - usually the gamer models. Check ark.intel for that.

Clearly states to remove the battery, but did not say the coin CMOS battery.
In fact I have not found that little turkey.

I'd recommend to also remove that. Check the tons of youtube videos on
X230 disassembly on where to find it. There's also a Lenovo hardware
maintenance manual describing all steps.

I want to have enough in my bank account to afford a replacement MOBO if I
brick this one and can’t unbrick it.

There's probably even youtube videos flashing the X230 out there.

And usually unbricking always works with hardware access to the
firmware/BIOS chip.

Mostly the available documentation might have some flaw I am not experienced
enough to catch.

One thing is obvious, while I my income may be to low to buy one, Insurgo
products are not overpriced. This project is a lot of trouble. Parts. Tools.
are not free.

True.

Anyone have recent experience with flashing Skulls onto Lenovo X230?

I didn't try skulls (it's just coreboot pre-compiled for the X230 if I
recall correctly) as I don't like flashing some untrusted binaries from
the Internet.

But I have some coreboot flashing experience (!= X230 though).

--
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/97fb4b49-a9c5-6c7a-d1d5-92c9a73bef8a%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] CentOS Template: Run with native kernel

2020-04-06 Thread David Hobach


On 4/6/20 3:34 PM, donoban wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2020-03-13 13:37, David Hobach wrote:

Dear all,

I tried to run the CentOS template with its own kernel (qvm-prefs
vm kernel '') in HVM mode, but so far it refuses to start and I
always get the following error:

[   11.073799] blkfront: xvdc: flush diskcache: enabled;
persistent grants: enabled; indirect descriptors: enabled; [
11.200124] dracut-pre-trigger[316]: sfdisk:  /dev/xvdc:
unrecognized partition table type [   11.201569]
dracut-pre-trigger[316]: sfdisk: No partitions found [   11.202927]
dracut-pre-trigger[316]: sfdisk: unrecognized input:
type=82,start=2048,size=2097152 [   11.207577] dracut: FATAL:
Qubes: failed to setup partitions on volatile device [   11.232758]
dracut: Refusing to continue

Did anyone have the same issue?



Hi, I am just running in same problem. Did you fix it?


No. I installed CentOS to a StandaloneVM from virtual CD to get the 
native kernel. Requires 2GB RAM for the VM though to work.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bcd9a278-ca66-489f-8aeb-0f3754898d2a%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Firefox discontinues addon sideloading

2020-03-16 Thread David Hobach


Fyi:

It seems that even with Firefox 74 addon updating via sideloading still 
works.


Initial installation probably doesn't.

I don't get that latter point as the initial installation did generate a 
popup ("Do you want to activate the newly installed addon XYZ?") even 
before 74, but oh well...


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/df49e8a3-766d-9080-5acf-3b1d19089397%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] CentOS Template: Run with native kernel

2020-03-13 Thread David Hobach


Dear all,

I tried to run the CentOS template with its own kernel (qvm-prefs vm 
kernel '') in HVM mode, but so far it refuses to start and I always get 
the following error:


[   11.073799] blkfront: xvdc: flush diskcache: enabled; persistent 
grants: enabled; indirect descriptors: enabled;
[   11.200124] dracut-pre-trigger[316]: sfdisk:  /dev/xvdc: unrecognized 
partition table type

[   11.201569] dracut-pre-trigger[316]: sfdisk: No partitions found
[   11.202927] dracut-pre-trigger[316]: sfdisk: unrecognized input: 
type=82,start=2048,size=2097152
[   11.207577] dracut: FATAL: Qubes: failed to setup partitions on 
volatile device

[   11.232758] dracut: Refusing to continue

Did anyone have the same issue?

Thanks & Best Regards
David

--
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/c308a146-ee1e-934b-e25b-cae3d6528982%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Mounting directories across VMs (losetup/block device solution for directories)?

2020-02-29 Thread David Hobach

On 2/28/20 2:40 PM, Johannes Graumann wrote:

On 2020-02-27 20:32, David Hobach wrote:

On 2/26/20 10:23 PM, Johannes Graumann wrote:

Hi,
I'm experimenting with creating a sys-dropbox vm that syncs with my
dropbox account. I would love to be able to then mount defined
subdirectories of the synced path to other vms (losetop/qvm-block-
style, which only works for files).
Is this possible? Where to find pointers?

qcrypt can do that: https://github.com/3hhh/qcrypt

Nice solution, but overkill in my case - I use tresorit's E2EE solution
(let's not get started on the closed source/snake oil discussion, I have
to consider noob-co-usage ...) and want to sync that storage to a
sys-tresorit, from where I want to grant access to certain subsections
of it to individual vms - without additional encryption.

I disagree with the idea that only pros deserve real security.

I'd recommend automating stuff so much that it can be used by "noobs".
Only that automation programming might require some "pro" knowledge, but
it needs to be done only once.

Any pointers on where to start exploring the above mentioned sshfs via
qubes-rpc solution?

Check the qubes-rpc doc on the Qubes website. I'm not sure whether
someone already implemented that.

However wrt your apparently low profile threat model I don't see too
much of a security benefit over doing it over battle-hardened TCP
anyway. So you might just want to check the Qubes doc on opening ports
to other VMs.

--
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/8bc714cd-03b3-8f7d-d84b-168f3a02ea45%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Mounting directories across VMs (losetup/block device solution for directories)?

2020-02-27 Thread David Hobach


On 2/26/20 10:23 PM, Johannes Graumann wrote:
> Hi,
> I'm experimenting with creating a sys-dropbox vm that syncs with my
> dropbox account. I would love to be able to then mount defined
> subdirectories of the synced path to other vms (losetop/qvm-block-
> style, which only works for files).
> Is this possible? Where to find pointers?

qcrypt can do that: https://github.com/3hhh/qcrypt


--
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/93038100-29c0-bd17-0d02-e6168c218a5e%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] MAC Address Anonymization and NetworkManager Compatibility

2020-02-26 Thread David Hobach




On 2/26/20 7:12 AM, 'sf0IqXUyNLTP22nB3Lpt' via qubes-users wrote:

I have recently set up a vpn gateway qube according to the instructions as 
listed [here](https://www.qubes-os.org/doc/vpn/). I have now gone to set up the 
MAC Anonymization and have a question and a problem both.

Firstly the linked page wrote specifically not to include the network manager. 
But at the same time the page on anonymizing the MAC address says that you must 
begin by installing the network manager. Is this safe to do?


The doc is here: https://www.qubes-os.org/doc/anonymizing-your-mac-address/

Your VPN client should reside in a different VM (a proxy VM named e.g. 
sys-vpn) than NetworkManager (sys-net).


--
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/a10fbe9e-6fbc-9227-2d53-c07fdde70f3c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Scary Systemd Security Report

2020-02-13 Thread David Hobach


On 2/14/20 4:01 AM, Chris Laprise wrote:
That's odd. I use a regular debian-10 template for most things and 
exim4* removal only takes out 2 other exim packages.


Yes, they apparently put some effort into removing useless dependencies 
between debian 9 and 10.


E.g. gnome-keyring can also be removed now. :-)

--
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/cb6f6b18-3a6a-b71e-f8fb-e05fd520d3e6%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Using Single External Storage Device with Multiple VMs

2020-02-03 Thread David Hobach

On 2/3/20 7:12 PM, Chris Laprise wrote:
BTW, have you thought about a threat model where the whole disk uses a
single encryption key and partitions exist on top of that... and the
possibility that a compromised sys-usb copies some of the blocks from
other partitions into the partition of a compromised/coordinating AppVM?
What are the chances the compromised AppVM would be able to decrypt the
misappropriated blocks? I think many would be inclined to say the disk
cipher salt would protect the copied blocks from improper decryption,
but how certain is this?

That should be all covered:

Assuming the following single encryption layer structure
sys-usb (compromised)
<-->
appVM (compromised)
your're obviously fully compromised as both the appVM and sys-usb may
simply stop encryption and write plain text data to their attached
volumes. So your additional sys-usb encryption key is totally irrelevant
in that scenario (and thus not in the diagram above; it hides the number
of volumes you use from attackers looking at your external disk though).

The 2 layer encryption
sys-usb (compromised)
<-->
middleVM (not compromised)
<-->
appVM (compromised)
helps against that: appVM may stop encryption to middleVM, but middleVM
will do its job properly to sys-usb (middleVM should be a VM dedicated
to only doing encryption/decryption).

Another 1 layer scenario that you might have thought about:
sys-usb (compromised)
<-->
appVM (compromised)
appVM2 (not compromised)

appVM2 data will remain confidential as it is still doing its own
encryption. Integrity attacks may be attempted by sys-usb (i.e. sys-usb
may change encrypted appVM2 data without looking at the plaintext), but
will be detected by appVM2 (decryption will fail / data be lost) for any
reasonable symmetric cipher mode (mostly non-ECB).
sys-usb may also copy encrypted data from appVM2 to appVM, but neither
sys-usb nor appVM can break the encryption without the key.

Of course all of this assumes perfect VM segregation, no relevant bugs
inside cryptsetup, the Qubes block attachment code & some parts of my
code. So a rather large TCB unfortunately.

--
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/2596d1d0-b21c-3d63-4376-a42676cfe428%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Using Single External Storage Device with Multiple VMs

2020-02-02 Thread David Hobach

On 2/2/20 12:40 AM, Chris Laprise wrote:

On 2/1/20 4:12 PM, curiouscuri...@mailbox.org wrote:
To remain secure, must one use a different external storage devices
per VM / security domain? Can one use a single external storage
devices to store files from multiple VMs securely, and if so, how?

One option is to create a Qubes storage pool on the external drive, then
move some of your VMs to it:

https://www.qubes-os.org/doc/storage-pools/

Is creating multiple encrypted partitions on a USB drive, each only
mounted and unlocked in it's relevant VM, a good option? (This would
require multiple passphrases and I believe recognizing the relevant
partition from it's partition number / size, which seems a lot of
effort).

The answer in many of these cases is 'Yes', even without storage pools.
But it can get a little complicated.

Start by reading about 'qvm-block' (or the Devices GUI widget) and how
to attach raw block devices to different VMs. It also helps to know
about Linux storage e.g. how to create and use LUKS volumes.

You can, for example, have a physical disk partition accessible by
sys-usb, then 'qvm-block attach' it to a trusted encryption vm (this
could even be dom0) where 'cryptsetup' is used to format/open/close the
encryption layer. Then create partitions on top of that encryption layer
and use `qvm-block attach' to assign them to various AppVMs where they
are formatted/mounted.

My implementation for that:
https://github.com/3hhh/qcrypt

Anyway it depends on you use case:

If you trust the external device, attaching it to dom0 & additional
encryption against its loss & storage pools are likely the best option.
It's essentially like an internal disk then (the security properties are
very similar). You might want to keep in mind that you should use a
dedicated USB card/PCIE lane or mSata though - otherwise you have a
shared bus with other USB devices that you trust less.

If you don't trust it (you got it used from ebay, regularly give it to
other people or have many enemies in general), you'll want to go the
path outlined by Chris/in my implementation.

--
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/8ca28b35-c5af-d6a6-7fc9-e347ef3de162%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Firefox discontinues addon sideloading

2020-02-01 Thread David Hobach


On 1/31/20 11:15 PM, Claudia wrote:
> January 28, 2020 7:09 PM, "David Hobach"  wrote:
>
>> Dear all,
>>
>> apparently Mozilla decided to discontinue that feature [1] without 
providing a lot of alternatives

>> [2].
>>
>> It was quite useful in the past to update addons inside Qubes OS 
template VMs by downloading them
>> to another VM and pass them to the template VM without having to 
start firefox and perform a lot of

>> clicking.
>>
>> That'll be gone.
>>
>> So does anyone have an alternative available apart from a dedicated 
template VM just for firefox?

>>
>> Update the addons on every disposable VM start? ^^
>>
>> BR
>> David
>>
>> [1] 
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions
>> [2] 
https://discourse.mozilla.org/t/questions-on-sideloading-alternatives/49245

>
> Not sure, but it looks like this change only affects loading from a 
*global* directory (/usr/share/mozilla/extensions), and loading from 
inside the individual profile directories (~/.mozilla/extensions) will 
still be enabled. If that's the case, I imagine you could just symlink 
the XPI directory to somewhere on root.img. However it's not clear if 
they are still loaded silently, or if the user has to confirm it. I 
haven't been able to track down any specific commits or anything related 
to this. Might be worth looking at the Tor Browser mailing list / bug 
tracker for clues, as that's how they ship NoScript and HTTPS 
Everywhere, I think. They're currently on FF68 ESR, but I'm sure there's 
some buzz about what they're eventually going to do after FF72. Come to 
think of it, switching to FF ESR might be a temporary workaround for you.

>
> 
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/#comment-226503
> 
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/#comment-226508
> 
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/#comment-226614
> 
https://github.com/mozilla/geckodriver/issues/1517#issuecomment-513537686-permalink


Thanks for the hints!

I hadn't seen the comments... Guess they were loaded via JS and thus 
blocked by one of my addons. ^^


Anyway you're probably right: It's either the profile loading, ESR or a 
dedicated template with internet access to mozilla.org.
One could also follow their suggested path by setting up one's own addon 
server; it sounds a lot like overkill to me though.



--
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/56c1c36c-ecde-2ffa-f246-397df98aebe0%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] dom0 refusing to update

2020-02-01 Thread David Hobach


On 2/1/20 2:36 AM, tetrahedra via qubes-users wrote:
> I could just create the cache directory, but there's probably something
> more fundamentally wrong:
>
> $ sudo qubes-dom0-update
> --> Running transaction check
> ---> Package anaconda-core.x86_64 1000:25.20.9-17.fc25 will be installed
> ---> Package anaconda-gui.x86_64 1000:25.20.9-17.fc25 will be installed
> ---> Package anaconda-tui.x86_64 1000:25.20.9-17.fc25 will be installed
> ---> Package anaconda-widgets.x86_64 1000:25.20.9-17.fc25 will be 
installed
> ---> Package qubes-anaconda-addon.noarch 0:4.0.11-1.fc25 will be 
installed
> ---> Package qubes-usb-proxy-dom0.noarch 0:1.0.27-1.fc25 will be 
installed

> --> Finished Dependency Resolution
> 
/var/lib/qubes/dom0-updates/packages/anaconda-core-25.20.9-17.fc25.x86_64.rpm 
already exists and appears to be complete
> 
/var/lib/qubes/dom0-updates/packages/anaconda-gui-25.20.9-17.fc25.x86_64.rpm 
already exists and appears to be complete
> 
/var/lib/qubes/dom0-updates/packages/anaconda-tui-25.20.9-17.fc25.x86_64.rpm 
already exists and appears to be complete
> 
/var/lib/qubes/dom0-updates/packages/anaconda-widgets-25.20.9-17.fc25.x86_64.rpm 
already exists and appears to be complete
> 
/var/lib/qubes/dom0-updates/packages/qubes-anaconda-addon-4.0.11-1.fc25.noarch.rpm 
already exists and appears to be complete
> 
/var/lib/qubes/dom0-updates/packages/qubes-usb-proxy-dom0-1.0.27-1.fc25.noarch.rpm 
already exists and appears to be complete

> find: '/var/lib/qubes/dom0-updates/var/cache': No such file or directory
> Qubes OS Repository for Dom0 
  18 MB/s |  32 kB 
00:00

>
> This has been happening for a while, it seems like something about the
> dom0 update process is broken.

It just worked fine for me. Are you on stable?


--
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/eb08dd0a-90d4-9682-329e-46078a77450f%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Firefox discontinues addon sideloading

2020-01-28 Thread David Hobach


Dear all,

apparently Mozilla decided to discontinue that feature [1] without 
providing a lot of alternatives [2].


It was quite useful in the past to update addons inside Qubes OS 
template VMs by downloading them to another VM and pass them to the 
template VM without having to start firefox and perform a lot of clicking.


That'll be gone.

So does anyone have an alternative available apart from a dedicated 
template VM just for firefox?


Update the addons on every disposable VM start? ^^

BR
David

[1] 
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/
[2] 
https://discourse.mozilla.org/t/questions-on-sideloading-alternatives/49245


--
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/3f495bb6-9276-80bd-3f7b-f00b5a531337%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes OS 4.0.3-rc1 has been released!

2020-01-16 Thread David Hobach


On 1/15/20 12:59 PM, Andrew David Wong wrote:

Shortly after the announcement of 4.0.2 [1], a bug [2] was discovered in
the dom0 kernel included in that release. Since the bug would have
presented installation problems for the majority of users. That bug has
now been fixed, along with a few installer fixes, resulting in
4.0.3-rc1.




What should I do?
=

If you installed Qubes 4.0, 4.0.1, or 4.0.2 and have fully updated [4],
then your system is already equivalent to a Qubes 4.0.3 installation. No
further action is required.


I didn't get any dom0 or template update.
Kernel is 4.19.84-1, qubes-core-dom0 is at 4.0.48-1, 
qubes-core-dom0-linux at 4.0.21.1.


I also didn't get the updates for QSB #56 on the stable repo yet.

Can someone confirm that?

Thanks in advance!

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/31eb75c9-9066-4551-a847-6a4db98eb69c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How do vif-route-qubes and DNS forwarding work?

2020-01-14 Thread David Hobach


On 1/15/20 3:44 AM, tetrahedra via qubes-users wrote:

On Tue, Jan 14, 2020 at 04:46:16PM +0100, David Hobach wrote:
You'll find the explanations in the respective iptables and/or 
nftables rules of the next hop networking VM.


What do you mean by "next hop networking VM"?


Most users have a setup such as
VM --> sys-fw --> sys-net

The next hop from VM is then sys-fw, i.e. you'd have to look there.

There you'll see in nft list ruleset that port 53 forwarding traffic 
only has a non-effective DNAT rule (DNAT to the same IP it had before). 
Otherwise it's forwarded as by your routing table to sys-net. In 
/etc/resolv.conf you'll see that the imaginary IPs 10.139.1.1/2 are used 
as DNS servers for traffic originating from sys-fw (same as in VM).


Then in sys-net the imaginary IPs are DNATted to your DNS server 
(usually your router).


This all assumes that you allowed DNS with qvm-firewall. If you don't or 
do other changes, iptables/nft changes will happen inside sys-fw / the 
next hop networking VM.


Watch out that both nft and iptables are used.

--
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/a0903e21-6f4b-b80d-ad65-5f4d11152268%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How do vif-route-qubes and DNS forwarding work?

2020-01-14 Thread David Hobach




On 1/14/20 2:01 PM, tetrahedra via qubes-users wrote:

(originally sent to qubes-devel, but I guess failed moderation)

I can't quite tell from the source code -- when / where / how does it
run? Is it used to change routing on sys-net, or is it used to set
routing in other VMs so they work with sys-net?

How does DNS forwarding work? (the Qubes networking docs page mentions
DNS forwarding, but does not explain it)


You'll find the explanations in the respective iptables and/or nftables 
rules of the next hop networking VM.


--
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/a327646b-2d53-0213-08d4-aa842226ba56%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

2020-01-12 Thread David Hobach


On 1/5/20 1:59 AM, cyber.citi...@tutanota.com wrote:

I'm resurrecting this thread to report that I was affected by this problem.
I hope a solution will be implemented soon because it takes me the better
part of a day to restore my system, and that's a lot of time to lose to an
unpredictable glitch.


What was the original report?

Hanging during boot at that message?

I also get this every now and then, but usually rebooting helps. It 
definitely relates to the order in which sys-usb and/or sys-net are 
started (maybe the hardware init wasn't completely done yet?). There's a 
racing condition in there somewhere. There were a few github reports in 
the past and it got better with 4.


Anyway you can choose to not automatically start sys-net & sys-usb at 
boot, but do it manually and/or script it yourself. That's what I'm 
doing and why rebooting usually suffices for me.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2121a058-38a2-dae8-1fd3-6b3dfeb47bea%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers

2020-01-10 Thread David Hobach


On 1/10/20 10:27 AM, David Hobach wrote:

On 1/9/20 3:27 PM, David Hobach wrote:

https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/


I tested that after passing the device to a VM via IOMMU.

It did work and even survived a reboot (without power off though).


Disadvantage here:
An attacker may modify the ROM and then use DMA during the boot process 
to do whatever he wants. But that unfortunately applies to many PCIE 
devices. It's also an attack quite sensitive to timing.


--
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/41f8b39a-828b-8b91-a853-f73fb8c35e1e%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers

2020-01-10 Thread David Hobach


On 1/9/20 3:27 PM, David Hobach wrote:

https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/


I tested that after passing the device to a VM via IOMMU.

It did work and even survived a reboot (without power off though).

I found the firmware inside an extractable executable (7z) of the CD 
that came with it. It was ~13K and called UPDATE.rom.


Good luck with your devices!

--
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/89a818da-ae44-d3c7-f10d-54283fe5ac0d%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Renesas uPD720202 uPD720201 usb controllers

2020-01-09 Thread David Hobach

On 1/7/20 11:58 PM, Steve Coleman wrote:
A number of months ago I was happily backing up my system at home using
my sys-usb with a dedicated USB controller that worked right out of the
box. I didn't need any drivers or anything special. It just worked.

Then something happened, likely during an update, which could be like 6
months ago, so I switched back to using dom0 for my updates until I
could find the time to look into it. It appeared to me that the USB
controller was simply malfunctioning, so I searched for a new card from
a different manufacturer which claimed it had native Linux support.

But after installing this new card and booting up qubes, nothing. The
new card didn't work either. Booting other OS's both cards work just
fine. But with qubes neither one works, and as luck would have it both
cards have chip-sets from Renesas (uPD720201 uPD720202).

I know that I have received a couple of qubes-vm kernel updates over
that time, and I can't say for certain which one broke it, but it
appears that other people on some other OS's are also having some
similar issues:

e.g. circa 2018-05-05
https://bugzilla.kernel.org/show_bug.cgi?id=199627

and in 2016 there was a patch to xhci-pci
https://lore.kernel.org/patchwork/patch/686290/

and some more recent indecision and push back:
https://lore.kernel.org/linux-usb/cancmjzdqx6-+nagebbiym+1czs6jfmop9bm5uk4zup_mw5a...@mail.gmail.com/

https://lore.kernel.org/linux-usb/20191106083843.1718437-2-vk...@kernel.org/

So my question to this forum is; Short of buying yet another "new" USB
card and taking a chance of getting the exact same flunky Renesas
chipset, what other options are there for resolving this? It seems
Kernel.org/linux-usb isn't exactly making haste in fixing this issue,
and reverting back to an older and less secure qubes-vm kernel would be
a definite mistake given some recent vulnerabilities.

Thoughts? Do I need to trash them and just move on? I do have one that
is working in my machine here at work, but I'll have to disassemble it
to find out what brand/model number it is. I hate breaking tamper seals
if I can avoid it.

Thanks,

Steve

My hardware info:

$ sudo dmesg | grep xhci
[ 16.516802] xhci_hcd :00:07.0: xHCI Host Controller
[ 16.516893] xhci_hcd :00:07.0: new USB bus registered, assigned
bus number 2
[ 26.517096] xhci_hcd :00:07.0: can't setup: -110
[ 26.517199] xhci_hcd :00:07.0: USB bus 2 deregistered
[ 26.520823] xhci_hcd :00:07.0: init :00:07.0 fail, -110
[ 26.520857] xhci_hcd: probe of :00:07.0 failed with error -110
[ 26.522239] xhci_hcd :00:08.0: xHCI Host Controller
[ 26.522332] xhci_hcd :00:08.0: new USB bus registered, assigned
bus number 2
[ 36.522522] xhci_hcd :00:08.0: can't setup: -110
[ 36.522567] xhci_hcd :00:08.0: USB bus 2 deregistered
[ 36.524235] xhci_hcd :00:08.0: init :00:08.0 fail, -110
[ 36.524268] xhci_hcd: probe of :00:08.0 failed with error -110

$ lspci
...
00:07.0 USB controller: Renesas Technology Corp. uPD720202 USB 3.0
Host Controller (rev 02)

I can confirm the issue for that chipset.

Maybe the firmware loading fails, because it's not shipped with the
kernel? I don't know...

Ah...

https://www.startpage.com/do/dsearch?query=uPD720202+firmware

-->

https://mjott.de/blog/881-renesas-usb-3-0-controllers-vs-linux/

So possibly it claims to have the firmware in the EEPROM, but it in fact
doesn't and requires it from the kernel.

Not sure why yours ever worked then. I just got mine, so I can't claim
that. Maybe I'll try the stuff mentioned in the blog post.

--
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/32f441ad-e5eb-0eb4-b58c-f94942036e74%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] No connection to qubes-guid

2019-12-28 Thread David Hobach


On 12/28/19 8:15 PM, David Hobach wrote:

Dear all,

I recently had a few boots where Qubes OS didn't start any 
/usr/bin/qubes-guid processes. All VMs did start as usual, but the GUI 
wasn't available.


The logs didn't show anything (journalctl & VM log) except for the guid 
log which said: "Failed to connect to gui-agent".


The full log entry for reference:

Icon size: 128x128
libvchan_is_eof
Icon size: 128x128
domain dead
Failed to connect to gui-agent


It was back OK after 2 reboots. qvm-start-gui was running as far as I 
recall.



Did anyone experience the same issue? How can I restart the guid?

Best Regards
David


--
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/2a28001c-25a4-a18f-c6ed-008e4c900cdd%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] No connection to qubes-guid

2019-12-28 Thread David Hobach


Dear all,

I recently had a few boots where Qubes OS didn't start any 
/usr/bin/qubes-guid processes. All VMs did start as usual, but the GUI 
wasn't available.


The logs didn't show anything (journalctl & VM log) except for the guid 
log which said: "Failed to connect to gui-agent".


Did anyone experience the same issue? How can I restart the guid?

Best Regards
David

--
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/9b9b15fe-7123-9abc-2f34-49acb30c9e21%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: How do I attach a hard drive to a VM on boot?

2019-12-14 Thread David Hobach


On 12/13/19 8:33 PM, billol...@gmail.com wrote:

No, it's been consistent for a few weeks now, so I'm not going to worry
about it.  I did find another way to screw up, though.  I attached the
drive persistently to my "untrusted" VM, and then put the mount in
/etc/fstab in the debian-10 template, so it would persist also.  That
worked fine for the untrusted VM, but none of the other debian-based VMs
would start, since they couldn't mount /dev/sda3.  Sigh.  So, now I have to
figure out how to add that to the fstab just for "untrusted."  I saw some
instructions, involving adding an echo command to an rc script, but haven't
tried it yet.


Yes, simply use your mount in /rw/config/rc.local, cf. [1].

[1] https://www.qubes-os.org/doc/config-files/

--
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/d5dcf2af-6290-1acc-6bee-20fba3647d41%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Mike's emails

2019-12-12 Thread David Hobach




On 12/13/19 3:34 AM, tetrahedra via qubes-users wrote:

On Thu, Dec 12, 2019 at 05:23:47PM +, Mike Keehan wrote:

Qubes won't help in this situation - see
https://www.qubes-os.org/doc/disposablevm/#disposablevms-and-local-forensics 



They recommend using Tails for this type of situation.

Mike.


I am getting very many duplicate copies of Mike's emails, but only of
emails from Mike. Is this happening to anyone else?


Probably because he clicked "reply all" on one of your questions like I 
just did.


--
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/d7d8207a-188c-10ef-cbb5-c59a0f9a5572%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: How do I attach a hard drive to a VM on boot?

2019-12-12 Thread David Hobach


On 12/12/19 8:46 PM, billol...@gmail.com wrote:


Doh.  I just noticed the "noauto" option.  Sigh. Deleted it and it works
fine.


The only remaining problem here might be that /dev/sda3 doesn't 
reference the same drive on each dom0 boot process...


So you'd have to write a udev rule for that. Alternatively your could 
write a little dom0 script to do the attachment by disk ID 
(/dev/disk/by-uuid) rather than via --persistent.


But I might also be wrong and Qubes OS solved that referencing issue 
internally.


--
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/59257a08-0257-82f9-e618-3eeaf25b8c75%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Help sending multiple files using qrexec

2019-12-12 Thread David Hobach

On 12/5/19 3:28 AM, pr...@tutanota.de wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I should have mentioned that this was part of a bigger script, using qvm-copy
would have required me to also pass along the qube name, so I could then cd to
the correct QubesIncoming directory. Keeping it simple I went with tar:

Script one on the client:

tar -c $@ | cat

Script two on the server:

cat | tar -x

Thanks for the help!

It might also work without cat, tar just doesn't like to print to shells.

And you'll probably want to quote your $@ --> "$@" for files with spaces
and other special characters if you're running inside bash.

Can a hacker use the same script to transfer files from a victims pc remotely ?
And if so, how easy is it ?

This can't be used remotely, the server I mention above is another virtual
machine in the same Qubes system. This is just sending files between two qubes

If tar is exploitable, then the client VM can use that exploit on the
server VM above to execute code, yes. Also see [1].

For example the first script of this topic should be fairly easy to exploit.

In total I'd recommend to stick with the means provided unless
absolutely necessary.

[1] https://www.qubes-os.org/doc/qrexec/

--
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/b002992a-0120-ffc5-ac40-92ea81da3aa9%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

2019-10-27 Thread David Hobach


On 10/27/19 6:33 AM, gas...@gmail.com wrote:

Is there a clear guide of how to set up a DNS VM in Qubes OS?

I tried setting up dnsmasq in the VPN VM behind sys-firewall, both with
NetworkManager and as a standalone service.  It didn't work.  I also tried
on another VM behind the VPN VM.

All I got working is making DNS requests to the specific VM.  E.g.

$ dig example.com @10.137.0.23

But I wasn't able to hijack the DNS requests with iptables for general
requests without "@".  tcpdump seems to indicate that the DNS queries don't
even get routed through the VPN VM, which doesn't make sense to me, so I
might be missing something.

Any clear step-by-step guide anywhere?


I randomly found
https://blog.tufarolo.eu/how-to-configure-pihole-in-qubesos-proxyvm/

It looks reasonable, but I didn't test it. Use it at your own risk.
Depending on your chain of VMs the Qubes firewall may or may not work 
for DNS - just test it if it matters to you.



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4f7f6490-7d5c-3a08-ab56-1bf8060edc87%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Customizing Firefox in dispVMs

2019-10-12 Thread David Hobach

On 10/11/19 5:23 PM, unman wrote:

On Fri, Oct 11, 2019 at 03:04:16PM +, 'Totally Zoid' via qubes-users wrote:

Hello

Is there a definite way to customize the default Firefox install in the DispVMs
without launching it first in the TemplateVM (which I don't want to do for
obvious reasons)?

I thought to add a prefs.js file to get rid of the Google search and other
garbage that comes preinstalled and turned on in Firefox and which I have to
manually turn off in preferences and about:config every time I start the DispVM
(which gets tiring). However, apparently the profile folder is always generated
under a different name and the new default profile I created doesn't get
recognized.

~ Zoid

How about this:

Create a qube, which has no netvm.
Open firefox - configure it as you will. (To install plugins, you wil
have to download elsewhere and copy them in to this qube to install)
Close qube.
Use `qvm-prefs qube template_for_dispvms True`
Set netvm for that qube.
Open disposableVM based on qube.
Profit.

Also, if you have an old profile that you want to re-use, you can edit
~/.mozilla/firefox/profiles.ini to point to it.

E.g.:

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=0
Path=[full path to your profile.default]
Default=1

Also put your settings in user.js, not prefs.js. The latter is for
internal firefox usage only and may be modified by firefox.

Btw a website with some nice firefox settings: privacy-handbuch.de

--
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/07261753-1f1a-e3c4-2693-7b57e80b5f1d%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] With 4K monitor, if screen goes blank, mouse clicks don't work in VMs

2019-09-30 Thread David Hobach

On 9/29/19 7:12 PM, 'Micah Lee' via qubes-users wrote:

On 2019-09-24 18:21, Michael Siepmann wrote:

I've read and followed the instructions on
https://www.qubes-os.org/doc/gui-configuration/ but the problem I'm
having is different. Here's what happens:

1. I'm using VMs on a 4K monitor successfully, via DisplayPort.

2a. I have Dom0 screensaver set to Blank Screen Only and it blanks after
the configured number of minutes

OR 2b. I switch to using the laptop screen, then back to the 4K monitor

OR 2c. The computer wakes from sleep while the 4K monitor is in power
saving mode.

3. I can no longer click the mouse in my VMs (though it seems as if
maybe all clicks register in a very small area at the top left). The
mouse works normally in dom0.

4. If I switch to the laptop internal screen it works fine there, but if
I switch back to the 4K monitor it still doesn't work there. The only
way to get mouse clicking working in the VMs again is to shut down the
VM and restart it while using the 4K monitor.

The same thing happens if the computer goes to sleep and when I wake it
up the monitor is in power saving mode. My current workaround is to
disable the screensaver, and remember to wake the monitor before waking
the computer,

Is this a bug I should report? Has anyone else encountered this behavior?

I've encountered this bug (or a similar one) as well on a 4K monitor. It
appears that the mouse clicks only register if they're within the top
left width and height of the laptop resolution.

A workaround I've discovered is just restarting your VMs while your 4K
monitor is plugged in. If you start a VM with the monitor plugged in, it
lets you click anyone on the monitor within that VM.

You can also try to switch to a tty (e.g. Alt+Ctl+F2), wait a few
seconds and then go back (Alt+Ctl+F1). Works for me whenever I have
issues with external monitors.

--
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/5643f5cb-cd93-78b7-bd51-4fea74bfc10c%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] slightly off-topic: self-resetting OS idea

2019-08-26 Thread David Hobach

On 8/26/19 10:24 AM, panina wrote:

Hi!

This is not strictly Qubes-OS related, rather inspired by Qubes.

I've been struggling with some parts of Qubes usage. Most of the time,
it is overkill for me, and putting some strain on my computer. The
bugginess is also quite annoying, whenever I just need to do some
everyday work.
I've been thinking I'd like some form of dual-boot solution, or possibly
a Live USB that could be used.
Most of the time I work with ssh and webapps, so the only persistent
data I need to work will fit on a smartcard.

My thought is to have an installation that mounts most of the root
partition as readonly, and uses ramdisks wherever the system wants to
write (e.g /var/log). I'm also thinking it should be possible to get a
fingerprint or somesuch of the root partition, and use my TPM2 to check
this.

The system should also have a possibility to update itself, that I can
choose to do in environments that I feel is safe.

I am wondering if anyone knows of an OS that works like this? Or if
anyone knows of tools that might accomplish parts of this?

Ehm... You're describing Qubes OS with disposable VMs there? The
fingerprinting is essentially AEM?

If you need to keep your data on an external disk (SDCard), you can use
either a manual approach with qvm-copy, permanently attach the disk to a
single disposable VM with a fixed name or use an automated solution such
as [1]. You might also want to look into qvm-pool.

[1] https://github.com/3hhh/qcrypt

--
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/ffaf90c5-ee87-5982-b1a3-22028583e6f9%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes does not recover from crashed X11 (related to shmoverride and GUID)

2019-08-22 Thread David Hobach

On 8/21/19 11:59 PM, Vít Šesták wrote:

Hello,
sometimes, Intel driver makes my X11 crash (see X11-crash.log). It happens
usually when I rotate the screen, but also sometimes without any apparent
reason. I can usually replicate in a minute by rotating the screen like
crazy. Note that this situation does not happen when I log out or kill the
X server.

What's worse, Qubes OS does not recover properly. It displays login prompt,
but when I log in, all previously opened windows just flash and the GUID
crashes. In the debug output, it complains about something related to SHM,
see guid.disp7824.log. Even newly started VM don't have a working GUID.

Some debugging with strace has accidentally* pointed me to
/var/run/qubes/shm.id.0 file. When I rename the file, the GUID seems to be
able to start it again. The shm.id.0 fle is recreated with a different
number and it works again.

I have found that the file is related to shmoverride documented at
https://github.com/QubesOS/qubes-gui-daemon/tree/master/shmoverride . I
however don't have much further idea about that. Well, it is some X11
shared memory and it has some identifier. When the X11 crashes, maybe it
gets corrupted or maybe just the old file is not removed. I don't think
there is a corruption of the SHM, as some similar situation happened on OOM
kill. So maybe it is just about some final cleaning missing there. Do you
have some further idea?

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

*) Well, I hit a kind of antiheisenbug. GUID does not work when I run it
with strace (even before the X11 crash), because strace breaks SUID for
obvious reason. As a result, it will fail when trying to access
/var/run/qubes/shm.id.0. Nevertheless, this file seems to be relevant,
although the discovery was rather random.

Hi Vit,

I'd recommend opening a respective Qubes issue on github as it looks
like a bug to me.

BR
David

--
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/01ad130a-e74a-2f70-a356-039303fec905%40hackingthe.net.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] firewall rules by domainname

2019-07-16 Thread David Hobach




On 7/16/19 11:21 AM, haaber wrote:

Hello, entering IP adresses in the firewall restriction list can be a a
lengthy and unpleasant exercise. If your admin-VM should only be able
access your bank, whose webpage loads various data over JS encapsulated
subdomains, it can take a long while to make that working. The natural
question would be to allows domains by *name* rather than IP ranges. For
example   *.mybank.com  Is that possible? Cheers


It is possible by full domain name. I.e. your *. is not possible.

Moreover there will be issues with DNS load balancers etc. as the IP is 
only resolved once (during startup) by the firewall and then used 
instead of the domain name.


There might be a respective feature request @github.

--
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/7fcd18ef-c1ce-067a-850b-083fed954150%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Use different DVM templates from same AppVM

2019-07-15 Thread David Hobach




On 7/15/19 11:13 AM, mittend...@digitrace.de wrote:

Hey,

it is so nice to have different DVM-templates now!

But: Is it possible to start a non-default DVM from within an AppVM?

I have different DVMs for web browsing, intranet browsing and printing.
It would be comfortable If I would not have to change default-dvm
setting in order to start a DVM form a different template.


Just use
qvm-run --dispvm [template] command

If you prefer to click things, create a shortcut for the command.

--
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/5cf70d54-5cc1-1a6e-6f7b-2a47d939e0ea%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes OS 4.0.2-rc1 has been released!

2019-07-11 Thread David Hobach


On 7/10/19 3:52 AM, Andrew David Wong wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Qubes Community,

We're pleased to announce the first release candidate for Qubes 4.0.2!

Features:
  - All 4.0 dom0 updates to date
  - Fedora 30 TemplateVM
  - Debian 10 TemplateVM
  - Whonix 15 Gateway and Workstation TemplateVMs
  - Linux kernel 4.19 by default

Qubes 4.0.2-rc1 is available on the Downloads page. [1]


I just checked

sudo qubes-dom0-update --action=search qubes-template

and found

debian-8
debian-9
fedora-30
fedora-25-minimal
fedora-28-minimal

No debian-10 however. Did I miss something?

--
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/1835a537-5946-5bd4-4ee7-afbff76c7023%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] VPN before sys-firewall ?

2019-07-10 Thread David Hobach

On 7/10/19 8:45 AM, Luc libaweb wrote:

Le mardi 9 juillet 2019 23:22:23 UTC+2, Chris Laprise a écrit :

On 7/9/19 4:49 PM, Luc libaweb wrote:

Hello,

I read lot of things about VPN in Qubes OS.

I have mount a standalone VM with client VPN installed. This VPN VM connect to
the network with sys-firewall.

Others VM connect them directly on this VM VPN.

So, AppVM connect to Netvm Standalone VM VPN connect to Netvm Sys-Firewall

It's good or not for security ? Maybe the VM VPN bypass the sys-Firewall ?

In practice, you won't see any difference between these configurations
unless you have placed special rules _inside_ sys-firewall (in the
/rw/config dir):

sys-vpn -> sys-firewall -> sys-net

sys-firewall -> sys-vpn -> sys-net

sys-vpn -> sys-net

The reason is that sys-vpn uses "provides network" and is thus a proxyVM
just like sys-firewall; if you add firewall rules to your appVMs, they
should be processed the same way in either sys-firewall or sys-vpn. As a
result, sys-vpn can perform both vpn and firewall functions. If you
consider sys-vpn's role to be trusted and low-risk, then the third
example can accomplish the same thing as the first two while consuming
less memory and CPU.

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Thanks, so, the default sys-firewall just block all ingoing traffic separatly.
I think that it's better to place de sys-vpn after the sys-firewall because the
configuration of the sys-vpn is just - install the client VPN and force
autoconnection and autostart. If the client app VPN is compromised, it still
exists the sys-firewall between at rest.

Qubes OS implements its firewall rules in the next upstream VM which
"provides network" (see qvm-prefs). So if you don't trust your VPN VM to
manage your firewall rules, you'll need

client VM --> sys-firewall-vpn --> sys-vpn --> sys-net

If you additionally want firewall rules for sys-vpn (e.g. allowing only
connections to your VPN provider) and don't trust your sys-net to manage
them (because it manages your network devices already which run a lot of
proprietary code?), you'll need

client VM --> sys-firewall-vpn --> sys-vpn --> sys-firewall --> sys-net

You'll also need the latter if you want other client VMs with clearnet
connections and managed firewall via sys-firewall.

It's also explained in [1], section "Network service qubes".

I'd also recommend using disposable VMs with static names for these
service VMs.

[1] https://www.qubes-os.org/doc/firewall/

--
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/b58df159-3198-bc87-0be7-b33e980f1bb2%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Convenient untrusted storage for Qubes OS: qcrypt & qcryptd

2019-06-21 Thread David Hobach

On 6/20/19 8:12 PM, Chris Laprise wrote:
This could be an improvement over the scripts I use to mount backup
volumes in dom0.

One hope that popped into my mind as soon as I saw this post is for some
kind of automatic teardown to address this:

> but shutting down the mediator-vm during the attachment is likely to
leave your Qubes OS in a dreary state and will probably require you to
restart the system.

I've experienced this a number of times with my own setups. It would be
nice to have the unmounting and closing handled automatically, perhaps
with this:

https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-events.html#qubes.events.handler

qcryptd is listening to the Qubes OS internal events and
starting/stopping VMs & opening/closing chains accordingly. There is
currently a 1s heartbeat to implement delays, but no polling. blib
provides the underlying functionality [1].

From my experience with a chain such as
source --> mediator --> dest
shutting down the mediator may "confuse" Qubes OS/the internal qubesd
state. You should receive a warning by qcryptd though (I didn't want to
automatically shut down dest as the user might be working on unrelated
parts of the file system).

Even shutting down dest and then attempting to properly close the
remaining parts of the chain tends to trigger bug #4784 [2] and require
the aforementioned system restart. Simply shutting down the mediator
doesn't trigger the bug; that's why qcryptd does just that.

Overall qcrypt & qcryptd shouldn't trigger the bug anymore as long as
the user doesn't do anything "wild".

[1] https://github.com/3hhh/blib/blob/master/util/qubes/qwatch
[2] https://github.com/QubesOS/qubes-issues/issues/4784

--
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/ffb7fd96-1d5c-f52e-db6b-6c6b53e7f3fd%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Convenient untrusted storage for Qubes OS: qcrypt & qcryptd

2019-06-20 Thread David Hobach

Dear all,

Qubes OS has always provided the basic tools to accomplish encrypted
storage devices, namely qvm-block [1] and cryptsetup [2].

However the combination is neither self-explanatory nor convenient for
users who come from Operating Systems which provide "plug & play" for
most devices. This facilitates user mistakes made either manually or
with self-written software.

Thus I decided a while back to bring my self-written software to release
grade and therefore present qcrypt and qcryptd at

https://github.com/3hhh/qcrypt

qcrypt can be used to create, open or close encrypted containers from
dom0 in a way similar to cryptsetup [2] - just with added support for
the Qubes OS VM infrastructure.

qcryptd attempts to bring back the "plug & play" feeling by providing a
daemon that automatically opens or closes encrypted containers whenever
VMs are started, stopped or external devices are attached or removed.

Both are command-line tools and heavily rely on the bash library blib
[3]. qcryptd requires some configuration in the form of ini files [4].

Feel free to review the code, use it at your own disposal or provide
feedback (questions, issues @github, ...). I hope it'll be useful not
only for me alone. ;-)

My code signing key for reference: (1533 C122 5C1B 41AF C46B 33EB) EB03
A691 DB2F 0833

Best Regards
David

[1] https://www.qubes-os.org/doc/block-devices/
[2] https://gitlab.com/cryptsetup/cryptsetup/wikis/home
[3] https://github.com/3hhh/blib
[4] https://github.com/3hhh/qcrypt/blob/master/conf/examples/ex01.ini

--
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/e77e5686-126b-7976-41e8-4487bd9a6ef2%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How to sync files from a file as block device attached to another qube?

2019-06-03 Thread David Hobach


On 6/2/19 6:03 PM, 'SideRealiq' via qubes-users wrote:

If I create a loopback device in vm1 and attach it to vm2, any changes in vm1 
device are not reflected in the attached vm2 device. Why is that and how can 
they be reflected/synced?

Here is my test code:
# in vm1
sudo losetup -f --show ~/loopfile.img
## result: /dev/loop2
sudo mkdir /mnt/loopmnt

# in vm2
sudo mkdir /mnt/loopmnt

# in dom0
qvm-block
## result: vm1:loop2 /home/user/loopfile.img

qvm-block attach vm2 vm1:loop2
qvm-block
## result: vm1:loop2 /home/user/loopfile.img  b(frontend-dev=xvdi, read-only=no)

qvm-run -u root -p vm1 'mount /dev/loop2 /mnt/loopmnt'
qvm-run -u root -p vm2 'mount /dev/loop2 /mnt/loopmnt'

# in vm1
cd /mnt/loopmnt
# create a new file and verify it is there

# in vm2
ls -al /mnt/loopmnt
# the changes from vm1 are not reflected.


As I've said in the other thread:

Mounting the same device two times in different VMs is a bad thing to do 
as it'll not work in the best case (apparently above) and result in data 
corruption in the worst.


One device should only be mounted inside a single VM unless it's some 
special networking file system (e.g. nfs), but even then it's not meant 
to be used with qvm-block, but over the network...


--
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/ab57a3fb-ab44-6d1b-c5be-54b3fed5b8c7%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How to automate cloud backups of trusted vault files?

2019-05-28 Thread David Hobach

On 5/27/19 3:05 PM, David Hobach wrote:

On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote:
How to automate backups of files from a very trusted vault to the
cloud? What are some best practices for that?

My current issue is that the files in the trusted vault do not have
internet connection, so the cloud backup software should not be
running in the vault, and needs to run in a separate "backup" internet
connected qube. But I don't know how I can automate copying the files
from the vault to the backup qube. The qvm-copy command requires
manual choice of the target VM, which is not automated.

This depends on your Qubes RPC policy, which you can manage with the
/etc/qubes-rpc/policy files in dom0. Also see [1].

So you can automate qvm-copy usage, if you want to.

Another option is to entirely attach your data from the source VM to the
backup VM using qvm-block, which should be faster as it doesn't involve
copy operations between VMs. See e.g [2] for that method.

I'd also recommend to
a) use software you trust for backups.
b) use encrypted containers (e.g. dm-crypt) for backups unless you
completely trust your cloud provider (I certainly don't).

[1] https://www.qubes-os.org/doc/rpc-policy/
[2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955

I had received another few private questions about this that I'd like to
respond to:

1. "You mentioned "use encrypted containers" when backups are made they
are encrypted correct? How about AppVMs, are they encrypted by default?"

The default backups made by Qubes OS are encrypted and should be the
overall preferred way of doing backups.

Since the OP was asking about only backing up dedicated files rather
than the entire AppVM (what the Qubes OS backup does), he'd have to
implement the encryption part himself.

It might make also sense to put the data meant to be backed up inside a
dedicated VM and then use the default backup mechanism with your cloud
provider. Of course you'd have to mount the cloud provider file system
inside your backup VM first.

Personally, I don't use the default mechanism for speed reasons - my
internet connection is too slow to push 100+ GB over it for every
backup. sparsebak might help here [3], but is not official yet.

[3] https://github.com/tasket/sparsebak

2. "For option 2) the function b_dom0_attachVMDisk attaches "the entire
private disk image (private.img) of the source VM to the target VM". In
my vault there is a folder with the encrypted files, and another with
decrypted files and I don't want to expose the decrpyted files to
another VM. Can I attach only a specified folder (with the encrypted
files) to another VM? If yes how?"

You can only attach devices to other VMs with qvm-block. So you'd have
to put your file inside a loop device, which you could then attach to
the backup VM. If "encrypted files" means a dm-crypt container, you can
map the decrypted data from your AppVM to your backup VM (cryptsetup
creates a /dev/mapper/something device after decryption, which you can
then use with qvm-block).

I'll also release some software in a month or so to simplify dm-crypt
usage with Qubes OS.

Alternatively you could separate the files you'd like to backup from
those you don't by using different VMs for them.

--
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/e3344f77-9258-2a41-fd5a-1720ae7d5f13%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How to tag a VM?

2019-05-27 Thread David Hobach




On 5/27/19 2:24 PM, 'Side Realiq' via qubes-users wrote:

According to the RPC Policy https://www.qubes-os.org/doc/rpc-policy/ VMs can be 
"tagged". How?
I cannot find tags in the Qube Manager.


Please check `man qvm-tags` in dom0.

--
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/d00b1e27-7ae5-5c6f-0d7e-f050ce8c36da%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] How to automate cloud backups of trusted vault files?

2019-05-27 Thread David Hobach

On 5/27/19 12:52 PM, 'Side Realiq' via qubes-users wrote:

How to automate backups of files from a very trusted vault to the cloud? What
are some best practices for that?

My current issue is that the files in the trusted vault do not have internet connection,
so the cloud backup software should not be running in the vault, and needs to run in a
separate "backup" internet connected qube. But I don't know how I can automate
copying the files from the vault to the backup qube. The qvm-copy command requires manual
choice of the target VM, which is not automated.

This depends on your Qubes RPC policy, which you can manage with the
/etc/qubes-rpc/policy files in dom0. Also see [1].

So you can automate qvm-copy usage, if you want to.

I'd also recommend to
a) use software you trust for backups.
b) use encrypted containers (e.g. dm-crypt) for backups unless you
completely trust your cloud provider (I certainly don't).

[1] https://www.qubes-os.org/doc/rpc-policy/
[2] https://github.com/3hhh/blib/blob/master/lib/os/qubes4/dom0#L955

--
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/aa93817e-d50b-3113-535a-f6ce6a74ecff%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: Qubes - Critique (long)

2019-05-11 Thread David Hobach

On 5/10/19 8:09 PM, Chris Laprise wrote:

On 5/10/19 12:16 PM, Marc Griffiths wrote:

My experience of installing on a Lenovo Yoga 720 was seamless,
everything worked including the touch screen. However, I experienced a
lot of random browser crashing. Chromium dead birds on a fairly
regular basis. Vivaldi, Chromium, and Firefox browser windows
disappearing without error, on both Fedora and Debian. Upgrading to
Fedora 29, and upgrading dom0 didn't resolve the problem. A few times
the desktop became unresponsive, and while I was able to ctrl+alt+F2
to dom0, it wasn't clear how I could view processes running on a
particular VM.

Sorry to hear about the stability issues. You might try updating your
UEFI firmware to see if that helps.. the precise way that it configures
advanced hardware features (seldom used by other operating systems) does
have an impact on both compatibility and stability. This is also a good
reason to stick with business-oriented computers because vendors take
more care to get advanced features working correctly on them; its one of
the reasons why Thinkpads are so popular among Qubes users.

The browser stuff sounds more like memory issues to me (not enough
memory assigned to disposable VMs).

I can confirm the ctrl+alt+F2 desktop issue with awesome WM as well.
Usually it became responsive after going back from the console to the WM
though.
This was "introduced" ~3 months ago or so; I guess it's a well hidden
bug, possibly not a Qubes one.

You're not limited to XFCE, and in my experience KDE works better.

And awesome, i3, ... But yes, KDE was even standard with Qubes 3.

--
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/3f9c7180-1648-7b05-8a66-a8f2fdf08a7a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Spontaneous rebooting

2019-04-18 Thread David Hobach

On 4/18/19 12:52 AM, Michael Siepmann wrote:

I dont see this on any machine, including long running desktops.
Is it possible that you are suffering from over-heating? That would
account for symptoms.

I'm now monitoring temperatures with the "sensors" command in a dom0
terminal and although the problem hasn't yet happened again, the
temperatures I'm seeing are often getting close to or even reaching
"Critical":

coretemp-isa-
Adapter: ISA adapter
Package id 0: +100.0°C (high = +84.0°C, crit = +100.0°C)
Core 0: +99.0°C (high = +84.0°C, crit = +100.0°C)
Core 1: +100.0°C (high = +84.0°C, crit = +100.0°C)

acpitz-virtual-0
Adapter: Virtual device
temp1: +99.0°C (crit = +200.0°C)

thinkpad-isa-
Adapter: ISA adapter
fan1: 4788 RPM

If over-heating is the cause, does that suggest a hardware problem, or
is there something I can do to configure Qubes differently to stop it
from getting so hot?

That's not good. Usually CPUs shut down and cause a reboot as you
observed at 100-110 Celsius (CPUs may die at higher temperatures and
thus perform an emergency shutdown).

Looks like you have a hardware issue with your CPU fan. Either cleaning
the CPU fan and replacing the thermal paste or replacing the entire CPU
fan is likely to solve your issue. Youtube videos are your best friend
there.

I had similar syptoms in the past, replaced the fan and thermal paste
(apparently the seller had applied way too much) and went down to 70-80
Celsius at maximum load.

--
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/465aeeec-ef5d-fe30-d1b1-6fe1593a694a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Spontaneous rebooting

2019-04-13 Thread David Hobach




On 4/13/19 8:29 PM, brendan.h...@gmail.com wrote:

There are some discussions in qubes-issues on github about torbrowser causing 
100% cpu while idle, yet appearing to mostly work ok. Running a couple VMs with 
that bug might cause an overheat reboot on some systems...


No Intel AMT (coreboot), no overheating (~50-60 degrees when idle), no 
torbrowser here... But thanks for the hints anyway, maybe it'll help 
someone!


I was referring to [1] earlier on. I didn't observe any log entries though.

I'll keep you posted if I ever find the root cause.

[1] https://github.com/QubesOS/qubes-issues/issues/3079

--
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/62109593-6b21-f372-5487-644e568329a9%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Spontaneous rebooting

2019-04-13 Thread David Hobach

On 4/12/19 5:24 PM, Michael Siepmann wrote:

On 8/10/18 12:37 PM, Kelly Dean wrote:

Am I the only one having a problem with Qubes spontaneously rebooting on Intel
hardware? Only other reports I see are about AMD problems, but I'm using an
Intel Core i3.

Happens every few weeks. Sometimes just 1 or 2 weeks, sometimes 5 or 6. Got it
on Qubes 3.2, and now 4.0 too (new installation, not upgrade), multiple times.

Unlikely to be a hardware problem. The system passed both memtest86 and a
multi-day mersenne prime stress test. And other OSes tested on this hardware
before I switched to Qubes, including Debian and Windows, never had a problem.

The rebooting seems completely random. No apparent trigger, and no warning.
Acts like an instant hard reset. Sometimes even when the system is idle, and I
haven't touched the console for hours.

It's wearingly inevitable enough that I don't even bother intentionally
rebooting after system updates anymore, in order to minimize how many reboots I
have to deal with (setting my workspace back up is an ordeal), because I know
the system will end up spontaneously rebooting a week or two later anyway.

I'm having this problem too. I hadn't had it for a while but in the past
week or so it's happened a few times. I have a Lenovo ThinkPad T440p
with Intel Core i7, and Qubes 4.0 which I keep updated.

Same here, but only since 4.0 and since coreboot & ME-cleaner on a T530.

I've always suspected that it's related to memory kills (there was an
OOM issue on github), but there's absolutely nothing in the journal
after such a "forced" reboot.

--
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/c5bb034e-dd78-e357-10d8-8a9d78de3ca0%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: ThinkPad X270 USB C/Thunderbolt USB C type and docking station Qubes 4.0

2019-03-21 Thread David Hobach

You're doing all this, BTW, because rather than supporting Thunderbolt and PCIe
hotplug (which are usually protected by that device authorization you have to
disable), Qubes is trying to protect users with FireWire and ExpressCard that
are fundamentally insecure. I hope those extra 4 times a day you enter your
dom0 decryption key on boot while using a dock aren't putting that key at extra
risk or incentivising you to use a weaker key. :(

Yes, and that's also why Thunderbolt is disabled. It has full memory
access and can likely bypass IOMMU = r/w access any VM on hotplug. So if
you leave your laptop unattended for 5mins, someone can simply
read/write the entire memory by just plugging in a USB type C stick into
your thunderbolt port [1].

More broadly, I think the lack of hotplug support is a misguided trade-off that
hampers the usability of Qubes and just creates one more barrier to adoption
for users. Folks with firewire ports/expresscard slots and nation-state
adversaries with physical access need to disable those ports/slots in BIOS
rather than relying on lack of hotplug support to protect them. It's not that
hard to hide something in an expresscard slot that will be there on boot, and
then it's game over for dom0 even without hotplug.

True, that is somewhat more advanced though. State-level attackers have
teams that can open and replace arbitrary hardware with malicious one
within 15 mins, yes. So if you fear them, don't leave your laptop
unattended anyway.
In contrast your colleague sitting next to you at work can plug in a USB
stick into your laptop and perform the thunderbolt attack whilst you're
at lunch.
Having someone physically take away your laptop or even dismantle it is
a lot more suspicious.

Qubes OS is focusing on security and fortunately doesn't make security
tradeoffs even for usability.

[1] http://thunderclap.io/

--
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/eb20546b-093a-1508-0adf-3afd30316446%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] ThinkPad X270 USB C/Thunderbolt USB C type and docking station Qubes 4.0

2019-03-20 Thread David Hobach

On 3/20/19 1:33 PM, aaq via qubes-users wrote:

Hello qubes users!

I currently acquired this dock
(https://www.dell.com/en-us/shop/dell-business-thunderbolt-dock-tb16-with-240w-adapter/apd/452-bcnu/pc-accessories),
and tried to connect it with my laptop, but it does not seem to work.

I have found different posts here and there regarding the issue, and I think
the most common solution is turning on the computer with the cable attached.
This does NOT work however.

I have not tried to boot up without attaching, and viewing lspci output, and
then comparing to when I have it connected. Will do that and post back if there
are no better suggestions for now.

I have also NOT modified my kernel yet or done anything to the start up flags
(other than enabling USB devices in general, so I can use my keyboard and
mouse).

I am running Qubes 4.0.

Any help appreciated!

Short story: Thunderbolt is not supported, see [1].

Longer story: It might be beneficial for the security of Qubes OS not to
support it anyway [2]. It appears that the Qubes devs are attempting to
get it done correctly though.

[1] https://github.com/QubesOS/qubes-issues/issues/4426
[2] http://thunderclap.io/thunderclap-paper-ndss2019.pdf

--
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/8b2ac192-d774-5565-eeeb-88bfc1d24b29%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Logging Drop Packets

2019-03-09 Thread David Hobach

On 3/9/19 2:58 AM, unman wrote:

On Fri, Mar 08, 2019 at 08:07:46PM +0100, Zrubi wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 3/8/19 3:28 PM, cmsch...@gmail.com wrote:

I'm trying to setup an appvm like this:

appvm -> appvm_firewall -> vpn -> vpn_firewall -> sys-net

I want to tighten the firewall rules and do a deny policy. How can
I get a log of dropped firewall packet logs from appvm_firewall or
vpn_firewall? I've tried a few different iptables commands but I
haven't really had any success.

From my point of view the "Qubes way" of doing this would be something like
appvm -> logging VM -> appvm_firewall -> vpn -> vpn_firewall -> sys-net

You can accomplish this in a rather straightforward way by using a proxy
VM with your preferred logging mechanism (sflow, iptables, tcpdump, some
IDS, ...). Alo see [1], "Network service qubes".

For iptables you'd require at least one rule in that proxy VM which
enables logging. It should be stored inside /rw/config/rc.local [1].

If you're looking for drops only, this is somewhat more complicated
because with the above, you'd just log everything.
You can however do filtering or log only ICMP replies (Qubes will send
an ICMP reply on rejected packages) and/or TCP handshakes that weren't
completed.

Of course you can also go with the other proposal by unman and modify
the Qubes firewall inside appvm_firewall. This however has the various
drawbacks mentioned inside [1], "Network service qubes". Mistakes there
can be costly even if the modification is rather easy for advanced users.

[1] https://www.qubes-os.org/doc/firewall/

--
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/65515e35-36ee-b333-54f7-6b36e3a8b6bd%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] where/how does dom0 gets its icons?

2019-03-02 Thread David Hobach

On 3/1/19 8:54 PM, Daniel Allcock wrote:

Hello,
I would like to understand what to do to customize the icons
that appear in the Q menu for template and app vms.
The only way I have found that works is to overwrite icon
files in /usr/share/icons/Adwaita/* in the template vm.

In dom0 it is easy: I put an icon folder Qubes in ~/.icons,
with a custom svg icon for a terminal, named appropriately, and Adwaita
as backup icon theme, ran gtk-update-icon-theme, and then chose that
icon theme in xfce settings. Everything just works.

I don't know about Adwaita or anything, but Qubes OS adheres to the
Freedesktop Standard [1] (I guess version 1.0 though).

So the entire menu incl. icons is managed by *.desktop and *.menu files
in dom0. Nothing is imported from within any VM.

If I recall correctly, the menu structure is managed at
~/.config/menus/applications-merged/ and the name & icons of the entries
at ~/.local/share/applications.

The sync you mentioned probably copies files from
~/.local/share/qubes-appmenus/ to ~/.local/share/applications as you
reconfigure your menu with e.g. the Qubes manager. I'm not 100% sure
about that, but you can easily test it.

Hope that helps,
David

[1] https://standards.freedesktop.org/desktop-entry-spec/latest/

--
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/d5d38c19-2157-60d4-7906-9e8137304401%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] [warn] last whonix-gw update, ipv6 and possible VPN leak!

2019-02-16 Thread David Hobach


On 2/15/19 10:14 PM, 'Evastar' via qubes-users wrote:

Seems after last whonix update my old VPN VM begin leaking traffic. After investigation I 
found that it's because ipv6 primary connection to whonix-gw. I guess that whonix-gw now 
supporting ipv6. It leak traffic through ipv6 connection to whonix and ignore my default 
old ipv4 setup. "qvm-features VM ipv6 0" fixed this issue! But I'm not sure 
about all my others vpns and leaking with ipv6. How I must fix this at vpn setup (on 
load) to be 100% sure that it never happen again?


For debian templates, you can also set in /etc/sysctl.conf:
net.ipv6.conf.all.disable_ipv6 = 1
I guess debian updates might mess with it though.

In particular I didn't notice `man qvm-features` to explain the setting 
you mentioned.


But thanks for the notice!

It is somewhat odd to observe this change, yes.

--
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/9de03e8e-de73-ef11-0b49-0070514e2ddc%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] ANN: blib - a bash library

2019-01-12 Thread David Hobach


Dear all,

I recently released blib [1], a bash library which also aims to be 
useful for Qubes OS bash developers.


The documentation can be found at [2], the Qubes specific part at [3].

A short example of what it can do:

---
#!/bin/bash

source blib

b_import "os/qubes4/dom0"

function getTheAnswer {
echo "There's none?!"
return 42
}

vm="d-testing"
b_dom0_ensureRunning "$vm" || { B_ERR="Failed to start the VM ${vm}. 
Maybe it doesn't exist?" ; B_E }


b_silence b_dom0_execFuncIn "$vm" "" "getTheAnswer"
echo "The answer to everything, computed by the VM ${vm}: $?"
---

Please let me know if there's any issues with it.

Best Regards
David

[1] https://github.com/3hhh/blib
[2] https://3hhh.github.io/blib-doc/blib.html
[3] https://3hhh.github.io/blib-doc/blib.html#osqubes4dom0

--
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/55f125e3-2948-3c68-1956-c325e19e3be2%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] old version of xscreensaver

2019-01-04 Thread David Hobach

On 1/4/19 9:24 AM, Frédéric Pierret wrote:

On 1/4/19 1:51 AM, unman wrote:

On Fri, Jan 04, 2019 at 12:03:49AM +0100, Frédéric Pierret wrote:

We built the upstream package of xscreensaver in current-testing for
both Qubes 3.2 and 4.0.

Welcome back to XFCE Chris :D !

On 1/3/19 11:56 PM, Chris Laprise wrote:

On 01/03/2019 02:00 PM, Achim Patzner wrote:

Am Mittwoch, den 02.01.2019, 20:42 -0800 schrieb pixel fairy:

xscreensaver complains about being an old version. doubt this
matters, but might scare some users.

There are worse problems with it (and some of them depend on X and the
hardware you're running on) which might also warrant finding something
different. I just have to find some time for constant rebooting of my
system to create a meaningful bug report.

(To give you an idea: Imagine a machine (let's call it Lenovo P52) with
multiple GPUs where certain output channels are connected to one of the
GPUs only starting a screen server. If you connect your second monitor
to the right port the screen saver will not blank one of them if you
start X without an appropriately xorg.conf... And to make things worse
it also depends on the GPU you are using and the phase of the moon.)

The bad screensaver is one of the reasons I switched back to KDE, and
why I recommend it to other Qubes users. The default environment
doesn't rise to the level of an every day functional desktop.

I fully agree - xscreensaver has lots of issues. Many of the
screensavers do though. E.g. most won't survive an X server crash due to
e.g. OOM killer, but your X server will probably be restarted
automatically and leave your screen unprotected...

In total it's not wise to trust one's screensaver for anything sincere.

Is this a thing now? Is Qubes going to provide updated packages for any
other software?

Absolutely not. It is just because it is annoying, at least, under XFCE.

--
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/fa3bf1a3-9d4d-b859-746b-89e7a7c029eb%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Error when trying to add a lot of firewall rules

2019-01-01 Thread David Hobach

On 1/2/19 4:34 AM, qubes-users-list - wrote:

Ah! I reread the docs, and it mentions a size limit 3k/~35-39 rules. So I
suspect that I'm hitting this limit. I was getting the error right in that
range. Thank you for pointing me at that. The docs point out rightly that
I can just put rules in the vm directly, so I'll go that route.

For those curious, I'm running a fully up to date R4

The docs say "there is a 3 kB limit to the size of the iptables script".
I'm curious as to where that limit comes from if anyone happens to know.

Hmm yes unman wrote that doc part...

But considering Marek's statement in
https://github.com/QubesOS/qubes-issues/issues/1570 : "This is already
fixed for Qubes 4.0. The fix is not feasible for backport (it's
incompatible change). The limitation is already documented."

Are you running 4.0? Because if so, that is a bug and should cause #1570
to be reopened. I cannot see the Qubes version from your post though.

On Tue, Jan 1, 2019 at 9:42 PM unman wrote:

On Tue, Jan 01, 2019 at 09:09:48PM -0500, qubes-users-list - wrote:

I'm trying to add a fair number (around 50?) firewall rules to a vm. I'm
reading a directory of wireguard configs and trying to create a specific
rule for each ip*port.

After adding many rules, at a very consistent point, I get the following
error:

$ qvm-firewall add --before 0 accept proto=udp dsthost=
dstports=
Got empty response from qubesd. See journalctl in dom0 for details.

journalctl in dom0 says:

unhandled exception while calling src=b'dom0'

meth=b'admin.vm.firewall.Set'

dest=b'' arg=b'' len(untrusted_payload)=2417
Traceback (most recent call last):
File "/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line

262,

in respond
untrusted_payload=untrusted_payload)
File "/usr/lib64/python3.5/asyncio/futures.py", line 381, in __iter__
yield self # This tells Task to wait for completion.
File "/usr/lib64/python3.5/asyncio/tasks.py", line 310, in _wakeup
future.result()
File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
raise self._exception
File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step
result = coro.send(None)
File "/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
res = func(*args, **kw)
File "/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 1303,

vm_firewall_set
self.dest.firewall.save()
File "/usr/lib/python3.5/site-packages/qubes/firewall.py", line 588, in
save
self.vm.fire_event('firewall-changed')
File "/usr/lib/python3.5/site-packages/qubes/events.py", line 198, in
fire_event
pre_event=pre_event)
File "/usr/lib/python3.5/site-packages/qubes/events.py", line 166, in
_fire_event
effect = func(self, event, **kwargs)
File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
line 79, in on_firewall_changed
self.write_iptables_qubesdb_entry(vm.netvm)
File "/usr/lib/python3.5/site-packages/qubes/ext/r3compatibility.py",
line 158, in write_iptables_qubesdb_entry
iptables)
qubesdb.Error: (0, 'Error')

The rule in question does show up in qvm-firewall list, but I
think the new rule doesn't actually get applied.

As soon as I delete enough rules to not get the error, it feels like the
rules are all properly applied again, but I didn't test this
comprehensively yet.

It feels like I've hit some size limit? From the backtrace it looks like
the argument was an empty string: arg=b''. That seems suspect.

Any pointers on where I could look in order to understand the issue

better?

Thanks in advance,

Ralph

Which Qubes version are you using?
How many rules are you able to apply?
Have you looked at the docs?
https://www.qubes-os.org/doc/firewall

--
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/20190102024257.s2plx7ipmkydl3dk%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 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/cfa34648-fc69-b5d4-3b04-bd13fd79b996%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: dom0 error

2018-12-18 Thread David Hobach


On 12/18/18 7:28 PM, cooloutac wrote:

On Sunday, December 16, 2018 at 8:13:52 AM UTC-5, Roy Bernat wrote:

while trying to update dom0

getting error sys-firewall command failed with code 1

Roy


I'm getting the same thing.  Updates go through but just wondering why the 
error and if it should be a concern.


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

--
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/7130ca43-bc26-e74e-f988-e3f3b2f9259d%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: R4.0: sys-net, sys-firewall and other network VM(s) forced to always be on

2018-12-15 Thread David Hobach

On 12/13/18 8:10 PM, mike wrote:

On Thursday, December 13, 2018 at 2:52:06 AM UTC+2, reby wrote:

IIRC sys-net sometimes can be stubborn if one is not patient enough so
use qvm-kill if in a hurry . personally I don't see a downside of it
autostarting, though I guess one might have reasons to not want that,
any way

My sys-net starts when I log in to Qubes (not during boot as it would if it was
configured to start on boot). It also starts immediately after being shut down.
Same is for sys-firewall.
Maybe I wouldn't even have noticed that, because normally I want it to always
be on, but I currently have a particular reason I would like to shut it down
and can't. :)

Any VM used by another for networking will be started as dependency
whenever you start the other.

Moreover I guess the update checks might cause a network VM start.

If you have a lot of qvm-run calls pending in the background (e.g. if
you're doing dom0 scripting), it'll also cause the target VM to
constantly restart unless you used the -n option (which is not the default).

qvm-pause could be an option without these issues.

KR
David

--
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/6162a1f5-abf2-2cef-165a-1c0674113231%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.

smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] My farewell to Qubes OS!

2018-10-28 Thread David Hobach


On 10/27/18 7:26 PM, taii...@gmx.com wrote:

No!! comp-sci angel D: you are IMO the best computer security
person on the planet and now you leave us :'[


I wasn't too happy neither to see the presumably main Qubes visionary 
leave. Anyway I look forward to hear about new interesting topics from 
Joanna in the future and thank her for everything she's done in the past 
for the Qubes project!


And Marek has simply done an absolutely awesome job for the Qubes 
project in the past so that I bet this project will prosper further.



You can't trust the "cloud" - it will always be someone elses computer

SGX etc is DRM and a proprietary wintel technology that shouldn't be
trusted.


I'm also still waiting for someone to explain to me why I should trust 
some chip manufacturers in the cloud more than I do on my desktop, but 
that may well become one of these interesting topics...


--
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/6d81711a-02cc-80d5-3fbf-8323ab14e353%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

1 2 >

1 - 100 of 172 matches

Mail list logo