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