> OK then ;-) I'll be posting a summary of the issues discussed
> and responses shortly so we're all on the same page.
During this case discussion a few points were raised. In order to work
towards convergence of the case the project team would like to respond to those
issues in summary. An updated spec will follow the convergence of the case.
Gary..
======
* PSARC/2007/315 Extensible Attribute Interfaces was referenced as a
dependency. The ZFS project team pointed out this was not a relevant
reference and that PSARC/2002/240 ZFS (Zettabyte Filesystem) was the
only case dependency required.
References to PSARC/2007/315 have been removed.
* What is the inheritance characteristic of the slabel property?
The slabel property is inherited just the same as the other
data set properties. Modifying the slabel's value requires
the specified privilege.
* How does zfs send deal with the slabel property?
send (and receive) preserve the slabel property. Making the
received data set available (mount) is restricted as specified
in the case materials mount policy.
* How is the slabel property related to delegation (zfs allow)?
Delegation deals with owner rights (Discretionary Policy as in
Discretionary Access Control, DAC), slabel is a Mandatory Policy
attribute. It deals with label based Mandatory Access Control,
MAC, thus unlike other zfs properties, additional policy applies
to the slabel property. In addition to having DAC rights to
modify the slabel property, the specified policy (privileges,
or setting to the label of the zone in which it is mounted
Read/Write) is required.
* Why have all three none/admin_low/admin_high; what is the relationship
between them?
The intent of this case is to prevent inadvertent access to labeled
data. The default slabel value (including when not present), none,
implies the data has not been labeled, thus default access is
allowed. admin_low and admin_high are "administrative" labels
associated with system, rather than user, data. They are only
set explicitly by Trusted Extensions administrators to indicate
how they wish system data to be protected. As opposed to other
labels in a Trusted Extensions configuration, they are not
automatically set when mounted. Trusted Extensions administrators
have to explicitly specify how they want system data protected.
When mounted in the global zone, admin_low data sets must not have
the existing zoned property set and must be mounted read only.
labeled-(non-global)-zone admin_low data sets must be mounted read
only. admin_high labeled data sets, must not have the zoned property
set and may only be mounted in the global zone. This allows the
Trusted Extensions administrator to ensure that such labeled data
sets will not be unintentionally mounted in ways that could cause
inadvertent data access or modification.
* Why must zfs set slabel= and zfs get slabel only deal with internally
formatted labels?
There is no reason. The case will be updated to allow human
readable as well as internally formatted labels. Internally
formatted labels will be stored as the string value of the
slabel property. The zfs command will do the translation
using the standard Trusted Extensions interfaces which take
into account the calling user's rights to view/set human
readable label strings.
* What is the interaction between the zfs crypto project and this case?
The on disk format of the slabel string is public information
(unclassified) and requires no protection.
