Gary Winiger wrote: > 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.
I'm happy with everything in this case except that the user interface to setting the property requires the use of an internally encoded label, I'm happy with allowing it. This seems really unfortunate that we can't just do: zfs set slabel=public tank/foo and instead have to do zfs set slabel=`atohexlabel public` tank/foo Storing the internal encoding in the property seems like the correct thing to do to. However requiring that the admin do that conversion provides an uglier UI that is necessary. I believe this can be implemented by a special case (similar to what is already done for the quota properties) in zprop_parse_value() for the 'set' case and a property specific case in zfs_prop_get(). If implementation assistance is needed by the project team I'd be happy to help - I'd also like to help code review anyway. -- Darren J Moffat