netdev - Re: [PATCH net-next] ptp: Add file permission checks on PHC

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] [day] [month] [year] [list]

Message-ID: <Z6YmHF6AeOwYkg8p@hoboy.vegasvil.org>
Date: Fri, 7 Feb 2025 07:26:20 -0800
From: Richard Cochran <richardcochran@...il.com>
To: Wojtek Wasko <wwasko@...dia.com>
Cc: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"vadim.fedorenko@...ux.dev" <vadim.fedorenko@...ux.dev>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"horms@...nel.org" <horms@...nel.org>
Subject: Re: [PATCH net-next] ptp: Add file permission checks on PHC

Wojtek,

The commit message is much impoved, thanks.

On Thu, Feb 06, 2025 at 11:03:35AM +0000, Wojtek Wasko wrote:
> Many devices implement highly accurate clocks, which the kernel manages
> as PTP Hardware Clocks (PHCs). Userspace applications rely on these
> clocks to timestamp events, trace workload execution, correlate
> timescales across devices, and keep various clocks in sync.
> 
> The kernel’s current implementation of PTP clocks does not enforce file
> permissions checks for most device operations except for POSIX clock
> operations, where file mode is verified in the POSIX layer before forwarding
> the call to the PTP subsystem. Consequently, it is common practice to not give
> unprivileged userspace applications any access to PTP clocks whatsoever by
> giving the PTP chardevs 600 permissions. An example of users running into this
> limitation is documented in [1].
> 
> This patch adds permission checks for functions that modify the state of

Can you change the wording to imperative voice please?
(grep for "this patch" under Documentation)

> a PTP device. POSIX clock operations (settime, adjtime) continue to be
> checked in the POSIX layer. One limitation remains: querying the
> adjusted frequency of a PTP device (using adjtime() with an empty modes
> field) is not supported for chardevs opened without WRITE permissions,
> as the POSIX layer mandates WRITE access for any adjtime operation.

> @@ -108,16 +108,20 @@ int ptp_open(struct posix_clock_context *pccontext, fmode_t fmode)
>  {
>  	struct ptp_clock *ptp =
>  		container_of(pccontext->clk, struct ptp_clock, clock);
> +	struct ptp_private_ctxdata *ctxdata;
>  	struct timestamp_event_queue *queue;
>  	char debugfsname[32];
>  	unsigned long flags;
>  
> -	queue = kzalloc(sizeof(*queue), GFP_KERNEL);
> -	if (!queue)
> +	ctxdata = kzalloc(sizeof(*ctxdata), GFP_KERNEL);
> +	if (!ctxdata)
>  		return -EINVAL;
> +	ctxdata->fmode = fmode;

This will fix the issue only for the PTP "sub-class" of posix clock...

> +struct ptp_private_ctxdata {
> +	struct timestamp_event_queue queue;
> +	fmode_t fmode;
> +};

Can you please move the `fmode` into `posix_clock_context` ?
(or maybe even the whole `struct file`)
(the change to posix-clock.c can be a separate patch)

In that way,

1) Future implementations of posix clock ops will not repeat the same bug.

2) Less churn in ptp_open()


Thanks,
Richard