From: Lennart Poettering <mzxreary@0pointer.de>
To: Jonathan McDowell <noodles@meta.com>
Cc: Jean Delvare <jdelvare@suse.com>,
Kay Sievers <kay.sievers@vrfy.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] firmware: dmi: Don't restrict access to serial number / UUID
Date: Mon, 12 Jun 2023 13:37:55 +0200 [thread overview]
Message-ID: <ZIcDk2XIePJidxW5@gardel-login> (raw)
In-Reply-To: <ZIbslWZev/Ayoug5@noodles-fedora.dhcp.thefacebook.com>
On Mo, 12.06.23 09:59, Jonathan McDowell (noodles@meta.com) wrote:
> The /sys/devices/virtual/dmi/id/*_serial + product_uuid files are
> currently only readable by root. There's no clear rationale for this;
> Windows + OS X both allow regular users to access the information, so
> there appears to be no expectation on the manufacturer side that it
> should be kept secret.
>
> Having the information easily available helps with automated tools that
> collect system information for the purposes of fault diagnosis/tracking
> without requiring the tools have root access.
>
> (I've tried to look for context on the initial patch submission about
> why these were root-only but didn't find any; hopefully Lennart or Kay
> can provide details if I'm missing something.)
When I originally added this in 2007 the intel cpuid serial numbers
kerfuffle wasn't ancient history yet, i.e. see:
https://en.wikipedia.org/wiki/Pentium_III#Controversy_about_privacy_issues
So we wanted to ensure that potentially identifying hw information
would not leak to unprivileged code just like that so easily, hence
restricting this was the easy way out.
We subsequently came up with the /etc/machine-id concept, i.e. a
*user* controlled ID value people can use instead. And for VMs we then
added logic so that the VM supplied UUID can be propagated into that
(under the assumption that the VM supplied UUID is under user control
anyway).
To my knowledge on ChromeOS the /etc/machine-id concept isn't much
liked either, they'd rather have *no* identifiable info available to
unpriv code instead of just user controllable ids... (i remember some
conversations with chromeos people back in the day about this.) if you
open up the DMI serial numbers like this you might not make yourself
many friends in that camp...
One might argue that there's always some identifiable hw info available
for apps to use, or that apps should run in sandboxes that make this
impossible, but that's cheap of course…
Lennart
--
Lennart Poettering, Berlin
next prev parent reply other threads:[~2023-06-12 11:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 9:59 [PATCH] firmware: dmi: Don't restrict access to serial number / UUID Jonathan McDowell
2023-06-12 10:25 ` Greg Kroah-Hartman
2023-06-12 11:37 ` Lennart Poettering [this message]
2023-06-16 9:47 ` Jean Delvare
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZIcDk2XIePJidxW5@gardel-login \
--to=mzxreary@0pointer.de \
--cc=gregkh@linuxfoundation.org \
--cc=jdelvare@suse.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noodles@meta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox