Glenn,

Glenn Faden wrote:
> Jerry,
> 
> For Trusted Extensions in OpenSolaris, we plan to use a new "labeled" 
> brand for zones which will be derived from the new ipkg brand. So your 
> proposal also affects "labeled" branded zones.  I would like to explore
> the plan to delegate these datasets to the zone. 

OK.  This document is currently what we have.  Let me know if you
have questions about it.  We'll be working on implementing toward
this over the next few months.  Also, it is worth noting that the
"ipkg" brand is pretty fluid at this point and I would expect to
continue to see a fair number of changes for a while.

> Since the zone's root 
> dataset must be mounted in the global zone before the zone can be 
> booted, this is distinct from the normal dataset delegation, in which 
> the mount is done from within the zone. For TX there are some issues 
> with ensuring that these datasets are properly protected and labeled. 
> There may also be issues with encryption keys.
> 
> For TX we would like a way to associate a label with a dataset even if 
> it isn't mounted. Today we derive the label from the ZFS mount attribute 
> which corresponds to the zonepath defined in zonecfg. Given a zone name, 
> we can find the label in /etc/security/tsol/tnzonecfg. However, with 
> multiple datasets being delegated to zones, and the use of the legacy 
> mount setting, the link between the dataset and it's label becomes a bit 
> weaker. For greater assurance, I would like to store the label as a 
> dataset property, but this implies it must not be delegated to the zone 
> since labels are only managed from the global zone.

Currently, with user defined properties, the values can be changed
inside the zone.  The proposal actually depends on this feature.
It sounds like you might need to talk to the zfs team about some
enhancements here so we can have properties that cannot be changed
on delegated datasets.  That might be generally useful beyond tx, so
that would be a good conversation to have.

> I'm not clear about the security policy of properties, such as 
> org.opensolaris.libbe:parentbe. Is the ability to modify these 
> properties granted when the dataset is delegated? Can there by 
> properties that don't get delegated?
> 
> There is tangential issue with respect to NFS sharing of directories 
> within delegated zone datasets. Currently there is a TX extension to 
> zoneadmd which allows per-zone shares to be interpreted when zones are 
> booted or halted. Since this code must execute in the global zone, the 
> dataset must be previously mounted in the global zone. Delegated 
> datasets that aren't mounted from the global zone can't be shared today. 
> This issue isn't completely relevant to your proposal, but I wanted to 
> mention it for clarity.

Most of this is just on paper now, so we can make enhancements as
it is implemented, as long as the basic design is sound.

Thanks,
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to