[MIR] authd

[Jean-Baptiste Lallement]

[Availability]
- The package authd is already in Ubuntu universe.
- The package authd build for the architectures it is designed to work on.
- It currently builds and works for architectures: amd64, arm64, armhf, ppc64el, riscv64, s390x
- Link to package https://launchpad.net/ubuntu/+source/authd

[Rationale]
- Authd is the foundation for cloud-based authentication and MFA support on Ubuntu and identity providers such as Open ID connect or Microsoft Azure / Entra ID. This package also enables partners to create their own authentication brokers.
- The package authd is required to be in main for enabling cloud authentication at provisioning time.
- The package authd will generally be useful for corporate users.
- No package in main or universe currently offers cloud authentication capabilities.
- The target release is the next LTS 24.04 LTS.

[Security]
- This is a new software developed and maintained by Canonical. It has no security history.

- No CVEs/security issues in this software in the past (There are false positives. authd is an authentication daemon for Junos and VMWare):
  - (0) https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=authd
  - (0) https://ubuntu.com/security/cves?q=&package=authd
  - (0) https://security-tracker.debian.org/tracker/source-package/authd

- no `suid` or `sgid` binaries
- Package does install a dpkg trigger on /usr/lib/linux/efi
- Packages does not open privileged ports (ports < 1024)
- Packages does not contain extensions to security-sensitive software

- It installs a service in /usr/sbin/authd, running as root. The service has some systemd confinement.
- It installs a PAM module
- It installs an NSS module.
- Communication between authd and its brokers is done over DBus
- Communication between the pam/nss module and authd are done over a local DBus socket (socket activated service), using grpc.

- Security has been kept in mind and common isolation/risk-mitigation patterns are in place utilizing systemd isolation features, cache directory permissions are 0700, cache file permissions are 0600.

- /!\ This requires a security review.

[Quality assurance - function/usage]
- The package needs post install configuration and reading of documentation. - There isn't a safe default because the administrator must configure the selected authentication broker corresponding to their identity providers.
- Once installed without additional configuration, PAM requests are ignored by authd.

[Quality assurance - maintenance]
- The Ubuntu Desktop team (~desktop-packages) maintains this package. It doesn’t have any long-term and critical, open bugs:
  - https://github.com/ubuntu/authd/issues
  - https://bugs.launchpad.net/ubuntu/+source/authd

[Quality assurance - testing]
- There is a comprehensive, non-trivial, testsuite. The testsuite includes integration and functional tests.
- The testsuite runs at build time. The branch coverage is 89%:
  - https://github.com/ubuntu/authd/actions/workflows/qa.yaml?query=branch%3Amain
  - https://app.codecov.io/gh/ubuntu/authd

- The same test suite runs as autopkgtest. It is passing on all supported architectures. Links to test logs:
  - https://launchpadlibrarian.net/701470374/buildlog_ubuntu-noble-amd64.authd_0.1_BUILDING.txt.gz
  - arm64 tests are flaky due to a Rust regression that makes the build very slow and timing out.

- Currently, autopkgtests and package build are skipping integration tests (because it needs a VHS binary). We are working on bringing it before the 24.04 release with a mock ttyd so that we can run them there too.
- Upstream CI also includes code sanity checks (golangci-lint, including gosec) and vulnerability scanning (govulneck).

[Quality assurance - packaging]
- There is no debian/watch because authd is a native package.
debian/control defines a correct Maintainer field:
    Maintainer: Ubuntu Developers <email address hidden>

- This package does not yield massive lintian Warnings, Errors

```
$ lintian --pedantic --tag-display-limit 0
W: authd-dbgsym: debug-file-with-no-debug-symbols [usr/lib/debug/.build-id/c8/a7886227cc6b0b1004271bd8a3f7eb0bf6a6b3.debug]
W: authd: no-manual-page [usr/sbin/authd]
P: authd: spelling-error-in-copyright Unknwon Unknown
```

- spelling-error-in-copyright is a false positive. Unknwon is the actual name of the author.
- Lintian overrides package-does-not-install-examples in vendored Rust modules.

- This package does not rely on obsolete or about to be demoted packages.
- This package has no python2 or GTK2 dependencies

- The package will not be installed by default. The package is installed during provisioning if the user explicitly selects it. In this case, they’ll have to also select an identity provider and questions will be asked.

- Packaging and build is easy:
  - https://github.com/ubuntu/authd/blob/main/debian/rules

