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


Re: [qubes-users] Custom LAN Network with dhcpd

2021-03-29 Thread David Hobach

On 3/29/21 10:36 AM, Frédéric Pierret wrote:

Hi,

Le 3/15/21 à 12:40 PM, 'Nyx' via qubes-users a écrit :

Hello,

I am trying to implement an internal Qubes LAN with HVMs that receive dhcp from 
a netvm using dhcpd. A classical network layout sort of speak. Reading Xen 
Networking makes it look possible but Qubes auto configuring the VM networking 
is being a bit troublesome for what I am trying to setup. Note that the entire 
network will be on Qubes only with no internet access.

The reason I am trying to set this up is I have some HVMs that are not getting 
an ip through dhcp and I cannot access them to set ip manually (they are 
vulnhub vms). I was thinking of just running an hvm with virtualbox but the 
limits of emulation only wont work. I read that qubes can be recompiled to 
enable nested virtualization to get that working but if there is a way to 
create a custom network that would be preferred.

Is there a way to allow a set of HVMs to get ip from a netvm running dhcp and 
communicate like a classic network?

--


You might be interested in such thing: 
https://github.com/fepitre/qubes-mgmt-salt-qubes-server/blob/devel-140320/qubes-server.png

I'm currently working on several adjustment recently (not pushed) but for you case, you 
might want to start by using usual "bridge" for which we have support of this 
in QubesOS-contrib:

dom0 component: 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device
vm component: 
https://github.com/QubesOS-contrib/qubes-core-agent-linux-addon-bridge-device

When this installed, in a given AppVM named for example "lan-net", with NetworkManager you can create a bridge interface named for example 
"br0" that will be made available as bridge device to be attached. Then, in dom0, running "qvm-device bridge" will show you the 
bridge created in "lan-net". At this point, this is exactly like USB, BLOCK or MIC devices. You can attach an AppVM named for example 
"personal" to this bridge (meaning it will have an interface that is linked into the bridge): "qvm-device bridge attach personal 
lan-net:br0". You can do that for multiple VMs, and then, you would have local classical network between several VMs. Even more, you can attach 
a physical interface into "br0" and link external network with other machines.

Notes:
  - It supports options like: "qvm-device bridge attach personal lan-net:br0 
--option=ip=192.168.0.1 --option=netmask=255.255.255.0 
--option=gateway=192.168.0.254"
  - Be careful that using standard bridge network model is NOT the Qubes model 
using NAT and based on isolation of each component.
  - You would need to probably adjust iptables if your "lan-net" has a NetVM.

I plan to make proper README and documentation describing this and also related 
Qubes-server formula soon. In the mean time I can help here or on discourse.


This also looks interesting.

An alternative that I learned about recently:
https://github.com/Rudd-O/qubes-arbitrary-network-topology

--
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/f52b46c4-89af-8bf5-fb32-6bf27e0491ef%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

--
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/755e0add-c426-8bc9-2473-3584410475fe%40hobach.de.


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.

--
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/9b2205cb-47b8-ff4d-1026-68b8941caf11%40hobach.de.


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.

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.

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

You might be interested in [1] and [2].

[1] 
https://github.com/Qubes-Community/Contents/blob/master/docs/customization/screenlockers.md
[2] https://github.com/QubesOS/qubes-issues/issues/1917

--
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/a68eb77e-7d4d-806f-ff15-2e61b51603a5%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature


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:




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.

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

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

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

in

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


Re: [qubes-users] Re: Replacement for Lenovo x230 (coreboot'able + high res)

2018-10-28 Thread David Hobach

On 10/27/18 12:42 PM, superriku11 wrote:

All of the **30 series ThinkPads were supported by Coreboot, last I checked.

The T430 has a 14-inch screen, but not FHD resolution like you would like. 
There is a screen replacement that some people have done to upgrade it to 1920 
x 1080.
http://www.thinkwiki.org/wiki/Replacing_T430_screen_with_a_better_one

If you'd rather not replace the screen, there's also a ThinkPad W530, which has 
a 15-inch screen, and you can get in OEM configuration with a 1920 x 1080 
resolution.


Sometimes you'll also find T530s with FHD, but they'll require some 
tinkering for coreboot (as usual I guess) and you'll want to have an 
IOMMU capable quad core for Qubes (which is less common).


--
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/25664eb6-48ae-46b6-7d77-75f79e5d563a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] nftables vs iptables

