A lot of trouble with qubes 4.0 rc2

[Bernhard]

Hello,

I jumped into cold water and have a fresh install of 4.0rc2. It seems
almost completely disfunctional at this stage. Problems are:

1) starting (larger) appvms result in a systematic qrexec-daemon error.
First I thought this would be debian specific, but it is not. I have 16G
ram, and try to start a single f25 based appvm ... I read some people
suggesting to install xen-hvm-stubdom-linux 2001:4.8.2-10.fc25 -- I
tried this, but no notable change (after coldboot). I tested if HVM / PV
could help. Quick answer: No.

2) I created a large (150G) personal appvm. The "max system storage" is
still 10G and I don't see how/where this could be changed. When
playing back backups, the fs is de facto limited to these 10G - so rsync
fails at some stage; from this moment on reboots fail as well (with
qrexec-error). journalctl gives no help (the journal keeps silent while
launching "qvm-start personal" in the neighbour terminal).

I hope I can get some help here, since I will have to reinstall 3.2
otherwise :(

Thank you, Bernhard

[Chris Laprise]

On 11/20/2017 12:16 PM, Bernhard wrote:
> Hello,
>
> I jumped into cold water and have a fresh install of 4.0rc2. It seems
> almost completely disfunctional at this stage. Problems are:
>
> 1) starting (larger) appvms result in a systematic qrexec-daemon error.
> First I thought this would be debian specific, but it is not. I have 16G
> ram, and try to start a single f25 based appvm ... I read some people
> suggesting to install xen-hvm-stubdom-linux 2001:4.8.2-10.fc25 -- I
> tried this, but no notable change (after coldboot). I tested if HVM / PV
> could help. Quick answer: No.

If possible, you should try doing a full update with testing release:

qubes-dom0-update --enablerepo=qubes*testing

> 2) I created a large (150G) personal appvm. The "max system storage" is
> still 10G and I don't see how/where this could be changed. When
> playing back backups, the fs is de facto limited to these 10G - so rsync
> fails at some stage; from this moment on reboots fail as well (with
> qrexec-error). journalctl gives no help (the journal keeps silent while
> launching "qvm-start personal" in the neighbour terminal).

System storage (the template) is different than private storage, and I
believe its the latter you should be concerned about. Not sure just how
you are using rsync... a lot depends on what your source and target are.

--

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

[Bernhard]

On 11/20/2017 09:34 PM, Chris Laprise wrote:
>
> If possible, you should try doing a full update with testing release:
>
> qubes-dom0-update --enablerepo=qubes*testing

Thank you for helping me. I'll try this out quickly & tell (all of) you
on this list.

>> 2) I created a large (150G) personal appvm. The "max system storage" is
>> still 10G and I don't see how/where this could be changed. When
>> playing back backups, the fs is de facto limited to these 10G - so rsync
>> fails at some stage; from this moment on reboots fail as well (with
>> qrexec-error). journalctl gives no help (the journal keeps silent while
>> launching "qvm-start personal" in the neighbour terminal).
>

> System storage (the template) is different than private storage, and I
> believe its the latter you should be concerned about. Not sure just
> how you are using rsync... a lot depends on what your source and
> target are.
>

Here is my procedure: I have a usb disc. I attach it to the appvm, loop
the luks container to /dev/loopX, cryptsetup luksOpen it, and mount then
the /dev/mapper/backup . Then I use (as root) rsync -auv
/backup/appvm-name /home/user/ . The data is 140G so I gave 150G to
the appvm as private storage. The rsync fails after ~6GB of data
transferred. Is this possble since the (standard install) LVM-thin
cannot provide quickly enough disc space??

Alternatively I can start the appvm, pause it, attach its private.img
to sys-usb and follow then the above procedure as root in sys-usb (this
is how I made the backups, since I prefer doing them by hand).

Is there some flaw in my procedure? Thank you, Bernhard

[Bernhard]

Hello,

I brought myself in trouble, when I (badly) followed the vm-sudo
instructions : as non-root, I modified (using each time sudo) the file
/etc/pam.d/common-auth in debian-8.
Now, at the follwoing steps I would need to sudo again - but the process
is blocked (saying 3 times bad password), since the new VMAuth is (only)
partially set up.

