> From gww at eng.sun.com Tue Jun 9 18:02:31 2009
> Date: Tue, 09 Jun 2009 18:02:13 -0700 (PDT)
> From: Gary Winiger <gww at eng.sun.com>
> Subject: Redux: PSARC/2009/348 Security Labels for ZFS
> To: PSARC-ext at sun.com
> Cc: rampart-dev-team at sun.com, ric.aleshire at sun.com
> Content-transfer-encoding: 7BIT
> X-PMX-Version: 5.4.1.325704
>
> AARGGGG, Fat fingered the case number when cleaning up the To and Cc lists.
> Please reply to this mail.
>
> 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) and its property structure defined
> by PSARC/2007/315 Extensible Attribute Interfaces, 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 and PSARC/2007/315.
>
> 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 "slabel" is defined. Its value is a
> string which represents the internally encoded label of the
> dataset. (E.g., "0x0002-08-08", which corresponds to the
> "public" label.) slabel is an inheritable property; when not
> present, it defaults to the string "none" to indicate no label
> is present. The slabel 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 slabel property may be set from the command line using the
> zfs command, for example:
> zfs set slabel=0x0002-08-08 export/something
>
> Setting the slabel 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.
>
> In addition to manually setting dataset labels, the system will
> appropriately initialize the label attribute automatically. At
> mount time, if the dataset has no slabel property or only the
> default one ("none"), the slabel property will be set during
> the mount.
>
> Changing the label on a dataset (i.e. setting the slabel
> property, when a non-default slabel value already exists), is
> only allowed when the dataset is not mounted. Setting an
> initial slabel is permitted regardless of whether the dataset
> is mounted or not.
>
> In a labeled zone the only value which can be set for the
> slabel 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 mount will fail
> if the dataset has any label other than the default ("none") or
> admin_high/admin_low. No automatic property setting is
> performed for any mounts into the global zone.
>
> One mount-time label check is performed for ZFS datasets when
> Trusted Extensions is NOT enabled. If the dataset has a non-
> default label property, then without Trusted Extensions it can
> only be mounted if it is admin_high/admin_low. That is, it
> was mountable exclusively into the Trusted Extensions global
> zone and contains no Trusted Extensions labeled user data.
>
> 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.
>
> [...]
>
> + slabel=<internally encoded label | none>
> + This property is used with Trusted Extensions. This is
> + the internal encoding of a sensitivity label (also called
> + a hex label). (See label_to_str(3tsol), label_encodings(4),
> + hextoalabel(1M), atohexlabel(1M).) At mount time, this label
> + must match that of the zone where the dataset is being mounted,
> + or the mount fails.
> +
> + When the slabel property is not set it defaults to the value
> + "none". Setting the slabel property to "none" is equivalent
> + to removing it.
> +
> + Setting the slabel property can only be done when Trusted
> + Extensions is enabled, and requires privilege. The
> + {PRIV_FILE_UPGRADE_SL} privilege is required when changing a
> + non-default label to a higher level label or when initially
> + setting the dataset label (i.e. when the existing label is a
> + default "none"). The {PRIV_FILE_DOWNGRADE_SL} privilege is
> + required when removing a label or changing to a default
> + label, or when changing a non-default label to a lower
> + level label.
> +
> + Changing the label on a dataset (i.e. setting the slabel
> + property, when a non-default slabel value already exists),
> + is only allowed when the dataset is not mounted. Setting
> + an initial slabel is permitted regardless of whether the
> + dataset is mounted or not.
> +
> + In a labeled zone the only value which can be set for
> + the slabel property of a dataset is the one matching the
> + zone's label. This is done automatically during the first
> + successful mount of a previously unlabeled dataset into
> + labeled zones. For global zone datasets, only the default
> + ("none") or admin_low and admin_high labels may be used.
> +
> + When Trusted Extensions is NOT enabled, datasets with
> + labels other than the default ("none") or admin_low/admin_high
> + cannot be mounted.
>
> [...]
>
>
> ----- End Included Message -----
>
>
