Ubuntu
adsys package

[MIR] ADSys

Bug #1936907 reported by Didier Roche-Tolomelli on 2021-07-20

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	adsys (Ubuntu)	Fix Released	Critical	Unassigned	Ubuntu ubuntu-20.04.4

Bug Description

[Availability]

Available on all archs, available starting hirsute. It will be backported to Focal once an FFe has been accepted.

[Rationale]

We are supporting GPO Active Directory support on ubuntu starting hirsute. This features allows for an administrator to configure their Active Directory server to deploy per-machine and per-user configurations, enforce rules and other domain policies.

Right now, dconf keys, sudo administration rights and computer and user scripts are supported.

This feature is built and use the krb5 tickets which are provided by SSSD. Basically:
- SSSD is dealing with user and machine registration/authentification and enforce password policies
- ADSys is handling GPO enforcement and support. The Ubuntu specific policies needs to be installed on the Active Directory server (they are contained in the daemon).

[Security]

The daemon is started is running as a root user to be able to enforce machine policies, like rebuilding dconf databases, setting profiles. User only interacts with the client side (both sides communicates over GRPC), which can be ran as any user.

Polkit is used to restrain access to some part of the API.

There is a PAM module to build on demand per-user policy once authenticated with SSSD. They are rejected if the authentication or not all affected policies could be downloaded.

[Quality assurance]

Joining a domain in the ubiquity desktop installer makes the machine joining the AD domain and install adsys functionality. The package will be seeded directly on the desktop ISO.

An extensive testsuite (more than 1k) is included and available as autopkgtests for rdepends. The whole stack is tested (even the client/daemon interaction) and coverage is measured (including in the small python script). However, tests with a real Active Directory server can only be done manually as there is no setup available in the autopkgtests infrastructure.

[Dependencies]

Main dependencies are libsmbclient, python3 (an embeeded script allows, via samba, connecting to AD LDAP) and SSSD/KRB5.

This is a Go package, and all dependencies are vendored, and versions are controlled via go.mod. We are using dependabot (from Github) to automatically get notified of any dependencies updates (and security issues), which opens a PR, rebuild and run all tests to report it there. We are thus able to quickly merge them.

[Standards compliance]

Standard debhelper packaging, including a systemd service.

[Maintenance]

The desktop team will maintain it.

* we commit to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included)
* we will provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary
* we commit to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included)
* we will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code

[Background information]

ADSys is composed of:
- a daemon, named adsysd, running as root. This one will shutdown after a period of inactivity without any active request. It is socket activated.
- a client, named adsysctl (which is a symlink to adsysd and only differ behavior from its executable name), which is running as the user (or root on boot for machine update). This ones optionally wakes up adsysd, connect through an Unix socket with SO_PEERCRED to communicate current user running the process. We are using grpc to communicate between the client and service.

Each client request is validated through polkit, matching user name and permissions. The daemon will reject any unauthorized client connections. Note that all actions are always performed from executing the client, even the scheduled one by a cron.

The daemon contains a python embedded script that uses samba utilities to connect with GSSAPI to the AD LDAP server and list available GPOs. GPOs are then downloaded in a cache directory which isn’t accessible to users.

The daemon also contains all GPOs policies to install on the Active Directory side to reflect them in the UI. This could be accessed online or dumped directly via the command line tool. Finally, those are automatically refreshed for any supported LTSes and intermediate versions. The availability of features can be different cross-release and is supported in the daemon.

Many utilities for debugging, following daemon or per transaction logs, streamed via our GRPC protocol are available.

We have different sync point with the system:
- at boot, the system will refresh the machine GPOs and build rules enforcements
- on login via the PAM module, which will:
a. download the machine GPOs if we couldn‘t before (due to no network available on boot/issues with NTP sync) and build rules enforcements
b. download the user-speciifc GPOs and build rules enforcements
- refresh every 30 minutes (same timing than windows client) the machine and all connected AD users GPOs, and rebuild rules enforcements if needed.

An offline mode (similar to SSSD) is available, so that you can carry your machine away of the network. The last successfully applied rules will still be enforced. Connection will be denied if you hadn’t connected once.

