a-barinov / liteqube Goto Github PK

apparently, something is wrong with my freshly created core-tor. i cannot qvm-run anything (hangs forever) and there is no way I can diaglose what happens inside, but it certainly does not provide network and other qubes say they cannot access netvm properly.

UPD:
watching the installation process, core-tor tries to send some wifi-related rpc request to core-net, fails and shuts down. no idea what it is!

it keeps being a mystery to me exactly how it is non-functional. tried adding more memory or private disk -- no change.
nothing suspicious in the console log, either. just qrexec and network refuse to function! apparently even tor starts fine.
I can qrexec to debian-core itself, but not to any VM based on this template! also when I qvm-run to core-dvm I get an error message immediately, but for, say, core-keys, it just hangs there forever.

When attempting to update templates based on Fedora or Debian, Dom0 throws the following error:

Error on updating t-browser: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=TEMPLATENAME', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 1.
t-browser: ERROR (exception Failed to copy Salt configuration to disp-mgmt-TEMPLATENAME')

I've reinstalled default-mgmt-dvm using the salt script, have changed the template of default-mgmt-dvm to Debian 11 (from the default debian-core), Fedora 37 and Kicksecure 16, and have not yet figured out how, if at all possible, to change the template for default-mgmt-dvm to core-update. <---none of those changes have worked.

I'm using the latest Qubes release and can update all templates independently through dnf/apt-get in their own terminals.

Thanks so much for your work on this @a-barinov; aside from its usefulness, reading through the scripts and walking through the prcessess have been a great learning experience.

I wonder if the below would be of interest, installed as part of 1.Core or 2.Network and placed as another lq-script within /bin. I've found this to be an excellent, fast, easy experience and goes a long way toward plausible deniability (in part, one of your post 1.0 release goals) and keeps the system lean.

#!/bin/bash
#A script to create, launch, and clean up a truly disposable QubesOS qube for secure browsing.
#Tor browser can be replaced with your browser or template of choice.
#Just check the variables or add your own.
#This script assumes you have a kicksecure TemplateVM
#Inspired by unman: https://github.com/unman/notes/Really_Disposable_Qubes.md
#

set -e

TMP_DIR="/home/user/tmp"
TMPFS_SIZE="5G"
QUBE_NAME="shadow"
NET_VM="sys-whonix"
TEMP="kicksecure-16"
BROWSER="torbrowser"
MEM="1000"

if qvm-check "${QUBE_NAME}" > /dev/null 2>&1; then
        echo "A qube named \"${QUBE_NAME}\" already exists. Exiting."
        exit 1
fi

sudo swapoff -a
mkdir -p "${TMP_DIR}"

sudo mount -t tmpfs -o size="${TMPFS_SIZE}" shadowy "${TMP_DIR}"
qvm-pool add -o revisions_to_keep=1 -o dir_path="${TMP_DIR}" shadowy file
qvm-create "${QUBE_NAME}" -P shadowy -t "${TEMP}" -l red --property netvm="${NET_VM}" --property memory="${MEM}"
qvm-run -a "${QUBE_NAME}" "${BROWSER}"
wait

qvm-kill "${QUBE_NAME}"
qvm-remove -f "${QUBE_NAME}"
qvm-pool rm shadowy
sudo umount shadowy
sudo rm -rf "${TMP_DIR}" \
        /var/log/libvirt/1ibx1/new.log \
        /var/log/libvirt/1ibx1/new.log.old \
        /var/log/qubes/vm-new.log \
        /var/log/qubes/guid.new.log \
        /var/log/qubes/guid.new.log.old \
        /var/log/qubes/qrexec.new.log \
        /var/log/qubes/qubesdb.new.log \
        /var/log/qubesdb.new.log \
        /var/log/guid/new.log \
        /var/log/qrexec.new.log \
        /var/log/pacat.new.log \
        /var/log/xen/console/guest-new.log

notify-send -t 5000 "${QUBE_NAME} qube" "${QUBE_NAME} qube remnants cleared."

Happy to chat more or tweak it into one of the install scripts wherever you suggest.

1. Fresh Qubes 4.1.0 installed.
2. Downloaded and transferred liteqube-0.91.tar.gz to dom0 and unpacked it.
3. Run install.sh script in '1.Base'.
   
   

Everytime it stops at this point.

What am I doing wrong?

As title says, using main branch fails with the chmod error:
unable to chmod +x ~/bin/lq-xterm - file not found

I was able to fix this by commenting out in .lib/lib.sh the following code (at line 256):
#chmod +x "~/bin/${_FILE}"

Afterwards the installation worked without a hitch. Auto-connect works now, no issues with upgrades, even my realtek wireless doesn't complain or fail at current 240 MB of RAM for the core-net. I'm going to experiment more with USB, VPN and sound qubes, and test liteqube impact on the battery.

how do I get a whonix like experience with tor-browser using fw-tor? I tried attaching a whonix-ws vm to fw-tor but doesnt seems to work. On the other hand if I attach a standard firefox from a debian vm, the traffic gets redirected trough tor but this setup lacks all the added protections from tor-browser.
Great work with liteqube, thanks a lot

I'm trying the vpn-ssh functionality but I find it very unstable. At first I couldn't connect at all, failing on the split-ssh part.
After some tinkering I increased the memory available to core-keys and core-vpn-ssh and worked ok for a while but after a few minutes I lost connection again.
Core-keys keeps shutting down by itself, then the split-ssh dialog appears, turns on core-keys and maybe restores connectivity for a little while or, I believe some timeout happens and no connection is made.
I turn on core-keys manually at boot because I want it to be ready every time I need it. I don't know if the shutting down behavior is intended (turn on, split-something, turn off) or it's something failing..
Please advise

Also a few things to note:

• I left a ping running from the client vm and it never stops, making me think icmp is never routed trough the vpn.
• It is really necessary for the vpn-ssh vm to be disposable? Maybe having some little private storage could allow to have more than one vpn vm with different configurations and not pollute debian-core with vpn settings. It could be read-only.
• Are you planning on write a more detailed documentation? I can help you with that

regards

This is a very interesting project. Thank you for working on it.

If I may suggest, an improvement in overall code quality would make this good work even better. After all, this is something which one is supposed to run in dom0 and it is good to have the possibility to go through it easily before using it. Personally, it took me more than 2 hours to check /.lib only (and I write bash scripts almost every day).

While there is no unified standard about shell script coding, there are some good practices. To name a few (not a complete list):

1. Don't use VAR_NAMES_IN_CAPS. Use lowercase_name instead. This avoids the potential problem of conflicting environment variable names (which are uppercase).

2. Use local variables whenever possible

my_function()
{
	local my_var="${1}"
	...
}

and you won't need to use cryptic prefixes like _VRP_SIZE.

3. I think [ x"$a" = x"$b" ] is outdated. The preferred way (especially if you use Bash which is installed in dom0) is [[ "${a}" = "${b}" ]].

4. If you need to comment what the code does (e.g. # Check if file exists), this means the code is not readable. Commands and variable names should speak for themselves. Comments should explain why something is done, not what is done.

5. Don't write complex nested loops and ifs (like in .lib/check-with-local.sh). Complex code is not only difficult to read but also difficult to maintain.

6. Limit line length to 80. It's more readable.

7. The result of any code execution should be predictable even in unpredictable situations and handled properly.

8. Exit early.

E.g. this:

my_function()
{
	if [ -e "${some_file}" ]; then
		add_line dom0 "some" "thing"
	else
		add_line dom0 "something" "else"
	fi
}

is better written as:

my_function()
{
	if [ -e "${some_file}" ]; then
		add_line dom0 "some" "thing"
		return
	fi
	add_line dom0 "something" "else"
}

9. Short lines and vertical orientation are more readable.

This:

command arg1 \
	arg2 \
	arg3 \
	| another_command \
	| third command
fourth_command

is more readable than this:

command arg1 arg2 arg3 | another_command | third command'; fourth_command

10. Check your scripts with ShellCheck

And so on. There are some good books about general code readability.

Please also add a license, so others can contribute.
Keep up the good work!

The author is a bit hard to contact, and to maintain a viable fork just in case the code gets unmaintained, we need to clarify the license terms. I assume this project inherited GPL3 from https://github.com/tasket/Qubes-VM-hardening , right?

There is "sudo -u user" in multiple places.

I got this error during installation. I had also to install e2fsprogs by hand.

I ran the install script within 1.Base, then attempted to run the install script from 2.Network, but received an error saying the disposable qvm wasn't installed. I rebooted the machine. Now I cannot access any VM, any dom0 application other than terminal, and the base uninstall script threw an error. I'm unable to use my system. Qvm-start from dom0 yields endless errors. Short of a fresh install, what are my options to recover my system?

I tried and it mostly works. Except core-tor is giving me issues and I am not sure how to diagnose it properly because I lack knowledge about how transparent torification is supposed to work in normal way.

Hello,

Installed liteqube 1.Base, 2.Network and 3.USB without issues.
However, despite the USB controller previously attached to sys-usb (debian) being successfully reallocated to core-usb, no USB devices are found in the qube, nor even reported in dom0.

I'm not sure what logs or commands' output to give you for debugging my case (or helping me find what's wrong0. Don't mind asking what you need.

Thanks

tmpfs would be nice. Fedora updates could be several gb at one batch and it is very easy to run out of space.

What makes Qubes unsuitable for non-geek audience could be fixed in liteqube! The problem is, when "something" fails, we do not know what happened -- or did it at all. I suggest making a self-diagnostic tool that could be run periodically to detect common error conditions and warn user (or even take some actions), like:

• if network works
• if tor works
• if time sync works
• if core services did not run out of disk space on any fs
• if OOM killer damaged something in any core VMs
• if input devices are available to dom0
• if core-usb did not get 100% cpu load because of stupid "control queue full" bug (who was that idiot who made a handler that works that way?)
• if core-audio has audio device
• if client VMs can connect to core-audio
• if there is enough space in vm pool
• if there is enough RAM to start a new VM

did I miss something?

Got my connection killed by OOM yet another time and.. why do we need NM at all? The applet we already got rid of, so it makes total sense to stick to generic dhcp and that would be it.

This is not your typical issue report, so let me first express my gratitude for all that you have done so far regarding the Liteqube development.

I believe this is what the Qubes have always needed. It’s not perfect solution and there are some issues, however I’m quite happy how it turned out. It wasn’t a smooth ride to get it all working as described, but not all the problems were caused by the script.

I’m one of those users that also likes the mc file manager. Reminds me of old times from MS DOS era, when Norton Commander was the thing. It is a good tool, but in some cases can make some major headaches and unexpected problems.

I’ve used the mc to extract the zip and you can probably guess how that has ended. In short, problems with permissions, errors during and after install, lq-based scripts ending up without xterm...I was really tempted back then to come here and complain about it all, and then it hit me to check it one more time to be exactly sure if the problem was really with the main script (which supposedly had the newest fixes) or PEBKAC. Cause nobody else was complaining about these errors and issues, which means it’s either new or something on my end.

And it was the second. So, whoever is reading this, make sure to use unzip command.

Onward to the script itself. I’ve downloaded the version with the bug, which supposedly renders the OS useless. I didn’t encounter the same problem, probably because of the previous permissions issues, which has saved me in way, since I was doing the installation on two PC’s, one with a new Qubes install and second with existing installation. More luck then brains I guess.

With the correct extraction I had 0 issues on both machines with the Base install. Networking brought different problems, and in order to resolve them I’ve encountered several issues with the script.

I’ve picked the Mirage FW option, and encountered the same issues for Cannot Dynamically Attach. It was supposedly fixed in the main branch, so this got me really confused. I’ve tried then with regular Firewall, but my other PC had an issue with it and internet never worked. So I went back to Mirage.

I’ve added the following code after 456 line, since the sys-firewall, sys-net and fw-net were somehow stil running and messing up the rest of the script.

qvm-shutdown --quiet --wait --force "${SYS_FIREWALL}"
qvm-shutdown --quiet --wait --force "${SYS_NET}"
qvm-shutdown --quiet --wait --force "${VM_FW_NET}"
qvm-shutdown --quiet --wait --force "${VM_NET}"
sleep 3

This is where I found out a bug with Mirrage Firewall. Seems like you can’t set netvm property if it’s running. I’ve tested this out in the Qube Manager, and manager crashed upon the change. When Mirage is down, the change can be applied without such crash.

Of course, this wasn’t the end of my problems. I’ve encountered few more issues, mostly tied to specific hardware of my second PC.

The PC has the dreaded rtl8821ce wifi, and you can probably guess, it is a pain to configure. The firmware is only available with dkms module. In my case it meant one more uninstall and modification of the install script (firmware part) to add dkms, followed by the bc packet to the debain-core, in order to make the required module.

The module was successfully added to the debian-core and I finally had the wifi. But, here comes the unexpected part. Core-net crashed and refused the start. Logs indicated the kernel panic, which I found strange because for a moment wireless has worked, as I’ve connected when the script was toryfing the debian sources.

Apparently, it was the last part of the script with the memory adjustments, which lowered the core-net RAM from 512 to 208 MB. I’ve encountered similar issues since the change from 5.10 kernel to 5.15 and higher but wasn’t able to figure it out.

Now, thanks to your script I’ve found the cause. Probably the issue is in the rtl8821ce source code which doesn’t play nice with newer kernels, but I have no idea what to do there. I’ve used the only workaround available, to add more RAM for the core-net at the memory adjustments - line 517 of my modified script.

qvm-prefs --quiet --set "${VM_NET}" memory 640

Finally what was left to do is to add autoconnect feature to /etc/protect/template.core-net/config/rc.local in debian-core:

/usr/bin/nmcli con mod <wifi> connection.autoconnect yes

Liteqube, when it’s properly installed and configured, works like a charm. I’m so excited with it and I can’t wait for the addition of network and Tor applets, as they are the most important ones in my opinion.
nmtui can work for Wifi network but I’m not sure what could be used for Tor.

My next adventure would be to try your awesomewm version, hopefully I would manage to figure it out.

Sorry for the long read and for the lack of TLDR.

Please consider changing this script to use admin.vm.property.Get+audiovm and admin.vm.property.Get+xid instead of admin.vm.property.GetAll.