netdev - Re: [PATCH] ptp: Add sysfs attribute to show clock is safe to open RO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c2d4a2ce-8af6-4dda-87e5-2cff14fd14b1@linux.dev>
Date: Wed, 14 May 2025 16:25:43 +0100
From: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
To: Andrew Lunn <andrew@...n.ch>, Wojtek Wasko <wwasko@...dia.com>
Cc: richardcochran@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ptp: Add sysfs attribute to show clock is safe to open RO

On 14/05/2025 15:54, Andrew Lunn wrote:
> On Wed, May 14, 2025 at 05:36:21PM +0300, Wojtek Wasko wrote:
>> Recent patches introduced in 6.15 implement permissions checks for PTP
>> clocks. Prior to those, a process with readonly access could modify the
>> state of PTP devices, in particular the generation and consumption of
>> PPS signals.
>>
>> Userspace (e.g. udev) managing the ownership and permissions of device
>> nodes lacks information as to whether kernel implements the necessary
>> security checks and whether it is safe to expose readonly access to
>> PTP devices to unprivileged users. Kernel version checks are cumbersome
>> and prone to failure, especially if backports are considered [1].
>>
>> Add a readonly sysfs attribute to PTP clocks, "ro_safe", backed by a
>> static string.
> 
> ~/linux$ grep -r "ro_safe"
> ~/linux$
> 
> At minimum, this needs documentation.
> 
> But is this really the first time an issue like this has come up?

I haven't seen such kind of discussions previously, but it's more about
netdev area only. The original problem was kinda hidden because all
modern distros had udev rules preventing non-root access to PHC devices,
which effectively means no strict access checks are needed. I cannot
find a good example of device with the same issues quickly...

> Also, what was the argument for adding permission checks, and how was
> it argued it was not an ABI change?

The original discussion was in the thread:

https://lore.kernel.org/netdev/DM4PR12MB8558AB3C0DEA666EE334D8BCBEE82@DM4PR12MB8558.namprd12.prod.outlook.com/

while the change has landed in:

https://lore.kernel.org/netdev/20250303161345.3053496-1-wwasko@nvidia.com/