Documentation is available online (https://github.com/ubuntu/adsys/wiki) and also on the command line tool (offline). Note that updating the online documentation will update the command line tool one as an automated PR and updating the command line documentation will automatically update the wiki.

See original description

Didier Roche-Tolomelli (didrocks) on 2021-07-27

Changed in adsys (Ubuntu):
assignee:	nobody → Matthias Klose (doko)

Christian Ehrhardt  (paelzer) on 2021-09-14

Changed in adsys (Ubuntu):
assignee:	Matthias Klose (doko) → Lukas Märdian (slyon)

Revision history for this message

Lukas Märdian (slyon) wrote on 2021-09-15:

Download full text (5.3 KiB)

[Summary]
Overall this is looking fine, but we need to make sure to fix a few things around it. As this is a go binary with many vendorized dependencies, you also need to explicitly state your commitment to support the security team with security and dependency updates. Please do so in this bug report. Furthermore, you might add a team subscription to this package's bugs (though that can be done by an AA later on).

I'd also like you to take a look at some recommendations like fixing autopkgtests, fixing some lintian warnings and trying to avoid the "sudo" call in debian/control/tests. Those can be fixed after promotion to main as well.

This does need a security review, so I'll assign ubuntu-security (root daemon, vendorized code)
List of specific binary packages to be promoted to main: adsys

So this will be a MIR team ACK, once the required TODOs are fulfilled.

Notes:
This is a go package with many (>50) vendorized dependencies, but the owning team is using "dependabot" (from GitHub) to keep track of dependency/security updates.

Required TODOs:
- This is a static go binary, therefore the owning team must state the following commitment explicitly:
  * the owning team must state their commitment to test no-change-rebuilds triggered by a dependent library/compiler and to fix any issues found for the lifetime of the release (including ESM when included)
  * the owning team must provide timely testing of no-change-rebuilds from the security team, fixing the rebuilt package as necessary
  * the owning team must state their commitment to provide updates to the security team for any affected vendored code for the lifetime of the release (including ESM when included)
  * the owning team will provide timely, high quality updates for the security team to sponsor to fix issues in the affected vendored code

Recomended TODOs:
- Please add a team subscription (~desktop-packages?)
- Make autopkgtests pass (it's not a regression as the autopkgtests passed never before)
- Fix relevant lintian warnings (missing-notice-file-for-apache-license, hardening-no-pie)
- check if you could be using the "needs-root" restriction instead of "sudo" in debian/control/tests

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- Build-dependency: debhelper-compat is pure virtual, dh-apport is only a build-dependency and therefore OK to be in universe
- no -dev/-debug/-doc packages that need exclusion

Problems:
- NONE

[Embedded sources and static linking]
OK:
- Special case: this is a Go package, using dh-golang

Problems:
- embedded source present (53 vendorized go depdendencies)
- static linking (Built-Using)

[Security]
OK:
- history of CVEs does not look concerning, 0 CVEs so far, according to https://ubuntu.com/security/cve?q=&package=adsys&priority=&version=&status=
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port (but can be socket activated)
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop

Problems:
- does run a daemon as root (can be socket activated)
- does deal with system authenticatio...

This does need a security review, so I'll assign ubuntu-security (root daemon, vendorized code)
List of specific binary packages to be promoted to main: adsys

So this will be a MIR team ACK, once the required TODOs are fulfilled.

Notes:
This is a go package with many (>50) vendorized dependencies, but the owning team is using "dependabot" (from GitHub) to keep track of dependency/security updates.

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- Build-dependency: debhelper-compat is pure virtual, dh-apport is only a build-dependency and therefore OK to be in universe
- no -dev/-debug/-doc packages that need exclusion

Problems:
- NONE

[Embedded sources and static linking]
OK:
- Special case: this is a Go package, using dh-golang

Problems:
- embedded source present (53 vendorized go depdendencies)
- static linking (Built-Using)

Problems:
- does run a daemon as root (can be socket activated)
- does deal with system authentication (pam, polkit)
- does parse data formats (configuration files)

[Common blockers]
OK:
- does not FTBFS currently (builds for amd64, arm64, armhf, ppc64el, riscv64, s390x)
- does have a test suite that runs at build time
  - test suite fails will fail the build upon error.
- translation present in po/adsys.pot
- no new python2 dependency
- Go package that uses dh-golang

Problems:
- The package has no team bug subscriber (~desktop-packages?)
- this is a go package, extra constraints to consider in that regard
- does have a non-trivial test suite that runs as autopkgtest, but it has been failing every since

[Packaging red flags]
OK:
- Ubuntu does not carry a delta, it's a native Ubuntu package, no Debian upstream
- d/watch is not needed as this is a native package
- symbols tracking not applicable for this kind of code. (not a library)
- Upstream update history is good (but this is still a rather new package, first release in Feb'21, approx. 1 release per month since then)
- Debian/Ubuntu update history is good (following upstream)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far maintained the package (it's been maintained by the Desktop team, upstream and downstream)
- d/rules is rather clean
- Go Package that follows the Debian Go packaging guidelines (but not maintained by pkg-go team)
- is not on the lto-disabled list

Problems:
- Does have Built-Using (static Go binary)
- some Lintian warnings:
  E: adsys source: missing-notice-file-for-apache-license vendor/gopkg.in/yaml.v2/NOTICE vendor/gopkg.in/yaml.v3/NOTICE
  W: adsys: hardening-no-pie sbin/adsysd

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of user nobody
- no use of setuid (vendorized golang.org/x/sys dependency provides setuid functionality for UNIX/BSD, but not for Linux)
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks (will be installed in the background if AD is selected in the installer)
- use of sudo, gksu, pkexec, or LD_LIBRARY_PATH (sudo is used in autopkgtests d/tests/control only – that's fine)

Problems:
- NONE

Didier Roche-Tolomelli (didrocks) on 2021-09-15

Changed in adsys (Ubuntu):
assignee:	Lukas Märdian (slyon) → Ubuntu Security Team (ubuntu-security)
description:	updated

Revision history for this message

Didier Roche-Tolomelli (didrocks) wrote on 2021-09-15:

Thanks for the review! All comments should now be addressed.

Required TODOs:
* Statement is now clearly made in description

Recommended TODOs:
* subscription is now done
* autopkgtests: no sudo anymore and they pass with 0.7.1: https://autopkgtest.ubuntu.com/packages/adsys
* 0.7.1 ships the NOTICE file from yaml dependency
* 0.7.1 now specify -buildmode=pie

adsys 0.7.1 is now in the release pocket.

Revision history for this message

Lukas Märdian (slyon) wrote on 2021-09-15:

Thanks for working out the kinks, Didier!

MIR team ACK

Revision history for this message

Christian Ehrhardt  (paelzer) wrote on 2022-01-12:

It seems this is important for the 20.04.4 point release, so while we try to prioritize all the cases in the queue for security review let us set this to Critical + 20.04.4 Milestone.

Changed in adsys (Ubuntu):
importance:	Undecided → Critical
milestone:	none → ubuntu-20.04.4

Jean-Baptiste Lallement (jibel) on 2022-02-07

description:

updated

Revision history for this message

Seth Arnold (seth-arnold) wrote on 2022-02-24:

Download full text (4.4 KiB)

I reviewed adsys 0.8 as checked into jammy. This shouldn't be
considered a full audit but rather a quick gauge of maintainability. As
usual with golang code, there's vastly more code in the package than we've
authored, and it's not feasible to review the entirety.

adsys allows network administrators to include Ubuntu systems in Windows
Group Policy ecosystem. There's easy support for a lot of individual
tunable elements, as well as generic support for running both machine and
user scripts on login, logout, etc.

- CVE History:
  none :)
- Build-Depends?
  Build-Depends: debhelper-compat (= 13),
               dh-apport,
               dh-golang,
               golang-go (>= 2:1.16~),
               libsmbclient-dev,
               libdbus-1-dev,
               python3,
               python3-samba,
               samba-dsdb-modules,
               libpam0g-dev,
               samba,
               dbus,
- pre/post inst/rm scripts?
  mostly added automatically by dh_ helpers; registers and unregisters pam
  module, enables systemd units, purges and unmasks systemd units, etc.
- init scripts?
  none
- systemd units?
  sets up socket activation, sets up timers, refreshes policies, runs
  machine scripts in machine units, runs user scripts in user units
- dbus services?
  none
- setuid binaries?
  none
- binaries in PATH?
  adsysd, adsysctl
- sudo fragments?
  /etc/sudoers.d/99-adsys-privilege-enforcement is under control of the
  application:

"%admin ALL=(ALL) !ALL\n"
"%sudo ALL=(ALL:ALL) !ALL\n"

contentSudo += fmt.Sprintf("\"%s\" ALL=(ALL:ALL) ALL\n", e)

these are very powerful; I'd appreciate a second set of eyes here :)

- polkit files?
  yes, seems reasonable
- udev rules?
  none
- unit tests / autopkgtests?
  yes, many tests, run during the build
- cron jobs?
  none, systemd timer units used instead
- Build logs:
  the shell completion files are dumped during build, it's a bit noisy,
  but otherwise looks clean

- Processes spawned?
  Yes -- pam module, copied from pam_exec.c
  Yes -- adsys spawned from the user manager will run scripts, seems okay
- Memory management?
  Most is golang, safe enough
  pam module has some memory leaks; when reported to upstream pam_exec.c
  folks, they appear to be leaning towards leaking even more memory :) so
  probably fine.
- File IO?
  Some issues, raised elsewhere.
- Logging?
  pam module looked fine
- Environment variable usage?
  NO_COLOR and KRB5CCNAME, seemed safe
- Use of privileged functions?
  chown
- Use of cryptography / random number sources etc?
  none
- Use of temp files?
  none
- Use of networking?
  grpc; to the extent I looked at it, it felt safe enough
- Use of WebKit?
  none
- Use of PolicyKit?
  yes, internal/authorizer/authorizer.go
  looks up process start time by searching *backwards* through
  /proc/pid/stat file for a ), then looking forward 19 fields. I didn't
  double-check the math but it sure sounds promising.

- Any significant cppcheck results?
  memory leaks in pam_adsys.c, upstream for inspiration pam_exec didn't seem bothered
- Any significant Coverity results?
  none
- Any significant shellcheck results?
  none
- Any significant bandit results?
  none

ads...

Other bug subscribers

Remote bug watches

auto-github-grpc-grpc-go #5137
[closed] Edit
auto-github-olekukonko-tablewriter #199
[open] Edit

Bug watches keep track of this bug in other bug trackers.

Changed in adsys (Ubuntu):
status:	New → In Progress
assignee:	Ubuntu Security Team (ubuntu-security) → nobody

Changed in adsys (Ubuntu):
status:	In Progress → Fix Released

Ubuntuadsys package

[MIR] ADSys

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
adsys package