2018-10-10 Thread David Hobach

On 10/10/18 3:33 PM, unman wrote:

On Wed, Oct 10, 2018 at 03:17:47PM +0200, Illidan Pornrage wrote:

On 10/10/18 3:14 PM, unman wrote:

On Tue, Oct 09, 2018 at 09:18:22PM +0300, Ivan Mitev wrote:



On 10/9/18 7:44 PM, mfreemon wrote:

On 10/8/18 10:56 AM, mfreemon wrote:

On 10/2/18 2:25 AM, Ivan Mitev wrote:

On 10/2/18 1:32 AM, Chris Laprise wrote:

On 10/01/2018 05:48 PM, mfreemon wrote:

On 1/11/18 3:01 PM, Chris Laprise wrote:
    > On 01/10/2018 03:47 PM, Connor Page wrote:
    >> The official templates use nftables so shouldn’t be mixed with
iptables. I didn’t have time to learn about nftables, so just removed
nftables package from debian 9 template. YMMV.
    >
    > Hmmm, I was just thinking how Qubes' own guest scripts still use
    > iptables even in fedora-26.
    >
    > IIUC, iptables and nft are two different interfaces
to netfilter. I
    > don't know if it really matters, at least for the R4.0 window. I'd
    > prefer to put the syntax change (for docs) off until
a later release.

I was recently thrown by the mix of both nftables and iptables in R4.

The qubes docs don't clarify much.  The qubes firewall scripts use
nft. Most of the discussion on the qubes website documentation is
about iptables, but there are also a few mentions of nft.  The upgrade
instructions (going from R3.2 to R4) did not mention converting rules
from iptables to nftables.  It looks like other related projects (one
example is qubes-tunnel) is using iptables.

Just reading a few things and trying to come up to speed, I get the
impression that nftables and iptables should not both by used at the
same time.  Even if technically possible (i.e. both sets of rules
applied correctly), it strikes me as not a great idea to maintain
packet filtering rules in two different ways.

What is the best practice recommendation on this (for R4, Fedora 28
template)?  Are we to be using, exclusively, nftables in R4?


The last I read about this (for 4.0) is that nftables is used in Fedora
Qubes code, but Debian Qubes is still using iptables. That
still appears
to be the case since nftables is not installed in my
debian-9 templates.

I've submitted qubes-tunnel to Qubes with iptables commands only, with
the intention to transition to nftables (or that other new interface in
Linux, name escapes me just now) for Qubes 4.1. Someone who is just
starting a project might be better off going with nftables.


... until yet another packet filtering mechanism replaces nftables (in
that case, bpfilter [1]).

I understand the rationale behind using nftables [2] but given how it is
widespread (hint: close to 0 even amongst seasoned sysadmins) IMHO it
wasn't worth it. The OP's post confirms there's quite some confusion
about how it interacts with iptables, and the official documentation is
far from helpful.
I'm quite proficient with iptables and networking in general but it took
me half an hour to understand how to tweak Qubes' nftables rules last
time I wanted to change something in the firewall, while I would have
done that task in less than one minute with iptables. I could have spent
a few hours learning nftables to improve the official doc but at my age
I prefer to spend time learning tech that significantly improves things
(eg. Qubes OS over standard linux distribution) over loosing time
learning stuff that is only marginally better.
Anyway - I digress :)

[1] https://old.lwn.net/Articles/747551/
[2]
https://github.com/QubesOS/qubes-issues/issues/1815#issuecomment-245109500



I'm concerned about the confusion and unnecessary complexity here.

Network packet filtering is certainly (one of) those features that
software such Qubes needs to be solid on (in both design approach
and implementation detail).

Is the Qubes team confident in the current situation, such that
users of Qubes should not be concerned?

nb.  This is not meant to be a criticism at all.  I very much
appreciate the hard (and complicated) work going into Qubes.  I'm
just looking to understand the current situation better so as to
judge whether my concern is warranted or not.



As an example:  I'm wanting to enable some specific network traffic
between two qubes.  The docs say to use iptables 
(https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes).
   qubes-firewall-user-script also specifies iptables rules.  But
qvm-firewall implements the rules it manages using nftables.  So the
firewall VMs have both iptables rules and nftables rules in effect.  And
these are different sets of rules.  It's not that the iptables command
and the nft command are just two user interfaces showing the same packet
filtering rules.  They are different packet filtering rules.  This seems
like a receipt for disaster.

