[MIR] linuxptp

[Alexandre Esse]

[MIR] linuxptp

[Availability]
The package linuxptp is already in Ubuntu universe.
The package linuxptp builds and works on all Ubuntu architectures.
Link to package: https://launchpad.net/ubuntu/+source/linuxptp

[Rationale]
Linux PTP is an open-source (GPL-2) software suite that is led by its main developer Richard Cochran and is supported by the Network Time Foundation (https://nwtime.org/).
The package linuxptp is generally useful for a part of our user base requiring a time synchronization of their system clocks in a network since it contains a PTP implementation compliant with the IEEE standard 1588. Especially users requiring higher precision than the one you can achieve with NTP. PTP is a standard synchronization solution that could be applied to systems such as automotive, telco, industrial or multimedia systems.

One specific reason for this MIR comes from the requirements of a commercial partner who would like to offer linuxptp as part of their user experience on their Ubuntu based SDK images. This partner is working with the Canonical Partner Engineering team, albeit the maintenance of linuxptp itself would likely be done by the Industrial team.

There are some alternatives to linuxptp::
ptpd: https://launchpad.net/ubuntu/+source/ptpd / http://ptpd.sourceforge.net/ : package exists but upstream project seems unmaintained (with missing tag on last identified version that blocks the package upstream source version update: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934275).
ptpd2: https://sourceforge.net/projects/ptpd2/ : fork of ptpd that also seems unmaintained.
ptpv2d: https://code.google.com/archive/p/ptpv2d/ : seems unmaintained.

Overall, linuxptp looks like the current leading solution for Linux PTP stack. And, there is no other/better way to solve this that is already in main.

[Security]

* CVE history:
In 2021: 2 High sensitive CVE about out-of-bounds read and write operations have been filled for linuxptp version prior to 3.1.1. The version 3.1.1 being actually dedicated to the fix of these two CVE only:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3570
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3571

* CVE status:
 There is a reference to the fix of these CVE on OpenWall:
https://www.openwall.com/lists/oss-security/2021/07/06/1
 As well as on Ubuntu CVE tracker:
https://ubuntu.com/security/cves?package=linuxptp
 With the associated Ubuntu Security Notice:
https://ubuntu.com/security/notices/USN-6097-1
 And Debian security tracker:
https://security-tracker.debian.org/tracker/source-package/linuxptp

* Project Changelog and associated commits:
```
Version 3.1.1

Fixes:

    CVE-2021-3570 linuxptp: missing length check of forwarded messages
    CVE-2021-3571 linuxptp: wrong length of one-step follow-up in transparent clock
```

https://sourceforge.net/p/linuxptp/code/ci/ce15e4de5926724557e8642ec762a210632f15ca/
https://sourceforge.net/p/linuxptp/code/ci/0b3ab45de6a96ca181a5cf62c3c2b97167e2ed20/

* Launchpad Bugs:
With a quick analysis: There is no Launchpad Bug referring to any security issue: https://bugs.launchpad.net/ubuntu/+source/linuxptp

Linked to linuxptp package: There is only one open bug related to the use of chronyd as the time backend(https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/2068526) that quickly got a valid proposition to fix here( https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/2032805/comments/11). This is a chronyd issue.

* Possible security flaws identified in the state of the art:

There are multiple articles about potential security issues while using PTP that got published (e.g. https://cybersecurity.springeropen.com/articles/10.1186/s42400-021-00080-y). A key sensitive point we identify is TLVs authentication that could lead to some security issues on PTP based stack (https://cybersecurity.springeropen.com/articles/10.1186/s42400-023-00140-5).

Further analysis should be done by the security team.

* Package content:

There are no SGID/SUID binaries in the current package:

On noble, running: cd /tmp/ && sudo apt download linuxptp && dpkg -c linuxptp_4.0-1_amd64.deb

Returns:
```
(...)
-rw-r--r-- root/root 263 2024-04-02 01:32 ./usr/lib/systemd/system/phc2sys@.service
-rw-r--r-- root/root 251 2024-04-02 01:32 ./usr/lib/systemd/system/ptp4l@.service
-rw-r--r-- root/root 359 2024-04-02 01:32 ./usr/lib/systemd/system/timemaster.service
(...)
-rwxr-xr-x root/root 14640 2024-04-02 01:42 ./usr/sbin/hwstamp_ctl
-rwxr-xr-x root/root 83760 2024-04-02 01:42 ./usr/sbin/nsm
-rwxr-xr-x root/root 91696 2024-04-02 01:42 ./usr/sbin/phc2sys
-rwxr-xr-x root/root 31112 2024-04-02 01:42 ./usr/sbin/phc_ctl
-rwxr-xr-x root/root 96640 2024-04-02 01:42 ./usr/sbin/pmc
-rwxr-xr-x root/root 182120 2024-04-02 01:42 ./usr/sbin/ptp4l
-rwxr-xr-x root/root 43320 2024-04-02 01:42 ./usr/sbin/timemaster
-rwxr-xr-x root/root 91616 2024-04-02 01:42 ./usr/sbin/ts2phc
-rwxr-xr-x root/root 58816 2024-04-02 01:42 ./usr/sbin/tz2alt
(...)
```

Currently:
- 9 binaries are installed on /usr/sbin.
- 3 systemd services are deployed, two of which are templates units (@*). These services are not enabled nor started by default.

* Privileged ports:

There are multiple network usage modes for linuxptp: transport over UDP/IPv4, UDP/IPv6, and raw Ethernet (Layer 2).

We haven't done any dynamic tests on this point. However: After a static code analysis: we can point out that UDP port 319 and 320 might be used by the binaries. (see udp.c and udp6.c lines 40 and 41).

These ports are open for good reasons (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt):
Port 319 is registered to IANA for ptp-event
Port 320 is registered to IANA for ptp-general

* External endpoints:

linuxptp exposes external endpoints depending on its usage. For instance: ptp4l handles communication between PTP nodes and then might create some endpoints dedicated to these communications. These endpoints are described on the IEEE 1588 specification (https://standards.ieee.org/ieee/1588/4355/) as PTP management messages with different possible actions:
GET action: Get current values of data
SET action: Update current values of variables
CMD action: Initiate some events

In order to interact with these endpoints: pmc binary (PTP management client) is used with 4 different possible modes: IEEE 802.3 (L2), UDP/IPv4, UDP/IPv6 or local UDS (Unix Domain Socket).

For example: In case of local UDS usage: /var/run/pmc.$pid and /var/run/ptp4l are used as endpoints.

* Extensions to security-sensitive software:

linuxptp does not contain extensions to security-sensitive software.

[Quality assurance - function/usage]

After installing the package, a ptp use case should be enabled with a reasonable amount of configuration and system setup.

[Quality assurance - maintenance]

The package seems well maintained in Debian, Ubuntu and upstream and does not have too many long-term & critical open bugs:
- Ubuntu https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=linuxptp
- linuxptp-devel Mailing list: https://lists.nwtime.org/sympa/arc/linuxptp-devel/
- linuxptp-users Mailing list: https://lists.nwtime.org/sympa/arc/linuxptp-users/

It is to be noted that the mailing list changed on 2023-12-07. (previous location: https://sourceforge.net/p/linuxptp/mailman/linuxptp-devel/)

- The package does not deal with exotic hardware we cannot support (however, there is some hardware requirements to use all features of the package: i.e. hardware timestamping).

[Quality assurance - testing]
- The package doesn’t include a non-trivial test suite yet: then, it doesn’t run at package build and fails the build if broken.

- The package does not run a test at build time because there is no upstream defined testsuite yet.

- Testing all linuxptp feature requires some specific hardware that we have access to.

However, two alternative testing solutions are available:

A testsuite available here: https://github.com/mlichvar/linuxptp-testsuite

With an associated simulator solution: https://github.com/mlichvar/clknetsim

An existing checkbox test jobs that are checking PTP interface capabilities and also use ptp4l: https://github.com/canonical/checkbox/blob/4ddf0fca2bd0cc3b74fe6a6edcea1975cc9bad06/contrib/checkbox-provider-ce-oem/units/ptp/jobs.pxu

- The package for oracular contains autopkgtests. These have been contributed recently and are maintained by the Industrial team: https://git.launchpad.net/ubuntu/+source/linuxptp/tree/debian/tests?h=applied/ubuntu/oracular .

[Quality assurance - packaging]
- debian/watch is present and works

But, we need to be careful if this is still valid in the future because for instance the mailing list moved away from sourceforge.

- debian/control defines a correct Maintainer field: Debian Multimedia Maintainers <email address hidden>

- This package does not yield massive lintian Warnings, Errors

- This package does not rely on obsolete or about to be demoted packages.

- The package does not ask debconf questions

- Packaging and build is easy, link to debian/rules: https://salsa.debian.org/multimedia-team/linuxptp/-/blob/master/debian/rules?ref_type=heads

[UI standards]
- Application is not end-user facing (does not need translation)

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

[Standards compliance]
- This package correctly follows FHS and Debian Policy

[Maintenance/Owner]
- The owning team should be the Server team

- The future owning team is not yet subscribed, but will subscribe to the package before promotion

- This does not use static builds

- This does not use vendored code

- This package is not rust based

- The package successfully built during the most recent test rebuild (https://launchpad.net/ubuntu/+source/linuxptp/4.0-1).

[Background information]
The Package description explains the package well. Upstream Name is linuxptp.
Link to upstream project: https://linuxptp.sourceforge.net/

[Alexandre Esse (ahresse)]

This MIR is a joint request with Industrial team (@farshidtz & @jpm)

[Christian Ehrhardt  (paelzer)]

Review for Source Package: linuxp2p

[Summary]
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: linuxptp
Specific binary packages built, but NOT to be promoted to main: -

Required TODOs:
- #1 This is exposed externally and runs with high permission as well as
     influence due to the importance of time to certificate checks. I really
     would want to see better use of isolation features before we encourage
     use more widely. In particular please look at:
     - surely: use a lof of the systemd isolation features
     - surely: create and test apparmor profiles for the binaries that run
               as service
     - maybe: running less privileged
- #6 Please merge the latest version (4.2 at the moment)

Recommended TODOs:
- #2 I'm happy to see that you have added clknetsim based autopkgtests already.
     But since this has no build time tests at all and also upstream testing
     seems to be manual according to https://linuxptp.sourceforge.net/ we should
     try to do a bit more. The content in debian/tests/linuxptp-testsuite is the
     same as clknetsim - so I guess that can be removed.
     I'm not sure what can be done without upstreams support on e.g. unit
     tests. But I'd ask to discuss it with them and refer the discussion here.
     If there is something that could be done, do it. Otherwise at least we
     know why.
- #3 You mentioned that checkbox, but that includes setup steps with physical
     access to the device. Could you outline how one could trigger these tests
     (e.g. after a bigger change or merge) themselve. Or if it really needs
     a person in front of the device who would be needed to get contacted to
     run such a test against a new build e.g. in a PPA?
- #4 If we'd onboard that today (not a MIR rule, but a server team rule since
     we shall own it later) it would also need some reasonable documentation
     entries like https://ubuntu.com/server/docs/how-to-serve-the-network-time-protocol-with-chrony
     Along your testing e.g. to get isolation right you will have gained the
     experience how to set this up well which will enable you to write that.
- #5 submit the Delta (your testing and the former config path change) to Debian
     Nothing we have is super-special, mostly added QA which helps us as well
     if spotted earlier or even in Debian already.
- #7 There are some bugs open that can get very painful later but need some
     time to dive deeper to get fixed. In particular into how it can manage
     service dependencies to its configured network devices better.
     Some are easy, other might need complex things, maybe even netlink
     enablement in the code? But it does not have to be that complex, the
     services should wait on %I network device and php2sys waits on a
     synchronized ptp4l. Yet the bug exists so give these an evaluation so
     we only skip them once we have a good reason why:
      - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004744
      ...