** Description changed: 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 + Ubuntu 26.04.1 LTS (also affects Stonking) 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_module, + capability net_bind_service, + capability net_raw, + capability sys_time, @@ - @{run}/ptp4l rw, - @{run}/ptp4lro rw, - @{run}/phc2sys.[0-9]+ r, + @{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 + 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 + 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 + sudo /usr/sbin/ptp4l -S -i ptprepro0 -m - This should report: "failed to set the clock status: Operation not + 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' + sudo pmc -u -b 0 'GET CURRENT_DATA_SET' - pmc should print "sending: GET CURRENT_DATA_SET" but should not + pmc should print "sending: GET CURRENT_DATA_SET" but should not receive a response Check the kernel log - sudo journalctl -k | grep 'profile="ptp4l"' + 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" + 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' + 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 + 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. + + The pathname rule allows ptp4l to read and write to items matching + `/run/pmc.[0-9]*`. If the pattern was incorrect or overly broad, ptp4l + can access unrelated items with a matching name, or a valid pmc item may + remain inaccessible.
** Patch added: "linuxptp_4.4-0ubuntu2_stonking.debdiff" https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/2169218/+attachment/6005102/+files/linuxptp_4.4-0ubuntu2_stonking.debdiff -- 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: ptp4l AppArmor profile blocks system clock adjustment and pmc replies 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
