Re: [qubes-users] Salt updates fails on Fedora-33

2021-03-03 Thread lok...@gmail.com
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

2021-03-03 Thread Andrew David Wong

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 

[qubes-users] Replacing the wpa_supplicant wifi daemon with iwd

2021-03-03 Thread 'qtpie' via qubes-users
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

2021-03-03 Thread Steve Coleman
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

2021-03-03 Thread lok...@gmail.com
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

2021-03-03 Thread 'keyandthegate' via qubes-users
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

2021-03-03 Thread Mike Keehan

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.