- Of course, qubes-revert command for template vm does not exist in Q4,
that would be too easy.
- Actually, reinstalling debian-8-template fails as well, since there
seems no package named qubes-template-debian-8 in contrast with the
qubes documentation
- So I would like to "break in" the vm-template as dom0, and change
that one line in /etc/pam.d/common-auth back. But how to mount the
root.img file? I tried a losetup & mount approach, but the file is
non-mountable. I have not found any documentation either.

So I ask in despair for some help. Bernhard

[Bernhard]

> So I would like to "break in" the vm-template as dom0, and change
> that one line in /etc/pam.d/common-auth back. But how to mount the
> root.img file?

I answer my own question, since this is more easy & efficient than I
thought, and should help others in many cases!

(0) make sure template-vm is halted.
(1) as dom0 root:
(a) fdisk -l path-to-root.img
Then read off the start sector of ...root.img3, (say,
1000). Multiply that value with 512 (512000 in my example).
(b) mount -o loop,offset=512000 path-to-root.img /mnt
(change 512000 by your value)
(c) modify bad config files
(d) umount /mnt
(2) restart template-vm

and we're back! Bernhard

[Chris Laprise]

Glad you recovered OK. The best way to execute the vm-sudo instructions
is to switch to root user first with 'sudo su'. Notice that all the
shell prompts in the document are '[root@vmname]#'.

[Chris Laprise]

On 11/22/2017 10:01 AM, Chris Laprise wrote:
>
> Glad you recovered OK. The best way to execute the vm-sudo
> instructions is to switch to root user first with 'sudo su'. Notice
> that all the shell prompts in the document are '[root@vmname]#'.
>

BTW I have a project Qubes-VM-hardening that uses vm-sudo configuration
to leverage template-based security. Its an added layer of protection
against malware persistence.

The master branch currently only deals with user init scripts, but the
systemd branch has some more interesting things in development, like
white-listing.

https://github.com/tasket/Qubes-VM-hardening

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Nov 22, 2017 at 11:02:11AM +0100, Bernhard wrote:
> Hello,
>
> I brought myself in trouble, when I (badly) followed the vm-sudo
> instructions : as non-root, I modified (using each time sudo) the file
> /etc/pam.d/common-auth in debian-8.
> Now, at the follwoing steps I would need to sudo again - but the process
> is blocked (saying 3 times bad password), since the new VMAuth is (only)
> partially set up.

I see you've already managed to fix the issue, but for anyone else: you
can access root using qvm-run command. For example:

qvm-run -u root debian-8 xterm

> - Of course, qubes-revert command for template vm does not exist in Q4,
> that would be too easy.

There is qvm-volume tool that provide similar functionality:

qvm-volume revert debian-8:root

But in default setup, no previous state is preserved, so there is
nothing to revert to...
https://github.com/QubesOS/qubes-issues/issues/3256

> - Actually, reinstalling debian-8-template fails as well, since there
> seems no package named qubes-template-debian-8 in contrast with the
> qubes documentation
> - So I would like to "break in" the vm-template as dom0, and change
> that one line in /etc/pam.d/common-auth back. But how to mount the
> root.img file? I tried a losetup & mount approach, but the file is
> non-mountable. I have not found any documentation either.
>
> So I ask in despair for some help. Bernhard
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJaHuXvAAoJENuP0xzK19csFA0IAIfV3qM/dK7k5mTQNpWazzDJ
5rd5x4lAq3hmAZC6PB1I9vG2kxxEzWrobGA01eFFOUYYrKffIoHXPSpRPVwNs3jw
VxnhvyuOFHnzBGYUFSZXUyE9r+rm6E43ByhX3BmNQhIHrMvSM7aA3jgiysGgO/Oq
+d73T47gT2fxVsfyTSg56A38FAQAzUSnBefCAxylE7XhqHT8qOYihogGMljAf01S
V+lEw/mfWEKH+dl2N+zw8LhNqICGi6+eqjhbFADptpz0wITKsgNKCF7ZWwJOGnPE
vzSzdVrazgmilRaqpD6YcaZEvs549Ydz4LrkxjKo0Hp0WnppL+rodTXTK78nqDk=
=AOXj
-----END PGP SIGNATURE-----

[haaber]

>
> I see you've already managed to fix the issue, but for anyone else: you
> can access root using qvm-run command. For example:
>
> qvm-run -u root debian-8 xterm
>

That is pretty cool and quick I admit. Notice however that my solution
works even in a no-longer starting template (if this problem is due to
config files). In more complicated situations one could even install a
clone of a damaged system, chroot from the working one into the damaged
one to run apt-get .. best, Bernhard