Is this the wrong forum for this discussion?  Should this be on
qubes-devel, or an issue in qubes-issues at
https://github.com/QubesOS/qubes-issues/issues?


You'll definitely get more visibility on qubes-devel.

FWIW I'm not concerned about the complexity itself: 

Re: [qubes-users] Re: 0.1 BTC bugfix bounty

2018-09-12 Thread David Hobach

On 09/12/2018 04:51 PM, Stickstoff wrote:

On 09/11/2018 03:52 PM, Thomas Papenkort wrote:

I have run into the same problem for backups when switching to qubes 4.0 and
found this workaround:

 # a file cannot be attached if it is in directory /var/lib/qubes/appvms, 
so create a link first
 ln /var/lib/qubes/appvms/$1/private.img /home/user/private.img
 LOOPDEV=`sudo losetup -f`
 sudo losetup $LOOPDEV /home/user/private.img
 qvm-block attach -o frontend-dev=xvds -o read-only=true backupvm dom0:$(basename 
"$LOOPDEV")

[backup happens here]

 qvm-block detach backupvm dom0:$(basename "$LOOPDEV")
 sudo losetup -d $LOOPDEV
 rm /home/user/private.img


Thank you a lot for your help!
I got it to work finally. In fact, it's a combination of the two details:
- get the .img file to another path. It can't stay in
"appvms/VMNAME/private.img". Get a hardlink elsewhere, or rename
"appvms" (and "vm-templates"), both are fine.
- you still have to delete the .qubes-exclude-block-devices file, if you
renamed "appvms" or the path to your hardlink contains this file.


Below in bash what I use since at least 4.0rc1.

Anyway what you're describing is considered a feature, not a bug (I 
recall when it was introduced as part of a bug report I had made in the 
beginning of 4.0rc1 about qvm-block not supporting files at all). I 
think it was a udev rule one-liner checking the path back then.


I'd suggest creating a feature request for a force flag bypassing it and 
maybe mention that you'd be willing to donate for that.


I'm not sure whether it's meant to be officially supported though as 
they might go away from sparse files with the recent introduction of 
qvm-pool etc. (wild guess).


KR
David

--

#createDomZeroLoopDeviceIfNecessary [dom0 path]
#returns: created loop device or previously used one (incl. /dev/); sets 
a non-zero exit code, if no device could be created
#create a loop device from the given file path in dom0, if necessary (no 
old one does exist)

function createDomZeroLoopDeviceIfNecessary {
local domZeroPath="$1"

#do we have a previously used device?
local oldDev="$(losetup -j "$domZeroPath" | grep -Eo '^/dev/loop[0-9]+')"

if [ -n "$oldDev" ] ; then
echo "$oldDev"
else
#no old device --> create a new one
#we use the exit code as ours
sudo losetup -f --show "$domZeroPath"
fi
}

#getVMDeviceNameForAttached [device in dom0] [VM]
#get the name for the device created in the given VM during execution of 
the qvmBlockAttachFromDomZeroTo function
#returns: name of the attached device in the given VM (without the /dev/ 
prefix) or an empty String, if no such device exists (not attached anymore)

function getVMDeviceNameForAttached {
local dev="$1"
local vm="$2"
local regex="^dom0:$dev\s+.*\s+${vm}\s+\(.*frontend-dev=([a-z0-9]+).*\).*$"

#run the regex against qvm-block & return the result
qvm-block l | sed -r -n "s/$regex/\\1/p"
}

#qvmBlockAttachFromDomZeroTo [result] [source path in dom0 (must be a 
file)] [target VM to attach the source path to] [optional: ro flag]
#[ro flag]: optional flag, that - if set to 1 - makes sure the file is 
attached as read-only to the target VM
#returns: device created in the VM as the result variable or an empty 
result variable in the case of errors

