[qubes-users] XSAs released on 2021-03-04
Dear Qubes Community, The Xen Project released one or more new Xen Security Advisories (XSAs) on 2021-03-04. The security of Qubes OS *is not affected* by these XSAs. Therefore, *no user action is required*. XSAs that affect the security of Qubes OS (user action required) The following XSAs *do affect* the security of Qubes OS: - (None) XSAs that do not affect the security of Qubes OS (no user action required) -- The following XSAs *do not affect* the security of Qubes OS, and no user action is necessary: - XSA-367 (not affected; Qubes uses PVH/HVM) - XSA-369 (DoS only) Related links - - Qubes Security Pack (qubes-secpack): https://www.qubes-os.org/security/pack/ - Qubes Security Bulletins (QSBs): https://www.qubes-os.org/security/bulletins/ - XSA Tracker: https://www.qubes-os.org/security/xsa/ This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2021/03/04/xsas-released-on-2021-03-04/ -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -- 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/55b3a113-89cb-6f8d-5d84-ffb8c157e03e%40qubes-os.org. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-users] Dom0 kernel panic
On 3/4/21 9:16 PM, frag face wrote: Thanks for your answer Bernhard, I wonder if I could make a Qube-style backup of the qubes in my hardrive instead of a rsync to restore/add them directly in the new installed Qube system, kind of lazy way ;) BR You can, with some extra work: The complete qubes-backup procdure is explained online. It is, roughly speaking, a tar archive with special checksum files to ensure pwds are correct. I always to these backups by hand, to keep myself trained. My method "sous-entend" that you "safe backup": in your life system generate a container file (truncate -s 200G /externalstorage/backup.luks), then losetup: (first losetup -f to get a free slot, then bind it with losetup /dev/loopX /externalstorage/backup.luks ), and cryptsetup luksFormat /dev/loopX ;cryptsetup luksOpen /dev/loopX BACKUP; mkfs.ext2 /dev/mapper/BACKUP ; mount /dev/mapper/BACKUP /somemountpoint For rsync'ing back inside qubes from subfolders you - attach usb to dispVM1 (widget) - lopsetup the container - attach container mapper to dispVM2 (widget) - there start same procedure as above at "luksOpen" step and then attach the full decrypted backup to each VM with the widget, and rsync back the correct subfolder in your home. You can use --exclude to avoid "dot"-files ... best, Bernhard -- 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/6d54904c-68ee-6ecf-4d59-10cddbd8941c%40web.de.
Re: [qubes-users] Dom0 kernel panic
Thanks for your answer Bernhard, I wonder if I could make a Qube-style backup of the qubes in my hardrive instead of a rsync to restore/add them directly in the new installed Qube system, kind of lazy way ;) BR Le jeu. 4 mars 2021 à 16:34, Bernhard a écrit : > On 3/3/21 3:29 PM, frag face wrote: > > Hi all, > > > > I'm running Qubes 4.0 > > My dom0 doesn't boot anymore (following an aborted Fedora update it > > seems...). > > Boot runs to kernel panic, see attached image. > > > > From a newly installed Qubes on a different disk, I can mount my > > crashed disk, decrypt it and access all my Qubes, DOM0... > > > > I see two options to recover my environment (and would prefer the first): > > 1- Fix my Dom0 environment on my crashed hard drive (I have another > > drive with a newly installed Qubes 4.0-rc3) > > 2- Save my qubes from my crashed disk, and restore them on my new > > 4.0-rc3 install. > > > > Any advise to perform a rescue for option 1 or 2 is welcomed ! > > 1) try to boot from a life system. Mount /boot and, in case of UEFI, > have a look in efi/qubes/xen.cfg or efi/BOOT/xen.cfg you should be > able to select a older kernel. Maybe that allows to reboot. > > 2) emergency backup is a good idea in any case. Open the encrypted > volume (using luks)then runvgchange -ayto activate all > logical volumes. With lvscan you should be able to see the names > (something like qubes-...-work-private > qubes-...-work-root > etc > It is the "private" one that you want. Mount them (they are all in > /dev/mapper/ ) and "rsync -auv" your data to a harddrive in > respective subdirs. That is less safe than the paranoid version > of qubes-backup since its grasps all ".config" files, but at least > you have a full take. > > Good luck! > > -- > 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/6ac3a6b2-9d0f-cb77-0ae0-a62e2f740d7c%40web.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/CAPrquWt6DK3w40VqYa_DoKHmMbn-P9gFzheK%2BEBQQMwUP%3D3gVA%40mail.gmail.com.
Re: [qubes-users] Open sourcing my salt configs
On Wed, Mar 03, 2021 at 11:58:41AM +, 'keyandthegate' via qubes-users wrote: > I've been developing a lot of salt config for myself and I want to start open > sourcing it so that I can: > > - Ask for public security review > - Accept patches > - Help people use Qubes a little better, when I think Qubes supports > anarchistic praxis and is a force of good in the world > > I'm worried about the following things: > > - I lose my security through obscurity, which I don't want to do without the > help of at least one non-amateur code reviewer for anything I publish > > - (and I'm not sure if the economics/incentives work out here such that I > should be paying someone to help me with this or not) > - I don't want to publish anything security sensitive without code review > because I don't want to harm people > > Additionally, I'm not sure how to package salt config via a .deb package. Are > there any existing examples of this? > > As an example of what I want to publish, I've written some config to create a > private debian package repo vm powered by a YAML file that lets you specify > sources to download packages (e.g. that are hosted as github releases) and > verify them via gpg, then provide them to vms. My motivation is towards the > goal of being able to destroy and recreate my templates from salt at any > time, because salt is not stateless (unlike e.g. nix or bazel), e.g. if you > decide to no longer add a package repo, you have to manually remove it from > the domain in addition to updating the salt config, and you may forget; being > able to recreate templates solves the otherwise almost intractable problem of > knowing your templates aren't out of sync; it also means you can exclude > templates from backups if you're brave, which can save a lot of space. > > Another example of some code I may want to publish: > (WARNING: I think this may have a critical security issue of exposing config > files to domains they don't belong to, but I'm not sure. Would need to > investigate before publishing) > This fixes TemplateNotFound errors when you try to jinja-include another file > within a `file.managed` `template.jinja` file. > > > # MAINTAIN: Removed when fixed: > > https://github.com/saltstack/salt/issues/31531 > > 'patch salt issue 31531': > > cmd.run: > > - name: | > > if [[ ! -f "$XDG_DATA_HOME"/patched-salt-31531 ]]; then > > cat < > sudo sed -i'' "s#if fn_.strip() and fn_.startswith(path):#if fn_.strip() > > and (fn_.startswith(path) or path == '/'):#" > > /usr/lib/python3/dist-packages/salt/fileclient.py && \ > > if ! grep extra-filerefs /etc/qubes-rpc/qubes.SaltLinuxVM >/dev/null; then > > sudo sed -i'' "s#salt-ssh#salt-ssh --extra-filerefs salt:///#" > > /etc/qubes-rpc/qubes.SaltLinuxVM; fi > > CMD > > fi > > sudo mkdir -p "$XDG_DATA_HOME" || exit 1 > > sudo touch "$XDG_DATA_HOME"/patched-salt-31531 || exit 1 > Great - I love salting Qubes. There *is* a problem in posting configs unless you are careful, but generally this can be mitigated by making them as general as possible. I'd be happy to take a look over what you have: you can get my email and PGP key from the team page at Qubes. Packaging - you need to package in an rpm because it will be handled in dom0 (generally). I generally just package the files, and *not* automatic execution. This is because I want people to review the files, and possibly edit them, before executing in dom0. If you want automatic execution, then it's simply a matter of using a "post install" execution in the rpm. I don't like this, as stated, but it's straightforward. As to publishing, I have some salt on GitHub (https://www.github.com/unman/shaker) Most of the states I publish are simple, in execution if not effect, because they are teaching aids. I have been thinking of publishing packages at https://qubes.3isec.org, alongside the templates and Ubuntu packages that I already offer. This could be done as an unofficial Qubes salt archive, possibly as a step toward inclusion of packages in the official Qubes repositories. If you'd like to take this further, drop me a line. For general issues, reply to the list. unman -- 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/20210304163301.GI17442%40thirdeyesecurity.org.
Re: [qubes-users] Dom0 kernel panic
On 3/3/21 3:29 PM, frag face wrote: Hi all, I'm running Qubes 4.0 My dom0 doesn't boot anymore (following an aborted Fedora update it seems...). Boot runs to kernel panic, see attached image. From a newly installed Qubes on a different disk, I can mount my crashed disk, decrypt it and access all my Qubes, DOM0... I see two options to recover my environment (and would prefer the first): 1- Fix my Dom0 environment on my crashed hard drive (I have another drive with a newly installed Qubes 4.0-rc3) 2- Save my qubes from my crashed disk, and restore them on my new 4.0-rc3 install. Any advise to perform a rescue for option 1 or 2 is welcomed ! 1) try to boot from a life system. Mount /boot and, in case of UEFI, have a look in efi/qubes/xen.cfg or efi/BOOT/xen.cfg you should be able to select a older kernel. Maybe that allows to reboot. 2) emergency backup is a good idea in any case. Open the encrypted volume (using luks)then runvgchange -ayto activate all logical volumes. With lvscan you should be able to see the names (something like qubes-...-work-private qubes-...-work-root etc It is the "private" one that you want. Mount them (they are all in /dev/mapper/ ) and "rsync -auv" your data to a harddrive in respective subdirs. That is less safe than the paranoid version of qubes-backup since its grasps all ".config" files, but at least you have a full take. Good luck! -- 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/6ac3a6b2-9d0f-cb77-0ae0-a62e2f740d7c%40web.de.
