Gary Winiger wrote:
>>> issues in summary. An updated spec will follow the convergence of the case.
>> This case was approved at today's PSARC meeting. An updated
>> spec will be delivered to the case tomorrow when I get the
>> wording straight for making mlslabel undelegatable.
>
> Below and in the case (spec.txt) please find the updated spec.
> Tim and zfs team, if the wording around delegation is inaccurate,
> please let me and the project team know and suggest some proper
> wording so it is clear to all. spec.old and zfs.1m.old are the
> previous verions (also under SCCS).
>
It looks fine.
-tim
> Thanks,
> Gary..
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I'm sponsoring this Fast Track for Ric Aleshire and the Trusted Extensions
> development team.
>
> Trusted Extensions was introduced in PSARC/2002/762 Layered Trusted
> Solaris with filesystem interfaces defined in the subcase
> PSARC/2005/723 Solaris Trusted Extensions Filesystem Labeling
>
> One of the goals of Trusted Extensions was to make no modifications to
> the on disk filesystem structures. This was different than the releases
> of Trusted Solaris (1.0-2.5.1, 7, 8). In those systems on disk filesystem
> changes were made in order to support labels. That made those filesystems
> incompatible with the unlabeled forms. With the advent of
> PSARC/2002/240 ZFS (Zettabyte Filesystem) some amount of labeling can be
> introduced in a fully compatible way.
>
> This case requests a Committed Interface Taxonomy, and a Patch Release
> Binding with a dependency on PSARC/2002/240.
>
> A full diffmarked zfs(1m) man page is in the case directory.
>
> The timer is set for 17 June, 2009.
>
> Gary..
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Background:
> ==========
> The Trusted Extensions feature of Solaris provides sensitivity
> labels, and mediates data access accordingly. These labels are
> associated with zones; each zone on a system is configured to
> have a unique label. Labels are not stored with the filesystem
> but are inferred based on the containing zone. Mount-time
> policy controls access to filesystems and the objects they
> contain.
>
> Problem:
> =======
> Based on customer requests for Trusted Extensions and possible
> future Common Criteria Evaluation criteria, there are
> requirements to be able to store labels with corresponding
> data. In Trusted Extensions, a ZFS dataset currently has only
> an implied label, based on where it is mounted (i.e., in which
> zone). To prevent administrators or users from accidentally
> mounting datasets in ways that would mislabel information, that
> information should be recorded as a persistent ZFS attribute.
> Labeled ZFS filesystems will also improve the security of
> removable devices (such as USB media) in Trusted environments.
>
> Proposal:
> ========
> ZFS filesystem mechanisms make it possible to support labels as
> attributes of the data. To protect these labels from user
> manipulation, they will be system attributes as defined by ZFS,
> and will be supported by kernel policy to maintain the label
> and control access to the corresponding data.
>
> ZFS kernel mount logic will access the label attribute and
> perform a check for label dominance, similar to the policy
> found in lofs and nfs mount code. Labeling of previously
> unlabeled ZFS file systems will generally be automatic and
> not require administrative action.
>
> Details:
> =======
> A new system property called "mlslabel" is defined. Its value
> on disk is a string which represents the internally encoded label
> of the dataset. (E.g., "0x0002-08-08", which corresponds to the
> "public" label.) mlslabel is an inheritable property; when not
> present, it defaults to the string "none" to indicate no label
> is present. The mlslabel property follows the same rules as the
> other inheritable properties.
>
> When Trusted Extensions is enabled, mount-time checks will
> verify that the dataset label matches the label of the zone
> that the dataset is mounted into. If the labels do not match,
> the mount syscall fails with an EACCES error.
>
> The mlslabel property may be set from the command line using the
> zfs command, for example:
> zfs set mlslabel=public export/something
>
> Setting the mlslabel property can only be done when Trusted
> Extensions is enabled. The file_upgrade_sl privilege is required
> when setting an initial label, or changing a non-default label
> to a higher level label. The file_downgrade_sl privilege is
> required when removing a label (setting it to "none") or when
> changing a non-default label to a lower level label.
>
> Unlike other properties, the mlslabel property is a Mandatory
> Policy attribute used to support label base Mandatory Access
> Control; therefore rights to modify it may not be delegated.
>
> In addition to manually setting dataset labels, the system will
> appropriately initialize the label attribute automatically. At
> mount time, if the dataset has no mlslabel property or only the
> default one ("none"), the mlslabel property will be set during
> the mount.
>
> Changing the label on a dataset (i.e. setting the mlslabel
> property, when a non-default mlslabel value already exists), is
> only allowed when the dataset is not mounted. Setting an
> initial mlslabel is permitted regardless of whether the dataset
> is mounted or not.
>
> In a labeled zone the only value which can be set for the
> mlslabel property of a dataset is the one matching the zone's
> label. (Which is set automatically at first mount time.)
>
> When mounting into the global zone proper (the zoned property is
> "off"), the mount will fail if the mlslabel property value is
> other than "none" or "admin_low/admin_high". Additionally
> admin_low mounts must be read only. No automatic property
> setting is done for global zone mounts.
>
> The intent of this case is to prevent inadvertent access to labeled
> data. The default mlslabel 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. This allows the
> Trusted Extensions administrator to ensure that such labeled
> datasets will not be unintentionally mounted in ways that could
> cause inadvertent data access or modification.
>
> When Trusted Extensions is NOT enabled, only datasets with
> an mlslabel value of "none" can be mounted.
>
> The kernel does not presently have interfaces to translate
> internally encoded string labels to binary label (m_label)
> structures for manipulation or from binary labels to internally
> encoded string labels. This case will add project private
> interfaces to do so. The actual code will be shared with the
> existing user land code in str_to_label(3tsol) and
> label_to_str(3tsol).
>
> zfs(1M):
>
> The following native properties can be used to change the
> behavior of a ZFS dataset.
>
> [...]
>
> + mlslabel=<label | none>
> + This property is used with Trusted Extensions. It is the
> + sensitivity label at which the dataset must be mounted (it
> + must match the labeled-zone where the dataset is mounted)
> + or the mount will fail.
> +
> + When the mlslabel property is not set it defaults to the value
> + "none". Setting the mlslabel property to "none" is equivalent
> + to removing the property.
> +
> + Unlike other properties, the mlslabel property can only be
> + modified when Trusted Extensions is enabled and only with
> + appropriate privilege. Rights to modify it may not be delegated.
> + When changing a label to a higher label or setting the initial
> + dataset label, the {PRIV_FILE_UPGRADE_SL} privilege is required.
> + When changing a label to a lower label or the default ("none"),
> + the {PRIV_FILE_DOWNGRADE_SL} privilege is required. Changing
> + dataset from labels other than the default can only be done when
> + the dataset is not mounted. When a dataset with the default
> + label is mounted into a labeled-zone, the mount automatically
> + sets the mlslabel property to the label of that zone.
> +
> + When Trusted Extensions is NOT enabled, only datasets with
> + the default label ("none") can be mounted.
>
> [...]
