[MIR] iwd

Review for Package: src:iwd

[Summary]
iwd (iNet Wireless Daemon) is a modern, up-and-coming wireless daemon for Linux. It is written by Intel and aims to replace wpa_supplicant for potential benefits in:
- simplification of network management
- faster network discovery
- fast and reliable roaming
- using less system resources
- using features offered by the Linux kernel
- support for enterprise security methods like EAP
- support for kernel asymmetric key rings and trusted platform modules (TPM)
- support for multiple clients

The package is in pretty good shape overall and has been discussed as a replacement for src:wpa since a long time ago (https://discourse.ubuntu.com/t/call-for-testing-improved-wifi-via-iwd/17795, LP: #1872060 and others). It would be nice to have iwd in main as a replacement for wpa.

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security.

List of specific binary packages to be promoted to main: iwd
Specific binary packages built, but NOT to be promoted to main: <None>

Notes:
- The MIR talks about replacing wpa with iwd, could you please specify the plan for this in more detail, e.g. can we demote src:wpa at the same time as promoting src:iwd?
- The src:iwd package contains an embedded source for "ell", but that is not being used during build.

Required TODOs:
#1: descibe how/when we will be able to demote src:wpa (wpa_supplicant)

#2: Remove src:iwd from the lto-disabled list: LP: #1956950
    And fix the LTO build or put the workaround into the package directly.

#3: get src:ell MIR approved: LP: #1971738

Recommended TODOs:
#4: The package should get a team bug subscriber before being promoted
#5: Double-check if https://bugs.debian.org/1007097 could be a problem
#6: work with upstream/debian to avoid autoconf warnings during build

[Duplication]
There is src:wpa (wpa_supplicant) in main, providing similar functionallity. There are some reverse-depends that would need to be adopted, if wpa is demoted:
$ reverse-depends -c main src:wpa
Reverse-Recommends
* geoclue-2.0 (for wpasupplicant)
* network-manager (for wpasupplicant)

Reverse-Depends
* ubuntu-desktop [amd64 arm64 armhf ppc64el]
* ubuntu-desktop-minimal [amd64 arm64 armhf ppc64el]
* ubuntu-desktop-raspi [arm64 armhf]
* ubuntu-server-raspi [arm64 armhf]

Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, ppc64el, s390x

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems:
- Depends on libell0, proposed for MIR: LP: #1971738

[Embedded sources and static linking]
OK:
- no static linking is used
- does not have odd Built-Using entries
- not a go package, no extra constraints to consider in that regard
- No vendoring used (embedded "ell" is unused)

Problems:
- embedded "ell" source present in ell/, but is not being used (d/rules specifies "--enable-external-ell"

[Security]
OK:
- history of CVEs does not look concerning (two of t...

This can enter security queue while Desktop considers the remaining open required todos.
Assigning.

Also setting the milestone matching that of ell.

After consultation with the MIR team, we concluded that this should actually go through security review. Updated my previous comment.

Using IWD wouldn't obviate the use of wpa_supplicant, since the latter is used for more than Wi-Fi security. 802.1x authentication can be used for physical networks as well as VPNs and other things, so NetworkManager will use wpa_supplicant for those scenarios.

IWD is pretty much only for Wi-Fi, so you'd wind up needing both in main if you decided to go down the road of using IWD.

> Using IWD wouldn't obviate the use of wpa_supplicant, since the latter is used for more than Wi-Fi security. 802.1x authentication can be used for physical networks as well as VPNs and other things,

iwd includes a component for physical 802.1x authentication called 'ead' but the Debian (and Ubuntu) package isn't currently built with --enable-wired which has been reported to Debian as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956457

I reviewed iwd 1.27-1 as checked into kinetic. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

Iwd, the iNet wireless daemon, is a wireless daemon for Linux that aims to implement wireless network functionalities and simplify network configuration, management and use for users. Iwd attempts to achieve this in a simple manner, using Linux Kernel functionalities and not depending on any external libraries, which also allows for optimized resource utilization (storage, runtime memory and link-time costs). It is written by Intel, and is an alternative to wpa_supplicant.

- CVE History: there are two main CVEs associated with this package, CVE-2020-17497 and CVE-2020-8689. According to our prioritization, none of these is a HIGH or a CRITICAL, and according to NVD, they are classified respectively as HIGH and MEDIUM. Upstream seems to have responded to the vulnerability reports quickly, and patches were provided.

- Build-Depends: debhelper-compat, libell-dev, libreadline-dev, libdbus-1-dev, systemd.

- Run-Depends: init-system-helpers (>= 1.51), libc6 (>= 2.34), libell0 (>= 0.50), libreadline8 (>= 6.0), dbus. Focuses on mostly depending on the Linux Kernel and the C runtime library.

- There is a postinst script and there is a postrm script. For the postinst script: creates and enables the iwd systemd service in /etc/init.d. The service seems to not be automatically started upon install, which is confirmed by the fact that the postinst scripts calls update-rc.d with option defaults-disabled. For the postrm script: removes the installed systemd service, reloads systemd and masks the iwd service, in case of a 'remove'; or purges and unmasks it, in case of a 'purge'. No configuration files seem to be removed. The postrm script cleans up what is done by the postinst script.

- File ./etc/init.d/iwd is created during install. This contains the iwd service that is to be run in the system. Permissions for this file are the default for init.d scripts, which seems appropriate. The script sets environment variables which will point to iwd's state directory and configuration directory (places where iwd extracts data from). It creates the directory for the state configurations with 0700 permissions. It starts the daemon. It sets the location of its pid file to /var/run/iwd-sysd2v.pid. The daemon is set to run in the background. It looks like iwd creates the directory it needs everytime it starts running, maybe to guarantee that there will be no errors if any configuration or state file is missing. This could be a positive thing, as iwd sets the permissions of the state directory everytime it starts, which means that once it starts, only whoever is the owner of the file (which we can assume is expected to be root) can edit it, which would avoid issues where there is an attempt to tamper with this file.

- /lib/systemd/system/iwd.service: defines the DBus service net.connman.iwd which has the following network capabilities: CAP_NET_ADMIN, CAP_NET_RAW and CAP_NET_BIND_SERVICE. It sets the StateDirectoryMode to 0700. NoNewPrivileges is set to true, which is a security plus. Sets PrivateTmp, which is useful to secure acce...

in case it was not clear from my earlier comment, re 1. we can demote wpa this cycle since ead in iwd provides what we need.

on the recommended todo, the Debian bug is under resolution and will be addressed before release and we will work with upstream on the warnings

After discussing this in the MIR team meeting, this is an ack as the remaining issues have been fixed or are on track.

desktop-packages subscribed and package promoted now

Nice. I think the last step is to change the ubuntu-meta packages to depend on iwd instead of wpasupplicant. What do you think?