This case updates the TX label translation service, svc:/system/labeld,
defined in Layered Trusted Solaris Label Interfaces (PSARC/2005/259) to
enable and disable Solaris Trusted Extensions.

The previous Unstable interface taxonomy is modified to Uncommitted and
a Patch release binding are requested.

Gary..
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Background
==========
Trusted Extensions (TX) today is an unbundled product delivered via
add-on packages in the ExtraValue directory.  The source code is in
several WOS consolidation: CDE, X, JDS, Admin.  There is an additional
Trusted Layered Component (TLC) consolidation and significant code is
the ON consolidation.  Virtually all of this code uses run-time checks
so that it is only effective when TX is enabled. 

Currently, installation of TX packages also serves to enable TX.  In
particular, TX kernel module lbl_edition maintains a variable that is
queried to determined whether TX is enabled (this is needed early in
boot code).  If this module is installed and loaded then TX is
effectively enabled.  This was described in is_system_labeled
(PSARC/2006/191):

	Early in boot, the kernel startup() function attempts to load a
	"sys"-type module named "lbl_edition"; load failures are silently
	ignored as the module is not expected to be present on an unlabeled
	system.
	
	Shortly thereafter, a single check is made via modgetsymvalue() for
	the value of the global integer variable "label_services"; if this
	variable is present and nonzero, the system is assumed to be labeled;
	if it is either not present (for instance, if the "lbl_edition" module
	fails to load or fails to define the variable), or zero, the system is
	assumed to be unlabeled.  At that point, the sys_labeling global
	integer variable, previously initialized to a negative value
	(indicating an indeterminate state), is set to 0 on an unlabeled
	system and to a value greater than zero on a labeled system.
	
	The lbl_edition module may not be unloaded, and exports no interfaces
	other than the "label_services" global variable.
	
	The lbl_edition module is packaged with other layered Trusted Extensions
	deliverable files.  

	...	

	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	|kernel/sys/lbl_edition,        | (Contracted)    | Layered module name|
	|kernel/sys/amd64/lbl_edition,  | Project Private |                    |
	|kernel/sys/sparcv9/lbl_edition |                 |                    |
	|label_services			|                 | global variable    |
	~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	
	

Problem
=======

It is planned to get rid of the ExtraValue directory and deliver all
the TX packages in the WOS to be installed with Solaris.  As part of work,
source from the TLC consolidation will be moved into the ON gate and
corresponding packages will be delivered with Solaris.  As a result, a
new mechanism to enable and disable TX must be created, so that
packages may be installed without forcing the system to be labeled.


Proposal
=======

1) The svc:/system/labeld service is only shipped in the global zone,
   is shipped disabled and not enabled by any SMF profile (it was enabled
   as part of the TX post installation process).
   Enabling this service will result in the Trusted Extensions feature
   being enabled.  To accomplish this, if TX is not already enabled,
   the start method for this service will set the following kernel
   variable in /etc/system:
	set sys_labeling=1
   In addition, it will enable auditing, enable other previously defined
   TX services (such as svc:/network/tnd and svc:/system/tsol-zones)
   and perform the other tasks that had been part of the TX packages post
   installation process.

   Disabling svc:/system/labeld results in the disabling of Trusted
   Extensions, and the above variable setting will be removed from
   /etc/system.

2) The Project Private lbl_edition kernel module, its contents and usage
   as described in PSARC 2006/191 will no longer exist; it will be removed
   if found during upgrade.

3) N.B.  Not changed by this proposal is the requirement to reboot to
   enable TX (thus the rationale to use /etc/system to just set the
   sys_labeling state).  The reboot enforces security policies documented
   for Trusted Extensions.  Due to the handling required for unlabeled
   and labeled data, zones must be deleted before enabling or disabling
   TX and a reboot is then used to populate kernel data structures with
   label-related data that must be present from very early in the boot
   sequence.

   The svc:/system/labeld service will enforce these zones restrictions;
   if zones exist during an attempt to enable or disable, appropriate
   error messages are logged and the service will enter maintenance state,
   and no other changes will be made.

References
==========

PSARC 2006/191 - is_system_labeled
PSARC 2002/762 - Layered Trusted Solaris
PSARC/2005/259 - Layered Trusted Solaris Label Interfaces