linux-kernel - Re: [PATCH] firmware: dmi: Don't restrict access to serial number / UUID

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: <ZIcDk2XIePJidxW5@gardel-login>
Date:   Mon, 12 Jun 2023 13:37:55 +0200
From:   Lennart Poettering <mzxreary@...inter.de>
To:     Jonathan McDowell <noodles@...a.com>
Cc:     Jean Delvare <jdelvare@...e.com>,
        Kay Sievers <kay.sievers@...y.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware: dmi: Don't restrict access to serial number /
 UUID

On Mo, 12.06.23 09:59, Jonathan McDowell (noodles@...a.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