On Wed, Oct 17, 2007 at 08:58:25PM +0000, Steven M. Bellovin wrote:
> On Wed, 17 Oct 2007 22:07:26 +0200
>
> Hmm, I'm not convinced about this one.  There tend to be other
> effectively-unique IDs, such as MAC addresses; I'm not sure that
> locking down just this set helps much.  (Aside: the P3 issue wasn't
> real.  Anyone who had enough access to query the CPU serial number
> had enough access to find lots of other serial numbers, including the
> set that Thor would like.)
> 
> It would help this part of the discussion, I think, if I understood
> better how the information would be used.  What programs or daemons
> would query it?  Would they run as root?  

Well, my intention was very much to _not_ require processes obtaining
this information to run as root -- after all, you can get the information
now using tools like dmidecode, but there's a significant security exposure
associated with configuring your system so you can run those.

I have two purposes for wanting this information, both relating to
commercial use of NetBSD, plus a third purpose that may be more general.

1) At work, we've had support cases where customers had mixed and matched
   pieces of systems to produce system types we never contemplated and
   can't support.  I'd like to be able to get basic system type information
   from the operating system kernel that tells me, at least, that the
   system with serial number _X_ has the mainboard I expect for such a
   system.  This would also have been very useful when I was supporting
   large numbers (>100) NetBSD systems in an academic environment at
   Stevens Tech.

2) Where there's a system serial number -- or more than one -- I'd like
   to be able to use it for product licensing.  A number of our competitors
   have had trouble with their system hardware being copied in China and
   installed with their genuine software.  There's no way to frustrate a
   really determined adversary here, but if I can require him to obtain
   components that fall into the same serial number ranges I know I actually
   shipped, or find out those ranges, avoid duplicates, and re-serialize
   a bunch of components, I can make his life a lot harder.

3) Some of this data is effectively write-once: if you're a large customer
   you can have Dell or HP write a custom value to the "asset tag" field
   of the SMBIOS data when building your system.  This is really useful
   for large IT organizations in the academic and government sectors: it
   lets them remotely audit their hardware deployments.

Unfortunately, because for many of the kinds of serial numbers available
on current hardware, the serial numbers are unique only per vendor and
product, I need the information from #1 to do #2.

I'd like to find a middle ground so system administrators can keep random
users of their systems from getting this information, but at the same time
code that uses it doesn't have to run as root.  Of course, this would be
easy with filesystem permissions, but a filesystem seems an extremely odd
fit for the retrieval and display of fundamentally MD data.  Perhaps ioctl
on a device node, as for NTP; it somehow seems a little less elegant than
just exposing the basically tree-structured data by sysctl, though.

Thor