PSARC/2002/762 - Layered Trusted Solaris -- inception 12/17/2003

jdc-0	20q5: what is meant by conditional compilation here?  Are we
	maintaining separate versions of the same binary (in contrast
	to 1991/061)?  If so, why?  This sounds like a patch delivery
	nightmare.

Although the vast majority of the conditional logic will be implemented
via runtime checks, there are a few programs that are either so extensively
modified or have decreased performance that conditional compilation is more
appropriate. Such programs will be delivered in unbundled packages, and will
have unique names.  For example, the TSOL version of dtwm will have a name
like tsoldtwm or be delivered into /usr/dt/tsol/bin.  Such programs will
require their own patches, but we anticipate only a few such applications.

jdc-1	Any new protocols (X Window System extensions) to be sent
	through external bodies?

Probably not. This path has been tried with the Trusted Systems
Interoperability Group (TSIG).  It never came to closure.  There was some
general consensus on the functions needed, but none on the OTW format.
For backward compatibiliity reasons we don't want to make any changes to these
protocols.  They are probably something like Sun or Committed Private as they
currently pass binary labels in a format that is Sun-specific and they depend
on features not available in any other OS.  There is nothing to perclude
future extensions that are controlled by external bodies.

jdc-2	Do any policies or features of either Solaris Zones (2002/174)
	or Solaris Least Privilege (2002/188) need to change?  If so,
	which ones and how?

No kernel functional changes in privileges. In userland, we will define
additional privileges for X protocol requests, and add privilege support
to CDE actions.  This may require expanding the number of privileges
available.

For Zones, we will be modifying some of the policy dealing with 
cross-zone communication. This will be done via runtime tests based on
whether a TSOL policy module is loaded.We will also be adding a label 
attribute to the zones struct which will be used for mounting and 
networking policies.

jdc-3	Are there any third party applications that depend on the
	existing TS8 behaviors?

Yes, we are aware of a product from General Dynamics called Trusted 
Network Environment. We have presented our roadmap to them (twice).

jdc-4	If I have both TS8 and TS10 systems, how do I keep the
	configurations synchronized?

Since these systems cannot share the same name service, manual
procedures will be required.

jdc-5	How do labels, removable file systems, and backups interact?
	If files aren't labeled, how are accidents prevented in this
	area?

If full pathnames are used, and backups are done from the global zone,
the relationship between zone, label, and pathname is preserved. We are 
still researching this issue.

jdc-6	Why are multilevel ports configured by interface?  Why not as
	a per-process (or zone) privilege?

Because we don't want trust labeled zones to set their own labeling 
policy. However, a privilege will be required to bind to a multilevel port.

jdc-7	1.3.13: says NIS and DNS not supported.  Why?

Should say NIS and DNS will not be enhanced for TSOL.

jdc-8	How are automounter-in-zone bits actually removed?  There's
	only one file delivered.

Runtime checks will be made in the autofs code to check whether the TSOL 
kernel module is loaded.

gw-1	The project team is aware that some things will require a UIRB review,
	that the security questionaire will need to be filled out.

gw-2	The number of spare privileges is becoming small.  Is it appropriate
	to add more privilege space in a micro/patch/update release?

kb-1	How is the migration of the following pieces in TSOL 8 handeled?
	. Archives produced with tar/ufsdump ... that preserved:
	  . privilege setting on binaries
	  . MLDs on directories
	  . labels on files and directories?

	. Clearances of users? 

	. explicit security policy-related settings (e.g device_policy entries,
	  tnidb label ranges, audit_events)

kb-2	the PKCS#11 (libpkcs11+pkcs11_kernel.so+/dev/crypto) brought a new
	interface for producing information (keys, certificates, raw data ...)
	on one device (a pkcs#11 token in Kernel), that can be available to
	other consumers on other zones. How is this project closing this
	conduit for Trusted Solaris? (device allocation? zoneid enforcement
	in /dev/crypto's code ?)

kb-3    Section 2.1.3 Network access refers to XXX. where is XXX?

wes-1 	NIT: overview.pdf color coding on pages 6-7 and later in the
	presentation is not clear.  a key or subheadings would help 
	(assuming you use white background for TS8 feature sets, 
	yellow for base S10)

wes-2   would like to hear more on the rationale for the CDE first,
	Gnome later decision.

wes-3	The role and "label" of the global zone is unclear here;
	it seems that it contains a bunch of things:
		- the TCB 
		- a bunch of "admin low" files which are shared read-only by 
		  the labelled zones
		- system-level logs, which would presumably be "admin high" or
		"system high" 
	Is there anything to prevent the administrator from shooting 
	themselves in the foot by accidentally loopback-mounting something 
	that they shouldn't from the global zone into the individual zones?
	(per-file or per-directory labels would provide a
	belt&suspenders protection here).  Could you get help here from ZFS?
	(multiple lightweight filesystems labelled differently in a pool?)

wes-4	overview.pdf slide 9: "no user processes, just TCB".
	will the system administrator be able to have an interactive shell
	in the global zone?  If not, what additional admin tools will
	be needed?

wes-5	Per-zone ip address (i.e., potentially lots of ip addresses in use)
	but ipv6 is deferred?

wes-6	would like to see much more detail on how CIPSO and IPsec and
	per-zone addresses interact and are managed in a network
	of TSol10 systems..

wes-7	given the radically different model, would like to see much more 
	detail on the migration path..

wes-8	NIT: some inconsistancy in arrow direction for cross-zone mount
	diagrams between documents (looks like spec.pdf page 33 points
	towards client side; overview slide 11 points towards server side)

	Whiteboard Issues

gcs-1	paragraph 5.2.2 -> 5 of automount conflict with zones semantics

tcm-1	Must Global Zone Admin be cleared for everything

tcm-1	Covert Channels