Gary Winiger wrote:
>> 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.
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
Two comments/requests from the ZFS team.
1) Please choose a more descriptive name for the property than 'slabel'.
Perhaps "securitylabel" or "seclabel" or something else?
2) Please make the property either not delegate-able or fully delegate-able.
By fully delegate-able we mean, no other privilege required if you've
been delegated permission to manipulate the property.
-tim
