Re: [qubes-users] Salt updates fails on Fedora-33
On Wednesday, 3 March 2021 at 23:40:55 UTC+8 stevenlc...@gmail.com wrote: > > On Wed, Mar 3, 2021, 9:28 AM lok...@gmail.com wrote: > >> On Wednesday, 3 March 2021 at 18:18:09 UTC+8 Mike Keehan wrote: >> >> I could not clone the fedora 33 templates, with a similar error message >>> about "not clean", until I started and stopped the template. It's been >>> OK since then. >>> >> >> I don't think that's the problem I'm facing, as I have restarted the >> template several times in order to do manual updates. >> > > In the F33 template announcement there were some mention about the update > control dvm needing to be updated to fedora-33 for the qubes update process > to work correctly. Updates will work right out of the box from the dnf > command line even without that change. Did you already follow this guidance > Thank you for the tip. I thought I had followed those recommendations, but I had missed the management VM template change. Changing this fixed the problem. Sorry for the noise. -- 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/64b6f2f6-3865-4cb0-bb76-17b40474468dn%40googlegroups.com.
[qubes-users] QSB-066: XML injection through libvirt domain configuration
Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) 066: XML injection through libvirt domain configuration. The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View QSB-066 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-066-2021.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ ``` ---===[ Qubes Security Bulletin 066 ]===--- 2021-03-03 XML injection through libvirt domain configuration User action required = Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0: - qubes-core-dom0 package, version 4.0.58-1 For Qubes 4.1: - qubes-core-dom0 package, version 4.1.20-1 The packages are to be installed in dom0 via the Qube Manager or via the qubes-dom0-update command as follows: For updates from the stable repository (not immediately available): $ sudo qubes-dom0-update For updates from the security-testing repository: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing A system restart will be required afterwards. Alternatively, it is possible to restart qubesd with the following command in dom0: $ systemctl restart qubesd.service These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. Summary The libvirt domain configuration is an XML file built by filling a template with values specific to a particular domain -- mostly its properties but, in a few cases, "features" (extra properties that can be freely defined). While most of the properties have strictly-defined formats, some allow for a very broad range of values -- broad enough to allow characters that are otherwise special in XML. Using such characters in XML values requires escaping them, which was not enabled in the template engine we use (jinja2). The specific VM metadata properties that allow free text and are used in libvirt XML are as follows: - `kernelopts` property - `timezone` feature (although it is validated in the template itself) - `video-model` feature - `audio-model` feature (Qubes R4.1 only) Normally, this wouldn't be an issue, since all VM settings come from a trusted entity (dom0). However, with the introduction of the Admin API [1] in Qubes 4.0, it is possible to allow less trusted domains (known as "ManagementVMs") to manage a subset of VMs or their settings, including the affected properties and features. This, in turn, can be used to modify unintended parts of the libvirt XML. In the worst case, this could lead to code execution in dom0. To fix the issue, we're enabling the autoescape feature of the jinja2 template engine. This will cover the current problematic properties as well as any others that might be introduced in the future. Additionally, we're adding an extra validation step for "features" that are otherwise used in a free text form context (specifically, `net.fake-*` features are expected to be IP addresses, but they lacked such validation). Note that a ManagementVM can still break a VM it has control over, for example, by setting some property to an improper value in a given context (e.g., too little memory or too short of a startup timeout). However, after these changes, it should no longer be able to escalate its permissions beyond what it has been assigned. Impact === Default Qubes 4.0 and 4.1 configurations are not affected. If a less trusted domain (known as a "ManagementVM") is given Admin API access to set any of the affected properties or features on any domain (via the `admin.vm.property.Set` or `admin.vm.feature.Set` qrexec services), it may use this access to elevate its privileges and potentially take full control of the system. Note that `qubes.FeaturesRequest` is enabled by default but *is not* vulnerable for three reasons. First, feature names are read from qubesd, which enforces a whitelist of permitted characters in paths. None of the permitted characters are metacharacters in XML. Second, none of the features for which dom0 will honor a request have their values incorporated into libvirt XML. Third, `qubes.FeaturesRequest` can only unset a feature or set its value to `1`. Credits This issue was discovered by Demi Marie Obenour. References === [1] https://www.qubes-os.org/doc/admin-api/ -- The Qubes Security Team https://www.qubes-os.org/security/ ``` This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2021/03/03/qsb-066/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To u
[qubes-users] Replacing the wpa_supplicant wifi daemon with iwd
Hi, Due to mysterious, unsolvable Wifi issues, I decided to replace the wpa_supplicant wifi daemon with iwd. iwd itself is excellent and a definite improvement over wpa_supplicant. I can't find Fedora working on this though. In the Fedora 33 template, it currently comes down to: $ dnf remove wpa_supplicant $ echo -e "[device] \nwifi.backend=iwd" | tee -a /etc/NetworkManager/NetworkManager.conf $ systemctl enable iwd.service $ systemctl start iwd.service $ systemctl restart NetworkManager There are just two integration issues remaining that I hope people can help me with. I am using the standard Qubes Fedora template, and want to stay as close to it as possible, so I'm not interested in ditching NetworkManager unless it is unavoidable. 1. /etc/dbus-1/system.d/org.freedesktop.GeoClue2.conf: this is the only other file in /etc/ that mentions wpa_supplicant. It contains policy to allow wpa_supplicant to be used for geolocation. Since I don't care for geolocation, I just removed it (don't comment it out. But if someone cares to adapt this to iwd, it would be nice. 2. Occasionally, NetworkManager says 'device not ready' under wifi, and wifi stops working. It is solved temporarily by ``$ systemctl restart iwd.service && systemctl restart NetworkManager.service`` in sys-net. I don't get from the log what the exact issue is though. -- Resources: - I used this howto from Josh Stoik as a starter: https://blobfolio.com/2019/replacing-wpa-supplicant-with-iwd-in-ubuntu-eoan/ - https://wiki.archlinux.org/index.php/Iwd GeoClue2 policy: -- 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/a92da205-6c3d-5ae7-3a9e-78ad19cefaaa%40disroot.org.
Re: [qubes-users] Salt updates fails on Fedora-33
On Wed, Mar 3, 2021, 9:28 AM lok...@gmail.com wrote: > On Wednesday, 3 March 2021 at 18:18:09 UTC+8 Mike Keehan wrote: > > I could not clone the fedora 33 templates, with a similar error message >> about "not clean", until I started and stopped the template. It's been >> OK since then. >> > > I don't think that's the problem I'm facing, as I have restarted the > template several times in order to do manual updates. > In the F33 template announcement there were some mention about the update control dvm needing to be updated to fedora-33 for the qubes update process to work correctly. Updates will work right out of the box from the dnf command line even without that change. Did you already follow this guidance? > -- 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/CAJ5FDng6reuYQAt-tBk2oAjk0kZKqXA6S71Ss76M%2Boih_o0Yig%40mail.gmail.com.
Re: [qubes-users] Salt updates fails on Fedora-33
On Wednesday, 3 March 2021 at 18:18:09 UTC+8 Mike Keehan wrote: I could not clone the fedora 33 templates, with a similar error message > about "not clean", until I started and stopped the template. It's been > OK since then. > I don't think that's the problem I'm facing, as I have restarted the template several times in order to do manual updates. -- 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/b6b82a15-6cde-470d-ad13-aa94723e14a7n%40googlegroups.com.
[qubes-users] Open sourcing my salt configs
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 -- 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/NTmFFT8PX6ISKTuoQoqTiNW-F2DglyltdvA9x8wO347GSSL_I4S-c74Mbov1E4USGtpiWIpH39AZ-6lT3zzA9Uym9nxrRtGKGl8t_YsP3oE%3D%40protonmail.com.
Re: [qubes-users] Salt updates fails on Fedora-33
On 3/3/21 4:31 AM, lok...@gmail.com wrote: After I installed the fedora-33 template a few days ago, I have never been able to do a software update on it using the Salt-based updater. A manual update using "dnf update" works fine. This is the error I'm getting in the updater tool: Is this a known problem, and is there some easy way to fix this? - Updating fedora-33 Error on updating fedora-33: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=fedora-33', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20 fedora-33: -- _error: Failed to return clean data retcode: 1 stderr: Traceback (most recent call last): File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in salt_call() File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 445, in salt_call client.run() File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 48, in run caller = salt.cli.caller.Caller.factory(self.config) File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 64, in factory return ZeroMQCaller(opts, **kwargs) File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 329, in __init__ super(ZeroMQCaller, self).__init__(opts) File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 89, in __init__ self.minion = salt.minion.SMinion(opts) File "/var/tmp/.root_dd8a91_salt/pyall/salt/minion.py", line 912, in __init__ opts["grains"] = salt.loader.grains(opts) File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader.py", line 825, in grains ret = funcs[key]() File "/var/tmp/.root_dd8a91_salt/pyall/salt/grains/core.py", line 2384, in ip_fqdn ret["ipv6"] = salt.utils.network.ip_addrs6(include_loopback=True) File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/network.py", line 1353, in ip_addrs6 return _ip_addrs(interface, include_loopback, interface_data, "inet6") File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/network.py", line 1333, in _ip_addrs ret.add(addr) File "/usr/lib64/python3.9/ipaddress.py", line 1920, in __hash__ return hash((self._ip, self._scope_id)) AttributeError: _scope_id stdout: -- I could not clone the fedora 33 templates, with a similar error message about "not clean", until I started and stopped the template. It's been OK since then. Mike. -- 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/6b4de0fb-e080-377b-e1a6-cfddc0b99743%40keehan.net.