function qvmBlockAttachFromDomZeroTo {
local result="$1"
local path="$2"
local targetVM="$3"
local empty=""
local dev=""
local rwOption=""
[ $4 -eq 1 ] && rwOption="-o read-only=yes"

#default = error
eval $result="'$empty'"

#we need to create a pseudo file as Qubes 4.0rc1 will attempt to prevent 
qvm-block usage for its private.img files
#hard links work to bypass that, but need to be on the same drive (/tmp 
doesn't work)

local pfile="$DOM0_TEMP_DEV_PATH/$(echo "$path" | md5sum | cut -d " " -f1)"
ln "$file" "$pfile"

#unfortunately qvm-block l has issues for files, so we create a loop 
device first and use that one
#also see: R3.0: qvm-block doesn't work well on files 
(https://groups.google.com/forum/#!msg/qubes-users/IotETu-gsm4/FO2GOu5pBwAJ)

#for 4.0rc1 I'm not even sure whether it supports files...
dev="$(createDomZeroLoopDeviceIfNecessary "$pfile")"
[ $? -ne 0 ] && return
dev="${dev/\/dev\//}"

#run qvm-block
qvm-block a $rwOption "$targetVM" "dom0:${dev}"
[ $? -ne 0 ] && return

#get the return value and update the return var
lastAttached="$(getVMDeviceNameForAttached "$dev" "$targetVM")"
eval $result="'$lastAttached'"
}

--
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/7a79d289-656c-21fc-2c06-c1a91f7d6c97%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME 

Re: [qubes-users] QSB #42: Linux netback driver OOB access in hash handling (XSA-270)

2018-08-26 Thread David Hobach

On 08/14/2018 09:12 PM, Andrew David Wong wrote:

Patching
=

The Xen Project has provided patches to fix this issue.

The specific packages that resolve the problems discussed in this
bulletin are as follows:


[..]


   For Qubes 4.0:
   - kernel packages, version 4.14.57-2
   - kernel-latest packages, version 4.17.9-2


[..]


   For updates from the stable repository (not immediately available):
   $ sudo qubes-dom0-update


Were these pushed to stable yet? Because I don't see them, but maybe my 
update is broken...


If not, when is that likely to happen?

Thanks for the good description though!

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 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/129c3ea8-261a-84ce-169d-980005c67d81%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] Any way to attach a USB drive to a VM by label?

2018-05-19 Thread David Hobach

On 05/19/2018 01:04 AM, Qubes Guy wrote:

On Friday, May 18, 2018 at 5:59:09 PM UTC-4, David Hobach wrote:

On 05/18/2018 08:19 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, May 17, 2018 at 05:57:09PM -0700, Qubes Guy wrote:

