linux-kernel - Re: [PATCH] firmware/dmi: Print product serial number if any

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: <CAL2JzuyvsTtUBB8VpbiuKJ2b6vEU_zLYELeYn-pm3-e82AbB_g@mail.gmail.com>
Date:   Wed, 12 Oct 2022 14:11:16 +0200
From:   Erwan Velu <erwanaliasr1@...il.com>
To:     Jean Delvare <jdelvare@...e.com>
Cc:     "e.velu@...teo.com" <e.velu@...teo.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] firmware/dmi: Print product serial number if any

[...]
> I see the value of this change. However it raises a privacy concern. So
> far, /sys/devices/virtual/dmi/id/product_serial is only readable by
> root. Writing the same string to the kernel log where everybody can
> read it is thus questionable.
>
> I can think of 2 ways to solve that problem:
> 1* I'm not really sure why the serial numbers stored in the DMI table
> were originally considered a secret. So we could change these sysfs
> attributes to mode 644, and then printing them in the kernel log would
> of course be OK.
> 2* We could make your code dependent on
> CONFIG_SECURITY_DMESG_RESTRICT=y. If dmesg is restricted to root then
> including the serial number there is OK, regardless of the permissions
> of /sys/devices/virtual/dmi/id/product_serial .
>
> For simplicity I'd go with option 1, but if people strongly disagree
> with making serial numbers world-readable, we can go with option 2.


Yeah I don't really see why showing a serial host in a dmesg is a
security problem.
We already expose other serials like disk or mac addresses which could
be considered private in the same way.


> Now from an implementation perspective, you chose to go with
> DMI_PRODUCT_SERIAL. That will work fine for vendor systems, however for
> self-assembled systems, DMI_PRODUCT_SERIAL is typically unset and
> DMI_BOARD_SERIAL would be more relevant. So it may make sense to
> fallback to "BSN: <DMI_BOARD_SERIAL>" if DMI_PRODUCT_SERIAL is unset.
> Unless you think such systems are out of scope for the intended purpose
> anyway, in which case your code is OK.

Note we have already the same issue with DMI_BIOS_VERSION vs DMI_BIOS_RELEASE.
On HPE system, reported the VERSION is useless as it points to the
motherboard type (U30/U32..) while the release field is the 'version'
like 2.56. On ODM systems, that is the opposite. \o/