linux-kernel - Re: [PATCH] dmi: export dmi data through debugfs

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: <20100929171118.1dbf3fbb@endymion.delvare>
Date:	Wed, 29 Sep 2010 17:11:18 +0200
From:	Jean Delvare <khali@...ux-fr.org>
To:	Olof Johansson <olof@...om.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] dmi: export dmi data through debugfs

On Wed, 29 Sep 2010 09:53:30 -0500, Olof Johansson wrote:
> On Wed, Sep 29, 2010 at 09:34:03AM +0200, Jean Delvare wrote:
> > Hi Olaf,
> > 
> > On Tue, 28 Sep 2010 16:12:46 -0500, Olof Johansson wrote:
> > > I've found this quite useful since it allows dmidecode to run without
> > > root privileges using --from-dump to read this file instead
> > 
> > This is a bad idea. We do NOT want every user to have access to all the
> > DMI information. There is sensitive information in there (serial
> > numbers and UUIDs, and possibly even more sensitive data in
> > OEM-specific records.) If you look in /sys/class/dmi/id/, you'll see
> > that files board_serial, chassis_serial, product_serial and
> > product_uuid are only readable by root exactly for this reason.
> 
> > So this is a NACK from me, sorry.
> 
> So how about a change to mode 0400 on the debugfs file then?

This is a requirement, yes.

> It's
> still better than having a userspace tool dig around /dev/mem for the
> information.

How is that better, please? Unless /dev/mem is going away, I don't see
any benefit. "Digging around" is exactly what the kernel is doing to
get the information. dmidecode has been around for over 7 years now,
it's always been reading its information from /dev/mem, and while there
has been some technical challenge with this (mmap vs. read) it has been
solved long ago.

And we now have an option limiting what can be accessed
through /dev/mem (CONFIG_STRICT_DEVMEM), so we should be safe.

The only objection I ever heard is that one had to be rootto run
dmidecode, but there's no way to address this, which is why the
relevant DMI strings are now exposed through sysfs. If there's a string
you consider useful which is missing there, you could just add it.

Now if you really insist on exposing the whole DMI table through sysfs,
I can't prevent you from doing that. After all, ACPI already exposes
its tables under /sys/firmware/acpi/tables (mode 0400). But then you'd
rather expose the DMI entry point and tables
under /sys/firmware/dmi/tables for consistency, rather than using
debugfs. But again, I don't think it is adding any value over what we
already have.

Please note that anyway, dmidecode is not going to stop getting the
table from /dev/mem, because it is used on several non-Linux operating
systems (all the BSDs in particular) which do not have sysfs.

-- 
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/