[UI standards]
- Application is not end-user facing, one string is translatable, via standard intltool/gettext or similar build and runtime internationalization system:

    pam/userselection.go: u.Prompt = "Username: " // TODO: i18n

- Most of the translated strings will come from the different brokers (separate projects)

- The system for internationalization is in place of the project and the mo and po files are generated. It’s a question of taking the time to mark the appropriate strings for translations.

[Dependencies]
- No further depends or recommends dependencies that are not yet in main.

[Standards compliance]
- This package correctly follows FHS
- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency.

[Maintenance/Owner]
- The owning team will be desktop-packages and I have their acknowledgement for that commitment
- The team desktop-packages is subscribed.
- The team desktop-packages is aware of the implications by a static build and commits to test no-change-rebuilds and to fix any issues found for the lifetime of the release (including ESM).
- The team desktop-packages is aware of the implications of vendored code and (as alerted by the security team) commits to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM).
- This package (NSS module) is Rust based and vendors all non language-runtime dependencies.

[Background information]
- The Package description explains the package well.
- Upstream Name is authd.
- Link to upstream project https://github.com/ubuntu/authd

[Mark Esler (eslerm)]

Vendored packaging is required for Go and Rust, but does not scale well for maintenance. There is a lot of vendored code in this package.

Is Security responsible for monitoring all 190 vendored packages for CVEs? Is Security responsible for resolving vulnerabilities in every vendored package?

Security could monitor CVE assignments to vendored packages and alert owning teams. I believe owning teams need to own vendored package maintenance. Otherwise the scaling nature of vendored packages falls on Security and will not be sustainable. After Security's CVE intake, owning team would need to set the affected status of CVEs in vendored packages.

Are there unnecessary dependencies in this package? Should we package or maintain ./vendor_rust/win* ?

What is Security's responsibility in reviewing dependencies during an MIR? If we don't review each package there is an MIR loop-hole to avoid security concerns. We cannot perform a security review of 191 packages by 24.04.

Please see the vendored discussion on ubuntu-mir [0], particularly the comment about [1] `cargo vendor` causing unnecessary vendoring.

