Configurable Hostids for Non-Global Zones [PSARC/2008/647 FastTrack timeout 10/30/2008]

[Jordan Vaughan]

Darren J Moffat wrote:
> Given that 2007/078 stores the hostid in /etc/hostid (for x86 only) was 
> any consideration given to just using the same mechanism for zones 
> rather than having a different one ?
> 

Yes, I considered it for a time but settled on the solution presented in 
the case because storing a non-global zone's hostid in its configuration 
file is consistent with the current way the zones subsystem works. 
Pertinent zone configuration information is stored in the zone's 
configuration file, so it seems natural to store hostid information 
there as well.  Furthermore, splitting a zone's configuration across 
many files (say, the zone's XML configuration file in /etc/zones and the 
zone's /etc/hostid file) unnecessarily complicates zone configuration 
and booting.  For example, suppose we want to configure a new zone with 
some hostid.  If the zone does not already exist (i.e., if it is not 
installed), then where would we store the hostid?  In the zone's 
configuration file.  But if it will be stored in the zone's 
configuration file, then why create a separate /etc/hostid file for the 
zone later when the hostid is already accessible in the zone's 
configuration file?  Storing a zone's hostid in an /etc/hostid file is 
superfluous.

Additionally, James Carlson made a good point about the security 
provided by storing non-global zone hostids in their /etc/zone 
configuration files.


Darren J Moffat wrote:
 > Why is it acceptable to have a zone's hostid in the clear in the 
global zone /etc/zone/<zonename>.xml for SPARC and x86 file yet it isn't 
acceptable to have the hostid in the clear in /etc/hostid for x86 - even 
when the source code for the silly obfuscation is open source.
 >

What exactly is your concern?  If it is the inconsistency between my 
case and PSARC/2007/078 in that /etc/hostid is obfuscated and non-global 
zone hostids (as stored in their configuration files) are not, then I 
agree that obfuscating the system's hostid is pointless given that 
anyone can examine the source and discover how to circumvent it.  I am 
in favor of removing the obfuscation in /etc/hostid, but I hesitate to 
agree that this falls within the scope of my case.


Brian Ruthven wrote:
 > Just to make sure this has been covered:
 >
 > PSARC/2007/078 (hostids for x86) mentions the legal implications of 
software licensing against hostids. This case proposes that the hostids 
are user-supplied, thus may need a Sun Legal check too.
 >
 > Brian
 >


If I remember correctly (please correct me if I am misunderstanding your 
reference), the concern in the PSARC/2007/078 mail was that placing the 
system's hostid in an /etc/hostid ASCII file would not only invite more 
license circumvention, but also make it appear as though we (Sun) are 
encouraging license circumvention and thus betraying our ISVs that use 
hostids for licensing.  Are you concerned that non-global zone hostid 
emulation might have similar consequences?  If so, then I would argue 
that the concern is unwarranted in this case.

We must remember that zones are configurable virtualized execution 
environments, like virtual operating systems.  (I say this not because I 
think you do not already know it, but to focus our attention on the 
purpose of zones in order to make a more salient point.)  They are 
*meant* to look and feel like machines distinct from their physical 
host.  Emulating hostids is simply another way to customize the 
virtualized environments that zones provide so that system consolidation 
can be more easily facilitated with zones and zone migration across 
physical nodes can be more flexible when legacy licensed software is in 
jeopardy (as my case states).  We are providing non-global zone hostid 
emulation for these reasons alone and should clearly state this in our 
documentation (as I made an effort to do in my proposed man page changes).

It is possible that license circumvention might increase slightly with 
the introduction of non-global zone hostid emulation, but I doubt that 
it would be a significant increase.  For one thing, faking hostids is 
already possible and easily accomplished (for example, see 
http://www.software.com/downloads/purchase/Solaris-Hostid-Controller-buy833075.html). 
  If a user wants to circumvent hostid-based licensing, then he can do 
so today in a variety of ways at little or no cost (except perhaps two 
minutes of his time) with Sun-developed technologies.  Adding non-global 
zone hostid emulation will not open any new doors to unscrupulous users. 
  Additionally, using non-global zones for the sole purpose of 
circumventing licensing for a handful of programs is a relatively 
expensive solution to an easily-solved problem.  Zones take disk space, 
cpu time, and memory, whereas a five- or six-line DTrace script that 
intercepts sysinfo(2) system calls is much cheaper.  Non-global zone 
hostid emulation will not enlarge the hostid-based licensing 
circumvention problem that our ISVs already face.

Furthermore, I claim that if users were to abuse hostid emulation to 
circumvent software licensing, a use which would not fall within our 
stated (documented) intentions for the technology, then we would not be 
responsible for their actions.  If arguing that the potential for such 
abuse justifies rejecting non-global zone hostid emulation, then 
destructive DTrace scripting should be eliminated because of the ability 
it grants users to (easily) circumvent hostid-based software licensing. 
  However, I imagine that we would not eliminate destructive DTrace 
scripting or consider providing it a betrayal of our ISVs because such 
abuses fall outside of the stated purposes for the technology.  If that 
is the case, then non-global zone hostid emulation should be permitted 
as well.

My two cents,
Jordan