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:
 <DM4PR12MB85587C371F5C20707BA61FF7BE90A@DM4PR12MB8558.namprd12.prod.outlook.com>
Date: Thu, 15 May 2025 12:48:33 +0000
From: Wojtek Wasko <wwasko@...dia.com>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>, Andrew Lunn <andrew@...n.ch>
CC: "richardcochran@...il.com" <richardcochran@...il.com>,
	"netdev@...r.kernel.org" <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:
> ~/linux$ grep -r "ro_safe"
> ~/linux$
>
> At minimum, this needs documentation.

Noted. I'll take care of that in v2.

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

Tightening of permission checks without providing backward compat doesn't seem
to be uncommon. One example I found is Greg K-H's cleanup of mtd driver ioctls
and the subsequent further tightening of mtd ioctl permission checks in
response to CVE-2021-47055:
https://lore.kernel.org/linux-mtd/20200716115346.GA1667288@kroah.com/
https://lore.kernel.org/linux-mtd/20210303155735.25887-1-michael@walle.cc/

Another, older example of "silent" tightening of capabilities/permissions
checks can be found in the SCSI aacraid driver:
https://lore.kernel.org/lkml/20070723145105.01b3acc3@the-village.bc.nu/

> But is this really the first time an issue like this has come up?

I agree with Vadim on this - this issue is a little bit special in that the
original bug was "hidden". In all the examples I could find, security issues
were exposed directly and so the kernel patches "silently" closed the security
hole.  In the case of PTP chardev, udev covered the security issue by
completely disallowing unprivileged access to PTP chardevs - a workaround of
sorts.  So what is needed now is a way to tell udev that the security hole is
fixed and the "workaround" can be disabled, i.e. the device is safe to be
exposed readonly to unprivileged users.

Thanks,
Wojtek