eslerm@mino:~/audits/authd/noble/authd-0.2$ ls vendor_rust/ vendor/*/ |wc -l
190

[0] https://github.com/canonical/ubuntu-mir/issues/35
[1] https://github.com/canonical/ubuntu-mir/issues/35#issuecomment-1859325671

edit: owning team already stated they are "commit[ed] to provide [vendor] updates to the security team" :)

As a debdiff for Security to sponsor, that sounds great \o/

[Didier Roche-Tolomelli (didrocks)]

We have many projects using Go (and another one with Rust) vendoring.

On Go, we are fully equipped on our vendoring: we are using heavy testing, use govulncheck in our upstream CI, which reports and ensure any disclosed CVE are checked. Also, this tools tell us if we are using or not the vulnerable code.

The Rust part is unfortunately less mature: it doesn’t have, as you says, the tooling for it, and `cargo vendor` is causing unnecessary vendoring as ``./vendor_rust/win*`. We are eager for Rust maintainer on the foundation team to provide a generic patches for it, so that it can spread out to any Rust packages that enters ubuntu.

[Mark Esler (eslerm)]

Thanks @didrocks!

Glad to hear about Go. Could you point me to our govulncheck CI? cargo-audit is a similar tool we may want to integrate for Rust.

I'll try to raise dh-cargo/`cargo vendor` issues in the proper channels.

[Jean-Baptiste Lallement (jibel)]

The source of the action is:
https://github.com/canonical/desktop-engineering/blob/main/gh-actions/go/code-sanity/action.yaml#L184

An example run (successful)
https://github.com/ubuntu/authd/actions/runs/7708388644/job/21007352814#step:4:514

[Mark Esler (eslerm)]

That's excellent :D Would be a great if Launchpad had a way to do something similar for all Go packages.

Running cargo-audit, which is like govulncheck, on authd found an issue in the vendored h2 package: https://rustsec.org/advisories/RUSTSEC-2024-0003

I'll ask desktop-engineering if they can add cargo-audit check.

[Seth Arnold (seth-arnold)]

cargo check and govulncheck are fantastic things, but they're written from the perspective of upstream application authors who will keep up with new versions of dependencies on a regular basis.

What does this mean for our 24.04 LTS release, in eg 2029? Will we have four different versions of authd, one for each release of the operating system? Will these CI jobs still be running in 2029 to alert us to issues in the vendored packages from 2024? Will the upstream data sources even care about five year old code versions?

Or, will we be updating the authd package periodically, and keeping identical versions between 24.04 LTS, 26.04 LTS, 28.04 LTS, etc, just rebuilt on each for the corresponding kernel ABI?

A brand new package feels likely to need quick iteration, especially once it's been used in the field. What does authd's future look like?

Thanks

[Didier Roche-Tolomelli (didrocks)]

> cargo check and govulncheck are fantastic things, but they're written from the perspective of upstream application authors who will keep up with new versions of dependencies on a regular basis.

This is exactly what we do as upstream developers (and use dependabot too to ensure we always use latest release versions)

> Or, will we be updating the authd package periodically, and keeping identical versions between 24.04 LTS, 26.04 LTS, 28.04 LTS, etc, just rebuilt on each for the corresponding kernel ABI?

That’s the idea. As with multiple upstream projects that the enterprise/WSL teams are owning, we need to backport to past LTS and ensure the same level of code and feature compatibility between releases. The goal is thus to only have one code base (optionally with few condition depending on the release), with vendored dependencies so that this backport/long term maintainance in future releases is easy.

Also, as we have a very comprehensive testsuite from unit to end to end on real systems, we ensure ourself that at least the parts of what we use from the vendored dependencies are behaving as we expect from our source code perspective.

So, all those toolings are in place to ensure we can always build and fix on any release. I would add also that we also do the same for our Golang version and always trim technical debts and adapt by the latest release. I think btw that our Golang maintenance policy (as the compiler) needs to change as Google only supports the last 2 versions of Go and don’t issue security maintenance or bug fixes to older releases. Consequently, we have vulnerable Go compiled code in previous LTSes and the maintenance strategy should be fixed (with the rebuild of any compiled impacted code).

At least, on enterprise/WSL projects like authd, as we are always targetting latest Go and are aware of security vulnerabilities impacting us through vulnerability check, I think we are quite ahead of the curbe despite (or also thanks to‘ doing some "vendoring" + a single code base.

I hope that answers your concerns!

By the way, we just uploaded authd 0.2.1 which is fixing the Rust dep CVE. (and updated some other vendored deps along the way).

[Jean-Baptiste Lallement (jibel)]

@Seth and Mark:

We've added a GH action that cover rust-sanity and includes cargo-audit.
The code of the action is https://github.com/canonical/desktop-engineering/blob/main/gh-actions/rust/code-sanity/action.yaml

It has been integrated to authd and here is an example run:
https://github.com/ubuntu/authd/actions/runs/7975225784/job/21825907903

[Mark Esler (eslerm)]

\o/ thank you, looks great :D

[Mark Esler (eslerm)]

`cargo vendor` is known to cause unnecessary package vendoring [0][1]

Are there dependencies that can be removed, such as `./vendor_rust/win*` ?

[0] https://github.com/rust-lang/cargo/issues/11929
[1] https://github.com/canonical/ubuntu-mir/issues/35#issuecomment-1859325671

[Didier Roche-Tolomelli (didrocks)]

Indeed, we don’t have any need for the `win*` dependencies and I agree that the amount of Rust vendor would be better reduced.

I’m happy if you have any advice or any hints how we can achieve this (after some reading on both links, I don’t see any off the self solution?)

Also I think a better path forward is for security team to raise this to our Rust toolchain maintainer to see if this could be implemented at the debhelper level? I am a little bit afraid that any hackish per-package solution would then be restricted there, diverge in methods between packages and then, we don’t have a single common solution for the whole archive, which is maintained centrally (a little bit our hack we had to put to remove the *.a archive files).

Does this make sense? (Again, happy to get any pointer for a quick solution for now, but I would prefer that we have the discussion at the Ubuntu level for the problems I raised above).

[Ioanna Alifieraki (joalif)]

Review for Source Package: authd

[Summary]
The main issue with this package is the large amount of vendored code however desktop
team has agreed to take care of it.
Other than that it looks ok.

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: authd
Specific binary packages built, but NOT to be promoted to main: <None>

Notes:
Recommended TODOs:
1. Please mark the appropriate strings that need translations.
- The package should get a team bug subscriber before being promoted

[Rationale, Duplication and Ownership]
There is no other package in main providing the same functionality.
Desktop-packages team is committed to own long term maintenance of this package.
The rationale given in the report seems valid and useful for Ubuntu

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

Problems: None

[Embedded sources and static linking]
OK:
GO:
- vendoring is used, but the reasoning is sufficiently explained
- golang: static builds are used, the team confirmed their commitment
  to the additional responsibilities implied by static builds.
RUST:
- Rust package that has all dependencies vendored. It does neither
  have *Built-Using (after build). Nor does the build log indicate
  built-in sources that are missed to be reported as Built-Using.
- rust package using dh_cargo (dh ... --buildsystem cargo)
- Includes vendored code, the package has documented how to refresh this
  code at https://github.com/canonical/desktop-engineering/blob/main/gh-actions/rust/code-sanity/action.yaml

Problems:
- Go Package that vioaltes the Debian Go packaging guidelines

[Security]
OK:
- history of CVEs does not look concerning
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not expose any external endpoint (port/socket/... or similar)
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with cryptography (en-/decryption, certificates,
   signing, ...)
 - this makes appropriate (for its exposure) use of established risk
   mitigation features (dropping permissions, using temporary environments,
   restricted users/groups, seccomp, systemd isolation features,
   apparmor, ...)

Problems:
- does run a daemon as root
- does deal with system authentication (eg, pam), etc)
- does deal with security attestation (secure boot, tpm, signatures)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- does have a non-trivial test suite that runs as autopkgtest
- This does not need special HW for build or test
- no new python2 dependency
- Go package, but using dh-go...

[Jean-Baptiste Lallement (jibel)]

@Ionna thanks for the review.

In the Go section, what does it mean:

> Problems:
> - Go Package that vioaltes the Debian Go packaging guidelines

can you point to the Debian Go packaging guidelines you're mentioning?

[Mark Esler (eslerm)]

Thanks @didrocks!

I added a comment to the upstream cargo issue based on advice from toolchains and ~Rust [0]. This issue is also raised in ubuntu-mir [1].

I'll mention this at the next MIR meeting.

[0] https://github.com/rust-lang/cargo/issues/11929#issuecomment-1960081509
[1] https://github.com/canonical/ubuntu-mir/issues/35

[Ioanna Alifieraki (joalif)]

@jibel

> can you point to the Debian Go packaging guidelines you're mentioning?
https://go-team.pages.debian.net/packaging.html

It is stated in the bug description:
"- This package violates Debian Policy. It vendorizes various Go (in vendor/) and Rust libraries (in vendor_rust/). We are maintaining them up to date with dependabot in our upstream CI. The Go part is covered by the govulncheck security scanning on the Go version we are depending on and its vendored dependency."

However there's no TODO wrt to that. Just the translations as a recommendation.

[Lukas Märdian (slyon)]

Can we try to reduce the set of unneeded vendored dependencies, similar to how it is described here for Rust https://wiki.ubuntu.com/RustCodeInMain ?

[Seth Arnold (seth-arnold)]

How about a debian/rules 'vendor' target that would run the crate vendor and then rm -rf the windows crates?

[Didier Roche-Tolomelli (didrocks)]

We agreed during the MIR meeting that a generic tooling as part of debhelper would be the best way, didn’t we?

See my arguments above different upstream policies in different source packages, where if we start introducing this in a per-package base, that would create divergences between projects. Does it make sense to have this centrally managed (by our Rust toolchain expert, ideally?).

That way, we can go beyond trimming the windows crates, like tree shaking and so on?

[Mark Esler (eslerm)]

A centralized vendor-linter is the best longterm option. Toolchains needs more resources before they can provide a solution (FR-6859).

[Didier Roche-Tolomelli (didrocks)]

I continued exploring this topic myself last week and was able to rely on a tool developed for this: https://github.com/coreos/cargo-vendor-filterer/.

This tool is not ideal in the sense that:
- it vendorize the whole content
- then, it filters by replacing entire crates based on some filtering rules, like arch, platform or file exclusion. The replacement is done by empty module, and rechecksumming.

So basically, cargo and rustc still thinks the crate is available, it just happens to be empty. Consequently, we wouldn’t know if we are impacted or not by security issue before manual checking.

However, I see this as a step in the right direction, so I implemented this in authd: https://github.com/ubuntu/authd/pull/270/files. Here, we are filtering to only keep Linux platform, on all our supported architectures (which is tier 1 and 2 in Rust world).
The benefit is that we are now able to remove our manual recheckshumming after purging the binary library archive files which are part of some crates.

This tool run during the package source build. I would feel better if this was packaged and maintained in ubuntu (as this injects potentially some code), and part of our standard tooling. I will reach out the Rust maintainer for the incoming engineering sprint. I think we can still trust this repository as it’s part of a well-known organization with multi-decades open source famous maintainers.

[Mark Esler (eslerm)]

I am posting this Security MIR on behalf of Sudhakar Verma (@sudhackar) since he is out of the office.

---

I reviewed authd 0.2.1 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.

authd is a service that builds cloud based authentication and MFA from clouds
such as Open ID connect or Microsoft Azure / Entra ID. This is also a
framework that will help create authentication broker services.

- CVE History
  - no CVE found
- Build-Depends
  - pam related libraries
    - libpam0g-dev
  - language runtimes
    - golang-go
    - dh-cargo
  - jq
  - protobuf-compiler
- pre/post inst/rm scripts
  - add/remove authd to /etc/nsswitch.conf
- init scripts
  - No
- systemd units
  - Creates 'authd.service' - which is expected since this is a service to manage
    the authentication with a daemon
- dbus services
  - No
- setuid binaries
  - No
- binaries in PATH
  - /usr/sbin/authd
- sudo fragments
  - No
- polkit files
  - No
- udev rules
  - No
- unit tests / autopkgtests
  - unit tests and autopkgtests are there and working quite fine
- cron jobs
  - No
- Build logs
  - some warnings from tests and autopkgtests but nothing major

- Processes spawned
  - gpasswd is spawned to manage user - groups associations. The path seems to
    be hardcoded
- Memory management
  - code is mostly go - some glue for handling native libs in rust and C
    but no problems seen there. The tests cover the cases well.
- File IO
  - the daemon relies on a database file, config files and files related to
    user accounts - like /etc/group. The config files could be based in user's
    home, /etc - nothing concerning. Seems safe.
- Logging
  - logrus is used - under vendor. Seems safe.
- Environment variable usage
  - Used to enable debugging, PAM specific glue, DBUS etc. Seems safe.
- Use of privileged functions
  - No
- Use of cryptography / random number sources etc
  - RNG - uses crypto/rand from stdlib which is a CSPRNG. Seems safe.
  - Cryptography - Uses RSA from crypto/rsa - PKCS #1 and RFC 8017 for PAM
    side encryption. Seems safe.
  - Hashing - Only uses sha512 from crypto/sha512. Seems safe.
- Use of temp files
  - only while testing. Seems safe.
- Use of networking
  - All networking is done through unix sockets within PAM. Seems safe.
- Use of WebKit
  - No.
- Use of PolicyKit
  - No.

- Any significant cppcheck results
  - No
- Any significant Coverity results
  - No
- Any significant shellcheck results
  - No. authd only has scripts which are used during building.
- Any significant bandit results
  - No
- Any significant govulncheck results
  - No
- Any significant Semgrep results
  - go.grpc.security.grpc-server-insecure-connection
    - The connection is through a unix socket, so it's only accessible locally
      and is within PAM, so we are protected by the pam stack as well.
  - go.lang.security.audit.dangerous-exec-command
    - The command is static - 'gpasswd' as defined in defaultOptions,
      so this is an FP.

authd is a daemon that implements managing user authentication and related
services like MFA. It can be used to integrate with different auth providers
with our own brokers ...

[Mark Esler (eslerm)]

I believe this issue can be set to In Progress and is ready for promotion to main.

@didrocks, @slyon: please ping me if anything is needed from Security.

[João Gomes (gomesjoao)]

Hi, I reviewed the internal/adapter module as requested by SE, everything seemed to be in order. The crypto they use seems to be correct and the standard lib is used. The code is structured as I would expect for an adapter.

[Lukas Märdian (slyon)]

Security review looking good (comments #23 & #21) and no required MIR TODOs (comment #12).

Package has a team-bug-subscriber (~desktop-packages). Please move ahead and make the seed/dependency change to pull authd into main.

[Didier Roche-Tolomelli (didrocks)]

We decided to remove the authd package in noble for the time being.

The current implementation (in particular the one in the PAM module) is not up to our standard in terms of quality and what we are confortable to support in the long term. Rather than releasing as is and having risky SRUs in the future changing a large part of the implementation, we decided against this and rather polishing the code, securing it, adding even more tests and releasing all that as a new package SRUed to the 24.04 LTS in the coming months.

That way, we won’t risk to regress any potential users and we will use an architecture we are more confortable supporting for the next 5/10 years of the LTS release.
It means that when we reintroduce it, we will rerequest a new MIR too as the PAM module will largely change and we want to ensure we follow the process and quality standard we expect for the Ubuntu distribution.