I've successfully used qvm-block (in Dom0) to attach USB drives to different VMs 
(persistently), but I've noticed that Qubes (or Linux) sometimes gives them to different 
devices over time. In other words, on Monday, my BIG_TOSHIBA drive will be on /dev/sda, 
but it'll be assigned to /dev/sdj when I boot up on Wednesday. This is throwing off my 
VeraCrypt / FreeFileSync backup routine. (Another way of saying this is if I say 
"qvm-block attach MyVM sys-usb:sda --persistent" when one of the three drives I 
use for MyVM is currently attached to that, this will fail if Qubes moves that drive to a 
different device-name (during boot) that isn't one of the three I previously attached 
(when I go to start up that VM).

I thought about persistently attaching all 10 of my USB drives to the VM (some HDs, some 
flash, one SSD - I never use all of them at once - don't ask!) because that would 
certainly fix this problem, but I get the following error when I try to start the VM: 
"ERROR: Start failed: XML error: target 'xvdi' duplicated for disk sources 
'/dev/sdc' and '/dev/sde', see /var/log/libvirt/libxl/libxl-driver.log for details".

Note that I did all the persistent attachment commands while the VM was not running. If I 
detach all those, start the VM, do the persistent attachments, shut down the VM and then 
restart it, I get an error along the lines of "qrexec process failed to respond in 
60 seconds".

So, I guess I'm asking if there's a way to just persistently attach 2 or 3 external 
USB drives and have them consistently available on the same device names when I 
start the VM so VeraCrypt doesn't balk?  (VeraCrypt ultimately doesn't care what 
device a drive is attached to (it could be sda - sdj on my system) because it shows 
the attached drive as "/media/user/BIG_TOSHIBA, but if a drive isn't where it's 
supposed to be, that'll fail.

In case you're curious, the error messages in 
/var/log/libvirt/libxl/libxl-driver.log are meaningless to me, but if you want 
me to post it, I can.

Any help you guys can give me would be greatly appreciated! Thanks...


It isn't available yet, related issue:
https://github.com/QubesOS/qubes-issues/issues/3437


As a workaround you could mount the device via uuid or file system label
in sys-usb, create a loop device from the container you want to pass to
another VM and use qvm-block on that loop device (for which you can
define the name yourself).

Of course that's only convenient if you script it...


Thanks, but how do you do create a loop device? I'm (mostly) a Linux newbie 
(and, as of 5 weeks ago, I was a Qubes newbie) - I'm your worst nightmare :)  I 
tried the UUID mount thing described in the article I mentioned above, but it 
just prevents sys-net from starting, but maybe with this loop thing you 
mention? Can you give me the actual commands required, or direct me to an 
article showing this? I'm not even sure what to search for. Thanks much!


Honestly you'll probably be off better by waiting for the feature to be 
implemented then.


Anyway for reference I was talking about something like

in your sys-usb:
1. mount -U [uuid] [mount point]
2. losetup -f --show [your veracrypt file on the mounted file system]

in dom0:
3. qvm-block a [target VM] "sys-usb:[output of 2]"
4. Open the veracrypt block device now attached to [target VM]. (luks 
supports that, not sure about veracrypt)


You can script all of that from dom0 using qvm-run. Essentially the idea 
was to attach the Veracrypt file to [target VM] instead of attaching the 
USB device itself.


qvm-block also supported files itself in 3.2 (i.e. 1. & 2. could be done 
with qvm-block), but from my experience that didn't work so well in the 
past.
In 4.0 it was then removed I think; qvm-block -p [target VM] [some file] 
would have made for some really interesting applications such as the one 
described above without much need for scripting.


--
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/f3ba3bf3-4a30-f45a-6ce6-7a06ac57ed60%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] Pass I/O option from qvm-run - In Depth Knowlege?

2018-05-18 Thread David Hobach

On 05/16/2018 05:51 PM, cr33dc0...@gmail.com wrote:

Hello All,

Often used the -p or -pass-io option in the past and wanted to get some deeper 
knowlege how this actually works, if or what xen based techniques are behind it 
and so on.

Sadly the only thing i found was: "Pass stdin/stdout/stderr from remote 
program".
In some forums they talked about opening something like a io-tunnel to pass 
trough the Dom0. (When using qvm-run -p to transfer files between appvms)

If someone knows a bit more than this or can confirm and explain that tunnel 
thing to me, i would be very pleased.


Good question, but I guess the code itself will provide the best answers.
You'll probably have to have a closer look at the qrexec framework. [1]

You shouldn't use -p without some caution in your scripts though as 
passing stdin can lead to unexpected leaks from dom0 to an AppVM.

So if you don't need stdin passing, it would be good practice to use
qvm-run -p [..] < /dev/null
[2]

[1] https://www.qubes-os.org/doc/qrexec3/
[2] https://github.com/QubesOS/qubes-issues/issues/3074

--
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/ef1dbd98-deb6-d070-b8c8-f0423b775627%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] Any way to attach a USB drive to a VM by label?

2018-05-18 Thread David Hobach

On 05/18/2018 08:19 PM, Marek Marczykowski-Górecki wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, May 17, 2018 at 05:57:09PM -0700, Qubes Guy wrote:

