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.
[...]
