Public bug reported: The AppArmor profile shipped by the linuxptp package is missing permissions required for software timestamping (-S) and communication with the local PTP management client via /run/pmc.<pid>.
Ubuntu 26.04.1 LTS linuxptp 4.4-0ubuntu1 apparmor 5.0.2-0ubuntu1~26.04.1 [ Impact ] The ptp4l process remains running, so the failure is not immediately obvious. In software-timestamping mode (-S) it reports `failed to set the clock status: Operation not permitted`. A local pmc query sends its request but receives no response. So although ptp4l remains alive and may continue exchanging PTP messages, it cannot perform privileged system clock adjustments which are its primary synchronization function in -S mode, while the pmc failure prevents local monitoring and tools from querying ptp4l's datasets or receiving responses to requests. With -S, during init, ptp4l calls sysclk_set_leap(0) which uses clock_adjtime(CLOCK_REALTIME, ...) with ADJ_STATUS. The kernel requires CAP_SYS_TIME for this operation to be permitted. The packaged [email protected] already has: CapabilityBoundingSet=CAP_SYS_ADMIN CAP_SYS_TIME, and the packaged phc2sys AppArmor profile already grants sys_time, but the profile for ptp4l does not contain `capability sys_time,`. For the management failure, pmc -u binds a temp client socket `/var/run/pmc.<pid>` which resolves to `/run/pmc.<pid>`. It sends a request to /run/ptp4l and ptp4l sends its response back to the client socket. The profile permits the ptp4l server sockets but has no rule for the pmc client pathname. The following rules should be added to debian/usr.sbin.ptp4l --- a/debian/usr.sbin.ptp4l +++ b/debian/usr.sbin.ptp4l @@ capability sys_module, capability net_bind_service, capability net_raw, + capability sys_time, @@ @{run}/ptp4l rw, @{run}/ptp4lro rw, @{run}/phc2sys.[0-9]+ r, + @{run}/pmc.[0-9]* rw, A read-only rule is insufficient for the pmc case; after adding only `@{run}/pmc.[0-9]* r,` ptp4l was able to receive the request but its response was denied with: `apparmor="DENIED" operation="sendmsg" class="file" profile="ptp4l" name="/run/pmc.<pid>" comm="ptp4l" requested_mask="w" denied_mask="w"` [ Test Plan ] Install linuxptp and create a veth pair: sudo apt install linuxptp sudo ip link add ptprepro0 type veth peer name ptprepro1 sudo ip addr add 192.0.2.1/24 dev ptprepro0 sudo ip link set ptprepro0 up sudo ip link set ptprepro1 up Confirm that the packaged ptp4l profile is loaded in enforce mode: sudo grep -Fx 'ptp4l (enforce)' /sys/kernel/security/apparmor/profiles In one terminal, start ptp4l with -S sudo /usr/sbin/ptp4l -S -i ptprepro0 -m This should report: "failed to set the clock status: Operation not permitted" In another terminal, query it sudo pmc -u -b 0 'GET CURRENT_DATA_SET' pmc should print "sending: GET CURRENT_DATA_SET" but should not receive a response Check the kernel log sudo journalctl -k | grep 'profile="ptp4l"' The log should contain denials corresponding to both failures: apparmor="DENIED" operation="capable" class="cap" profile="ptp4l" comm="ptp4l" capability=25 capname="sys_time" apparmor="DENIED" operation="sendmsg" class="file" profile="ptp4l" name="/run/pmc.<pid>" comm="pmc" requested_mask="r" denied_mask="r" Stop ptp4l before continuing To test the proposed rules independently of a rebuilt package, add: sudo install -d -m 0755 /etc/apparmor.d/local sudo tee /etc/apparmor.d/local/usr.sbin.ptp4l >/dev/null <<'EOF' capability sys_time, @{run}/pmc.[0-9]* rw, EOF Reload the complete packaged profile and confirm it is still in enforce mode: sudo apparmor_parser -r -T /etc/apparmor.d/usr.sbin.ptp4l sudo grep -Fx 'ptp4l (enforce)' /sys/kernel/security/apparmor/profiles Repeat the test above. ptp4l should init without reporting "failed to set the clock status: Operation not permitted" and the pmc query should receive a response containing "RESPONSE MANAGEMENT CURRENT_DATA_SET". Re-checking the kernel log should reveal no new denials for the ptp4l profile. If verifying with a rebuilt package from a PPA or from -proposed, simply install the candidate linuxptp package, confirm it contains the two new rules, and repeat the test above without installing the local override. [ Where problems could occur ] CAP_SYS_TIME permits adjustment of the system clock. Although the rule does not grant the capability by itself (only allows ptp4l to use it when it already possesses it under standard Linux and systemd capability rules), a compromised or seriously misconfigured ptp4l could affect anything relying on the system clock. Controlling a clock is an intended function of ptp4l in -S mode, the packaged systemd unit already includes CAP_SYS_TIME in its capability set, and the phc2sys profile permits the same capability. ** Affects: linuxptp (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2169218 Title: AppArmor profile blocks ptp4l timestamping and communication with pmc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/2169218/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