I've successfully used qvm-block (in Dom0) to attach USB drives to different VMs 
(persistently), but I've noticed that Qubes (or Linux) sometimes gives them to different 
devices over time. In other words, on Monday, my BIG_TOSHIBA drive will be on /dev/sda, 
but it'll be assigned to /dev/sdj when I boot up on Wednesday. This is throwing off my 
VeraCrypt / FreeFileSync backup routine. (Another way of saying this is if I say 
"qvm-block attach MyVM sys-usb:sda --persistent" when one of the three drives I 
use for MyVM is currently attached to that, this will fail if Qubes moves that drive to a 
different device-name (during boot) that isn't one of the three I previously attached 
(when I go to start up that VM).

I thought about persistently attaching all 10 of my USB drives to the VM (some HDs, some 
flash, one SSD - I never use all of them at once - don't ask!) because that would 
certainly fix this problem, but I get the following error when I try to start the VM: 
"ERROR: Start failed: XML error: target 'xvdi' duplicated for disk sources 
'/dev/sdc' and '/dev/sde', see /var/log/libvirt/libxl/libxl-driver.log for details".

Note that I did all the persistent attachment commands while the VM was not running. If I 
detach all those, start the VM, do the persistent attachments, shut down the VM and then 
restart it, I get an error along the lines of "qrexec process failed to respond in 
60 seconds".

So, I guess I'm asking if there's a way to just persistently attach 2 or 3 external 
USB drives and have them consistently available on the same device names when I 
start the VM so VeraCrypt doesn't balk?  (VeraCrypt ultimately doesn't care what 
device a drive is attached to (it could be sda - sdj on my system) because it shows 
the attached drive as "/media/user/BIG_TOSHIBA, but if a drive isn't where it's 
supposed to be, that'll fail.

In case you're curious, the error messages in 
/var/log/libvirt/libxl/libxl-driver.log are meaningless to me, but if you want 
me to post it, I can.

Any help you guys can give me would be greatly appreciated! Thanks...


It isn't available yet, related issue:
https://github.com/QubesOS/qubes-issues/issues/3437


As a workaround you could mount the device via uuid or file system label 
in sys-usb, create a loop device from the container you want to pass to 
another VM and use qvm-block on that loop device (for which you can 
define the name yourself).


Of course that's only convenient if you script 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 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/171dd679-5f63-32a1-98a4-ed93c97eadbf%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] Re: Lenovo G505S Coreboot

2018-04-20 Thread David Hobach



On 04/20/2018 12:21 PM, River~~ wrote:

correction where I said



My assumption is that the time is explained by the fact that it is not
only booting the physical machine but also the various CMs that are tagged
to be started at bootup.



I meant VMs, not CMs



correction where I said


My assumption is that the time is explained by the fact that it is
not only booting the physical machine but also the various CMs that
are tagged to be started at bootup. 



I meant VMs, not CMs


Yes, it tends to be 7s for normal booting with SSD and 30s+ for the VMs 
- that's normal. There is a feature request [1] out there to get the VMs 
started after X instead of before. So that might change in the future.


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

--
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/78ab7eae-1279-0bb0-af0d-6d4321127c9c%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


[qubes-users] Tester needed: AMD CPU Microcode update

2018-04-20 Thread David Hobach

Dear users,

the project currently requires a tester for 
https://github.com/QubesOS/qubes-issues/issues/3703
(see the comment by marmarek 
https://github.com/QubesOS/qubes-issues/issues/3703#issuecomment-381369180)


It would be really nice if someone could help out.

Thanks & 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/7d9a7061-6cfd-1c17-bd3a-82cbbf0c56e9%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] DNS propagation in Qubes

2018-03-13 Thread David Hobach

On 03/13/2018 07:14 AM, Alex Dubois wrote:

On 12 Mar 2018, at 18:40, David Hobach <trip...@hackingthe.net> wrote:


On 03/11/2018 03:15 PM, David Hobach wrote:
An alternative might be to setup the local DNS service in a VM closer to the 
Internet, i.e. not in the proxy VM which also implements the qubes firewall.
Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw 
<-- client VM
I didn't test that though.


I just tested that as well now and it works as expected without any of the 
aforementioned caveats.

So I'd recommend the one above over the previously discussed
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
(at least I was talking about that architecture - maybe the others were talking 
about something different...).
The same holds true for VPN users.


This type of architecture is bad practice as the attack surface of DNS is 
bigger than Qubes firewall, and an attack on this daemon compromise all 
traffic, not just DNS.

A better arch is
Internet
- netVM
- - firewallVM
- - - Service (ie DNS or VPN)
- - - clientVM1
- - - clientVM2


I believe your essential point was not to use proxy VMs for services at all.

My main point was not to mix a Qubes Firewall VM with local services. I 
think you basically agree with that.


I however also disagree with your point wrt proxy VM usage as there's no 
attack vector for E2E encrypted traffic on proxy VMs except for DoS 
which you'll notice.
If you're using non-E2E encrypted traffic (except for maybe DNS) you 
have a different problem altogether and even then I'd trust my proxy VM 
a lot more than any other hop (your Wifi provider? the 4+ backbone 
providers you pass?) on the route to the destination.


Moreover it is rather inconvenient to configure each and every client VM 
to use that service VM which can also lead to unexpected 
misconfigurations & leakages.


--
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/e117d09a-974c-904d-2532-b890b2c77008%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] DNS propagation in Qubes

2018-03-12 Thread David Hobach

On 03/11/2018 03:15 PM, David Hobach wrote:
An alternative might be to setup the local DNS service in a VM closer to 
the Internet, i.e. not in the proxy VM which also implements the qubes 
firewall.


Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM 
with qubes-fw <-- client VM


I didn't test that though.


I just tested that as well now and it works as expected without any of 
the aforementioned caveats.


So I'd recommend the one above over the previously discussed
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
(at least I was talking about that architecture - maybe the others were 
talking about something different...).

The same holds true for VPN users.

I also documented this at 
https://github.com/QubesOS/qubes-issues/issues/3051


--
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/b1482304-c9c8-11d6-c988-4adcc737380b%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] DNS propagation in Qubes

