How-not-to Guide: Ouch! Things to __not__ do (lightheartedly)

Collecting “useful” things (not) to do that are “frowned upon”.

:smiling_imp:

Connecting dom0 to network?

Having a single qube for everything? :sweat_smile:

In a dom0 terminal, doing:

eval "$( cat /run/qubes/qubes-clipboard.bin )"

Because this executes what is pasted into the global copy-paste-buffer in the dom0/administrative/privileged virtual machine.
And that could be changed/altered/exploited from another virtual machine.

As a demonstration, copy this into the global clipboard and execute the eval-command in dom0:

qvm-run --no-gui sys-net 'notify-send "Not sending something to blackhats."'

However it can sometimes come in handy, especially if you want to know if it is your lucky day.

Hm, yes, guess that would make working with the qubes operating system easier.

Because copying and pasting text or files between qubes/virtual-machines is less easy in the default configuration of QubesOS.

So, the (hopefully) simple explanation why not to connect dom0 to the network:

If the operating system in dom0 has an vulnerability that can be exploited through the network, all of the controlling commands for the other qubes could come at the hands of the blackhat.

The (hopefully) simple explanation why not to have a single qube for everything:

Decreasing the amount in which the software (OS) you use is exposed (reachable) by other/external parties results in less opportunity for them to do something you would rather not have them do.

[aside]
Interesting exercise, to give words to these matters that seem so evident to me by now.
[/aside]

Oh sorry, I misunderstood the goal of that topic, I thought it was a topic to gather bad practices :sweat_smile: my proposals were reallyyy bad and not really useful

Adding/removing PCI devices (even moving them between slots) or replacing MoBo or updating BIOS without appropriate care.

The problem is that this can change numbering of your devices. After next boot, different PCI devices might be assigned to your VMs. This has potentially both security implication (assigning a sensitive device to sys-net) and practical implications (assigning GPU to a VM just after boot makes you unable to boot).

How to do it properly: see workaround at Add warning re PCI numbering changes to "Devices" tab in QM · Issue #8127 · QubesOS/qubes-issues · GitHub

1 Like

Strategy to set autostart for as less as possible qubes would get additional +1 to implement it.

I don’t think it would be the way to go:

  • Usually, autostarts are desired.
  • When user doesn’t care about that and starts the qubes automatically, the implications are essentially the same.
  • When an user wants to investigate and fix the issue, then yes, having no autostart would be helpful. But I don’t think it justifies the discomfort from no autostart, especially when there are other options, incl. adding relevant Grub option.
    " There is some suggestion that aims to handle this issue more gracefully by detecting such situation and not starting the affected qube. This looks better, even from the security PoV.

Moderation note I’ve added some banners next to posts with commands not to run warning users about that fact. This topic is fine on its own, I just did that out of concern that someone arrives here without context and tries to run that. I don’t want to underestimate the ability of some users to shoot themselves in the foot by blindly running commands they see on a random forum without understanding the full conversation context.

4 Likes

Well, I meant that sometimes this can even prevent the user from booting to Qubes at all, so it would be needed as you indicated, to temporarily set the grub to prevent autostart. This could be cumbersome to less experienced users. Less than, for example, set the whole “online chain” to be invoked by starting (disposable) browser qube.

It would definitely help to some degree at some cost (e.g., longer time to ready after reboot). My point was that there are other options that can do the same or even better at lower cost.

Without intention to further advocate or oppose, just for peculiarity, we just had such a case, another amongst countless, hahaha

Upgrade to a template version (Fedora 39 for me) before it’s supported. Unless I had a unique corruption of the upgrade from 38, 39 rendered my system unusable until I switched VMs to Debian and used a USB wifi dongle to reinstall 38.

1 Like

copying directory from qube/vm into admin-qube/dom0

For why not, see:

!!! :warning: You are warned :warning: !!!

Sometimes it can be useful to recursively copy a directory from a VM into dom0 . This helper function does that by piping an tar-archive to stdout and then unpacking that archive to a given directory on dom0 .

(
qvm_copy_from_vm ()
{
  # Intended to work like `cp -a` .
  # But with provided paths limited to directories .
  verbose="" #--verbose"
  autostart="" #--autostart"
  root="" #--user root"

  remoteQubeName="${1?}"
  remotePath="${2?}"
  localPath="${3?}"

  remoteElementPath="${remotePath##*/}"
  remoteRootPath="${remotePath#${remoteElementPath?}}"
  remoteRootPath="${remoteRootPath%%/}"
  localRootPath="${localPath%%/}"
  localPath="${localPath%${remoteElementPath?}}"

  echo mkdir -p "${localRootPath?}"
  echo qvm-run ${verbose?
    } ${autostart?
    } ${root?
    } --pass-io "${remoteQubeName?
    }" -- 'tar -C "'"${remoteRootPath?
      }"'/" -czf - .' |
  printf '%s | ' "$( cat - )";echo tar -C "${localRootPath?}/" -zxf - .
  ## All these examples:
  #qvm_copy_from_vm "vault" "/home/user/temp/" "/home/d0user/temp/"
  #qvm_copy_from_vm "vault" "/home/user/temp/" "/home/d0user/temp"
  #qvm_copy_from_vm "vault" "/home/user/temp"  "/home/d0user/temp/"
  #qvm_copy_from_vm "vault" "/home/user/temp"  "/home/d0user/temp"
  ## Will execute the same:
  #mkdir -p /home/d0user/temp/dit
  #qvm-run --pass-io vault -- \
  #  'tar -C "/home/user/temp/" -cf - .' |
  #  tar -C /home/d0user/temp/ -xf - .
}
)

related to:

#!/usr/bin/env sh
# file to "test" qvm_copy_from_vm its path-sanitization
# Execute with: $0 /path/to/qvm_copy_from_vm.sh
#(
  testC="qvm_copy_from_vm"
  . ${1:-./${testC?}.sh}
  testLocal="${HOME:-/home/user}/temp/dit/"
  testRemote="${rHOME:-/home/user}/temp/dit/"
  remoteQube="vault"
  set -e
  2>/dev/null cd "${testLocal?}" ||
    mkdir -p "${_?}"
  for rQ in \
    "${remoteQube?}" \
  ;
  do
    {
      for rD in \
        "${testRemote?}" \
      ;
      do
        {
          rD="${rD%%/}"
          for rP in \
            "${rD?}/" \
          ;
#            "${rD?}" \
          do
            {
              for lD in \
                "${testLocal?}" \
              ;
              do
                {
                  lD="${lD%%/}"
                  for lP in \
                    "${lD?}/" \
                  ;
#                    "${lD?}" \
                  do
                    {
                      >&2 printf '# Example:\n'
                      printf '%s "%s" "%s" "%s"\n' "${testC?}" "${rQ?}" "${rP?}" "${lP?}"
                      >&2 printf '# Will execute:\n' 
                      >&2 ${testC?} "${rQ?}" "${rP?}" "${lP?}"
                    }
                  done
                }
              done
            }
          done
        }
      done
    }
  done
#)

True