2018-03-11 Thread David Hobach

On 03/11/2018 03:03 PM, David Hobach wrote:
So yes, if one is aware of that issue, one can certainly use it the way 
you described. If you rely on the qubes-firewall to work as expected, 
you shouldn't use it.


P.S.:
An alternative might be to setup the local DNS service in a VM closer to 
the Internet, i.e. not in the proxy VM which also implements the qubes 
firewall.


Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM 
with qubes-fw <-- client VM


I didn't test that 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 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/ec054435-0c3c-9517-f02f-f9c2c50c19a8%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] DNS propagation in Qubes

2018-03-11 Thread David Hobach

On 03/11/2018 11:21 AM, Chris Laprise wrote:

...and for now omitted the '-d' destination part in iptables.

Then if I issue:


sudo iptables -t nat -F PR-QBS
sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to 
$eth0_address
sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to 
$eth0_address


it appears to work from a downstream appVM. But I haven't checked yet to 
see if its really using the dnscrypt proxy; even if it is, the config 
may need to be adjusted for better security.


I just tested that one (my implementation was also doing pretty much 
exactly that + a local INPUT chain firewall so it was a 5 min test 
removing the INPUT firewall):


Since you'll need something like

-I INPUT -p udp -m udp --dport 53 -j ACCEPT
-I INPUT -p tcp -m tcp --dport 53 -j ACCEPT

it makes DNS accessible for all downstream VMs regardless of the 
qubes-firewall settings, i.e. apprently the nft FORWARD rules are not 
applied for DNAT to localhost.


That's probably why I had opened that github issue & implemented a local 
firewall back then...


You can verify my findings by using the dom0 qvm-firewall command line 
to revoke DNS access for a downstream VM & then use e.g. dig in that VM. 
The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always allowed.


So yes, if one is aware of that issue, one can certainly use it the way 
you described. If you rely on the qubes-firewall to work as expected, 
you shouldn't use 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 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/ba33e227-187d-4945-6b51-d1ef0093d21a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [qubes-users] DNS propagation in Qubes

2018-03-08 Thread David Hobach

On 03/07/2018 06:40 PM, Unman wrote:

On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:

I'm trying to make all DNS requests in Qubes go over TLS (more information 
about this [1]).

I've got this successfully working in sys-net by running a local DNS server on 
udp 53 that forwards DNS requests to a remote DNS server over TLS, and then 
setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed 
that this works great in sys-net -- all of my DNS requests are encrypted to my 
remote DNS server, and none are plaintext.

The problem is when I do this, DNS in other downstream VMs all fail. The Qubes 
networking docs [2] explain how DNS works in Qubes, but I'm confused about how 
to make this set up work. Any ideas? Thanks!

[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/



In sys-net you have PR-QBS chain in nat table that redirects DNS
requests to the network DNS server.

You'll need to remove that chain and replace it with one directing DNS
traffic to the local server.
You'll also need to open the udp port to inbound traffic.


If you do that, you'll lose any qubes firewall-based control on DNS 
traffic though. I.e. all of your downstream VMs will have DNS access.


Essentially you'll have to implement your own local version of the qubes 
firewall to achieve qubes-firewall support. I happened to have done that 
some time ago, but the code quality is not good enough to share it 
(sorry). nft usage in 4.0 further complicates it from my point of view. 
You could try to move the forward chain rules to the input chain on 
every firewall change...


Maybe qubes will support it one day; here's the feature request: 
https://github.com/QubesOS/qubes-issues/issues/3051
I'm not sure why it got tagged as doc though - maybe I didn't see the 
obvious solution.


--
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/e60f357b-99ed-fa8d-8909-978200662b95%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature


  1   2   >