|
Replies:
29
-
Last Post:
Jun 18, 2009 8:03 PM
by: timh
|
|
|
Gary Winiger
gww@eng.sun.com
|
|
|
|
Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 9, 2009 6:02 PM
|
|
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 -----
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
Posts:
113
From:
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 7:45 AM
in response to: Gary Winiger
|
|
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.
> +
> + 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.
>
> [...]
>
>
PSARC 2007/315 defines extensible system attributes, which are a file-level
mechanism. What you are describing is a new dataset-level property. So I
don't see a need to tie this new case with 2007/315.
By default a child dataset inherits property values from its parent. There are
exceptions to this, and if this is one of those, that should be noted. Also,
will you allow a label to be inherited from a parent dataset via 'zfs inherit'?
Does this property need to remain with the dataset if the dataset is streamed
somewhere via 'zfs send'? That will affect the implementation.
Will you allow label setting to be delegated (i.e, 'zfs allow')? All other
properties support this.
-tim
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
16
From:
US
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 10:52 AM
in response to: timh
|
|
Tim Haley wrote:
> 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.
>> +
>> + 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.
>>
>> [...]
>>
>>
> PSARC 2007/315 defines extensible system attributes, which are a
> file-level mechanism. What you are describing is a new dataset-level
> property. So I don't see a need to tie this new case with 2007/315.
I'll see if there's another case that's relevant in place of this one,
unless it turns out that 2002/240 is sufficient.
> By default a child dataset inherits property values from its parent.
> There are exceptions to this, and if this is one of those, that should
> be noted. Also,
> will you allow a label to be inherited from a parent dataset via 'zfs
> inherit'?
This will inherit normally, including by the "zfs inherit" command.
> Does this property need to remain with the dataset if the dataset is
> streamed somewhere via 'zfs send'? That will affect the implementation.
Yes, the intention is that the slabel property will be maintained in the
send/recieve process.
> Will you allow label setting to be delegated (i.e, 'zfs allow')? All
> other properties support this.
I don't have a final answer for this now. My initial reaction is "no
delegation", but I want to verify if there are indeed
special security considerations based on the MAC (mandatory access)
nature of this property. This differs from
DAC properties which are discretionary and can be modified by general
users. I'll get back on this one.
> -tim
>
>
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 11:49 AM
in response to: rica
|
|
On Wed, Jun 10, 2009 at 10:52:16AM -0700, Ric Aleshire wrote:
> Tim Haley wrote:
> >By default a child dataset inherits property values from its parent.
> >There are exceptions to this, and if this is one of those, that should
> >be noted. Also,
> >will you allow a label to be inherited from a parent dataset via 'zfs
> >inherit'?
>
> This will inherit normally, including by the "zfs inherit" command.
The thing is that "zfs inherit ..." is, effectively, unsetting the
property so it can be inherited. If the to-be-inherited value is
different from the current, then the same controls must apply as would
to changing the property value in the first place. That might be
implied by zfs inherit's definition ("[c]lears the specified property,
causing it to be inherited from an ancestor"). I think Tim was just
asking to make this explicit.
Nico
--
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
113
From:
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 12:17 PM
in response to: nico
|
|
Nicolas Williams wrote:
> On Wed, Jun 10, 2009 at 10:52:16AM -0700, Ric Aleshire wrote:
>> Tim Haley wrote:
>>> By default a child dataset inherits property values from its parent.
>>> There are exceptions to this, and if this is one of those, that should
>>> be noted. Also,
>>> will you allow a label to be inherited from a parent dataset via 'zfs
>>> inherit'?
>> This will inherit normally, including by the "zfs inherit" command.
>
> The thing is that "zfs inherit ..." is, effectively, unsetting the
> property so it can be inherited. If the to-be-inherited value is
> different from the current, then the same controls must apply as would
> to changing the property value in the first place. That might be
> implied by zfs inherit's definition ("[c]lears the specified property,
> causing it to be inherited from an ancestor"). I think Tim was just
> asking to make this explicit.
>
> Nico
I figured they wouldn't want the label to be an automatically inherited
property, but wasn't sure. But apparently I was wrong. :-) If it wasn't I
just wanted them to make this clear in their man page changes as we do for
other properties which are not inherited.
-tim
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
299
From:
US
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 8:02 AM
in response to: Gary Winiger
|
|
>
> 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.
It sounds like there are 3 different values for this property that have
exactly the same effect. Is there any difference in semantics among these?
- slabel=none (or attribute not present)
- slabel=admin_low
- slabel=admin_high
If there is no difference, I suggest that there is no reason to store
the latter two. The zfs set command could accept those values and
convert them to none, if desired.
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
16
From:
US
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 11:01 AM
in response to: rotondo
|
|
Scott Rotondo wrote:
>
>>
>> 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.
>
> It sounds like there are 3 different values for this property that
> have exactly the same effect. Is there any difference in semantics
> among these?
>
> - slabel=none (or attribute not present)
> - slabel=admin_low
> - slabel=admin_high
>
> If there is no difference, I suggest that there is no reason to store
> the latter two. The zfs set command could accept those values and
> convert them to none, if desired.
>
> Scott
The latter two will prevent the dataset from being mounted in any
labeled zone.
Currently there would be no behavioral distinction between admin_low and
admin_high
zfs labels. However, after zfs labels are established by this case, the
implementation
of the getlabel interfaces, introduced by 2005/723, will be modified to
take advantage
of the zfs property. I anticipate that will result in the ability to
loopback-mount
admin_low datasets into labeled zones, which would be appropriate.
-Ric
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
320
From:
US
Registered:
4/14/06
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 11:29 AM
in response to: rica
|
|
Ric Aleshire wrote:
> Scott Rotondo wrote:
>>
>>>
>>> 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.
>>
>> It sounds like there are 3 different values for this property that
>> have exactly the same effect. Is there any difference in semantics
>> among these?
>>
>> - slabel=none (or attribute not present)
>> - slabel=admin_low
>> - slabel=admin_high
>>
>> If there is no difference, I suggest that there is no reason to store
>> the latter two. The zfs set command could accept those values and
>> convert them to none, if desired.
>>
>> Scott
>
> The latter two will prevent the dataset from being mounted in any
> labeled zone.
>
> Currently there would be no behavioral distinction between admin_low
> and admin_high
> zfs labels. However, after zfs labels are established by this case,
> the implementation
> of the getlabel interfaces, introduced by 2005/723, will be modified
> to take advantage
> of the zfs property. I anticipate that will result in the ability to
> loopback-mount
> admin_low datasets into labeled zones, which would be appropriate.
The admin_low label implies that the dataset is read-only to all zones,
including the global zone. I think it would be cleaner to use the
existing "readonly=on | off" property instead of having two properties
that both imply read-only semantics. The getlabel interface should
interpret a read-only zfs mount in the global zone to be admin_low,
regarless of the current zone status. However, we still need a value
other than "none" to prevent mounting global zone datasets into a
non-global zones. So the admin_high value seems to meet that requirement.
--Glenn
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
299
From:
US
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 1:58 PM
in response to: gfaden
|
|
Glenn Faden wrote:
> Ric Aleshire wrote:
>> Scott Rotondo wrote:
>>>
>>>>
>>>> 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.
>>>
>>> It sounds like there are 3 different values for this property that
>>> have exactly the same effect. Is there any difference in semantics
>>> among these?
>>>
>>> - slabel=none (or attribute not present)
>>> - slabel=admin_low
>>> - slabel=admin_high
>>>
>>> If there is no difference, I suggest that there is no reason to store
>>> the latter two. The zfs set command could accept those values and
>>> convert them to none, if desired.
>>>
>>> Scott
>>
>> The latter two will prevent the dataset from being mounted in any
>> labeled zone.
>>
>> Currently there would be no behavioral distinction between admin_low
>> and admin_high
>> zfs labels. However, after zfs labels are established by this case,
>> the implementation
>> of the getlabel interfaces, introduced by 2005/723, will be modified
>> to take advantage
>> of the zfs property. I anticipate that will result in the ability to
>> loopback-mount
>> admin_low datasets into labeled zones, which would be appropriate.
>
> The admin_low label implies that the dataset is read-only to all zones,
> including the global zone. I think it would be cleaner to use the
> existing "readonly=on | off" property instead of having two properties
> that both imply read-only semantics. The getlabel interface should
> interpret a read-only zfs mount in the global zone to be admin_low,
> regarless of the current zone status. However, we still need a value
> other than "none" to prevent mounting global zone datasets into a
> non-global zones. So the admin_high value seems to meet that requirement.
>
I was about to agree with you, that there should be a single "admin"
value whose interpretation depends on the readonly property. That avoids
having two different properties that imply a read-only mount.
But to argue the other side for a moment, any other label remains
unchanged regardless of the readonly attribute. That means you can have
a read-only filesystem of any label *except* admin_high. Should a
filesystem full of admin_high data become admin_low if you set the
readonly property?
If the answer to the above question is yes, then presumably setting or
clearing the readonly property will require priv_downgrade_sl or
priv_upgrade_sl, respectively.
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
320
From:
US
Registered:
4/14/06
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 2:43 PM
in response to: rotondo
|
|
Scott Rotondo wrote:
> Glenn Faden wrote:
>> Ric Aleshire wrote:
>>> Scott Rotondo wrote:
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> It sounds like there are 3 different values for this property that
>>>> have exactly the same effect. Is there any difference in semantics
>>>> among these?
>>>>
>>>> - slabel=none (or attribute not present)
>>>> - slabel=admin_low
>>>> - slabel=admin_high
>>>>
>>>> If there is no difference, I suggest that there is no reason to
>>>> store the latter two. The zfs set command could accept those values
>>>> and convert them to none, if desired.
>>>>
>>>> Scott
>>>
>>> The latter two will prevent the dataset from being mounted in any
>>> labeled zone.
>>>
>>> Currently there would be no behavioral distinction between admin_low
>>> and admin_high
>>> zfs labels. However, after zfs labels are established by this case,
>>> the implementation
>>> of the getlabel interfaces, introduced by 2005/723, will be modified
>>> to take advantage
>>> of the zfs property. I anticipate that will result in the ability
>>> to loopback-mount
>>> admin_low datasets into labeled zones, which would be appropriate.
>>
>> The admin_low label implies that the dataset is read-only to all
>> zones, including the global zone. I think it would be cleaner to use
>> the existing "readonly=on | off" property instead of having two
>> properties that both imply read-only semantics. The getlabel
>> interface should interpret a read-only zfs mount in the global zone
>> to be admin_low, regarless of the current zone status. However, we
>> still need a value other than "none" to prevent mounting global zone
>> datasets into a non-global zones. So the admin_high value seems to
>> meet that requirement.
>>
>
> I was about to agree with you, that there should be a single "admin"
> value whose interpretation depends on the readonly property. That
> avoids having two different properties that imply a read-only mount.
>
> But to argue the other side for a moment, any other label remains
> unchanged regardless of the readonly attribute. That means you can
> have a read-only filesystem of any label *except* admin_high. Should a
> filesystem full of admin_high data become admin_low if you set the
> readonly property?
>
> If the answer to the above question is yes, then presumably setting or
> clearing the readonly property will require priv_downgrade_sl or
> priv_upgrade_sl, respectively.
>
>
The distinction between admin_low and admin_high in TX is about what
global zone data is shared with all zones, and what is private to the
global zone. Originally, this included all the sparse-root zone
directories (/usr, /lib, /opt, ...) and anything special like
/var/tsol/doors. /etc/passwd and /etc/shadow. Now that sparse root
zones are unsupported in OpenSolaris, there are only a few files and
directories that are treated as admin_low, not entire datasets. So there
is limited value in labeling a dataset with the admin_low label.
The rationale of this PSARC case is to make labeling more robust by
preventing the administrator from incorrectly mounting ZFS datasets, and
to facilitate determining the label without mounting the dataset. A
mount time, label are validated against the mount point since these two
properties can be set independently. The utility of distinguishing
between admin_low and admin_high labels would be to validate that these
label properties are consistent with the readonly property.
--Glenn
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@eng.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 10:31 AM
in response to: Gary Winiger
|
|
Tim,
Thanks for adding zfs-team.
> PSARC 2007/315 defines extensible system attributes, which are a file-level
> mechanism. What you are describing is a new dataset-level property. So I
> don't see a need to tie this new case with 2007/315.
I didn't recall system attributes being part of the original
ZFS case. Do you have a case pointer for dataset-level system
properties? Or are you saying that there are no dataset level
system properties? I'm pretty sure the project team believes
there are.
> By default a child dataset inherits property values from its parent. There are
> exceptions to this, and if this is one of those, that should be noted. Also,
> will you allow a label to be inherited from a parent dataset via 'zfs inherit'?
>
> Does this property need to remain with the dataset if the dataset is streamed
> somewhere via 'zfs send'? That will affect the implementation.
>
> Will you allow label setting to be delegated (i.e, 'zfs allow')? All other
> properties support this.
I'll let the project reply to this part.
I'd appreciate a proper case reference for dataset system properties.
Thanks,
Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
113
From:
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 10, 2009 11:02 AM
in response to: Gary Winiger
|
|
Gary Winiger wrote:
> Tim,
>
> Thanks for adding zfs-team.
>
>> PSARC 2007/315 defines extensible system attributes, which are a file-level
>> mechanism. What you are describing is a new dataset-level property. So I
>> don't see a need to tie this new case with 2007/315.
>
> I didn't recall system attributes being part of the original
> ZFS case. Do you have a case pointer for dataset-level system
> properties? Or are you saying that there are no dataset level
> system properties? I'm pretty sure the project team believes
> there are.
>
Dataset-level properties have been in place since initial integration of ZFS,
so I would say 2002/240 is sufficient.
-tim
>> By default a child dataset inherits property values from its parent. There are
>> exceptions to this, and if this is one of those, that should be noted. Also,
>> will you allow a label to be inherited from a parent dataset via 'zfs inherit'?
>>
>> Does this property need to remain with the dataset if the dataset is streamed
>> somewhere via 'zfs send'? That will affect the implementation.
>>
>> Will you allow label setting to be delegated (i.e, 'zfs allow')? All other
>> properties support this.
>
> I'll let the project reply to this part.
> I'd appreciate a proper case reference for dataset system properties.
>
> Thanks,
> Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 4:55 AM
in response to: Gary Winiger
|
|
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
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 5:23 AM
in response to: darrenm
|
|
Darren J Moffat wrote:
>> + 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,
Scratch that comment, on further thought (prompted by MarkS) I'm
actually not happy with using a dataset property for this.
ZFS Crypto support doesn't encrypt the property names or values, this
means that the sensitivity labels will not be encrypted on disk. That
could be a serious issue for use cases that involve ZFS doing encryption
and having TX enabled.
I think this case needs some discussion with the ZFS core team and the
ZFS crypto team before it can move forwards.
--
Darren J Moffat
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
320
From:
US
Registered:
4/14/06
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 7:40 AM
in response to: darrenm
|
|
Darren J Moffat wrote:
> Darren J Moffat wrote:
>>> + 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,
>
> Scratch that comment, on further thought (prompted by MarkS) I'm
> actually not happy with using a dataset property for this.
>
> ZFS Crypto support doesn't encrypt the property names or values, this
> means that the sensitivity labels will not be encrypted on disk.
> That could be a serious issue for use cases that involve ZFS doing
> encryption and having TX enabled.
>
> I think this case needs some discussion with the ZFS core team and the
> ZFS crypto team before it can move forwards.
You think the internal (hex) labels need to be encrypted? What is the
alternative to using a system property?
--Glenn
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 10:18 AM
in response to: gfaden
|
|
On Tue, Jun 16, 2009 at 07:40:10AM -0700, Glenn Faden wrote:
> Darren J Moffat wrote:
> >Scratch that comment, on further thought (prompted by MarkS) I'm
> >actually not happy with using a dataset property for this.
> >
> >ZFS Crypto support doesn't encrypt the property names or values, this
> >means that the sensitivity labels will not be encrypted on disk.
> >That could be a serious issue for use cases that involve ZFS doing
> >encryption and having TX enabled.
> >
> >I think this case needs some discussion with the ZFS core team and the
> >ZFS crypto team before it can move forwards.
> You think the internal (hex) labels need to be encrypted? What is the
> alternative to using a system property?
Well, they are static, no? Therefore at the very least there's a
traffic analysis issue. But given that we don't encrypt anything in ZFS
now I would think it'd be fine for the ZFS crypto project to leave
dataset properties unencrypted and _later_ come back and address that
problem, leaving this case and ZFS crypto orthogonal to each other.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 11:59 AM
in response to: nico
|
|
Nicolas Williams wrote:
> On Tue, Jun 16, 2009 at 07:40:10AM -0700, Glenn Faden wrote:
>> Darren J Moffat wrote:
>>> Scratch that comment, on further thought (prompted by MarkS) I'm
>>> actually not happy with using a dataset property for this.
>>>
>>> ZFS Crypto support doesn't encrypt the property names or values, this
>>> means that the sensitivity labels will not be encrypted on disk.
>>> That could be a serious issue for use cases that involve ZFS doing
>>> encryption and having TX enabled.
>>>
>>> I think this case needs some discussion with the ZFS core team and the
>>> ZFS crypto team before it can move forwards.
>> You think the internal (hex) labels need to be encrypted? What is the
>> alternative to using a system property?
>
> Well, they are static, no?
Static to a given site. The issue is that the labels themselves are
classified information for some customers - usually only the compartment
bits - and as such it would be better if we could encrypt them so that
the handling of disks that contain labels could be reduced.
> Therefore at the very least there's a traffic analysis issue.
> But given that we don't encrypt anything in ZFS
> now I would think it'd be fine for the ZFS crypto project to leave
> dataset properties unencrypted and _later_ come back and address that
> problem, leaving this case and ZFS crypto orthogonal to each other.
Given that ZFS crypto explicitly has all properties (including user
properties) in the clear I was trying to ensure that this case didn't
build an architecture that mean't it wasn't possible to have the TX
label encrypted. If a dnode system attribute rather than a dataset
property was used then it would automatically be encrypted by ZFS
crypto. However it seems that the desire is to know the label before
not after mounting so a property needs to be used.
--
Darren J Moffat
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 12:06 PM
in response to: darrenm
|
|
On Tue, Jun 16, 2009 at 07:59:06PM +0100, Darren J Moffat wrote:
> >Well, they are static, no?
>
> Static to a given site. The issue is that the labels themselves are
> classified information for some customers - usually only the compartment
> bits - and as such it would be better if we could encrypt them so that
> the handling of disks that contain labels could be reduced.
The internal encoding is supposed to make the label useless to a human.
In practice, unless there are many ways to encode a single label, then
traffic analysis is possible:
> > Therefore at the very least there's a traffic analysis issue.
>
> > But given that we don't encrypt anything in ZFS
> >now I would think it'd be fine for the ZFS crypto project to leave
> >dataset properties unencrypted and _later_ come back and address that
> >problem, leaving this case and ZFS crypto orthogonal to each other.
>
> Given that ZFS crypto explicitly has all properties (including user
> properties) in the clear I was trying to ensure that this case didn't
> build an architecture that mean't it wasn't possible to have the TX
> label encrypted. If a dnode system attribute rather than a dataset
> property was used then it would automatically be encrypted by ZFS
> crypto.
Sure, you could use an extended attribute of the dataset's root dnode,
which would work fine for filesystem type datasets and their snapshots,
but sadly not for zvols.
> However it seems that the desire is to know the label before
> not after mounting so a property needs to be used.
Why can't the system go through the motions all the way up to decrypting
the relevant items, then evaluate labeled security policy and only then
(assuming the MAC allows it) complete the mount? It seems to me that
whether the slabel property is a dataset property or an attribute of the
root dnode is an implementation detail from that p.o.v.
Nico
--
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@sac.sfbay.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 9:56 AM
in response to: Gary Winiger
|
|
> > + 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
Gosh I overlooked that in ensuring what was on disk was an
internally formatted label string. Indeed I agree, there
should be no reason to require the admin to enter a atohexlabel,
or for the system to display an internally formatted label.
The point is to not have the kernel have to deal with translating
human readable labels, likely before the label service is up.
I'll ask the project team about this all later today when I meet
with them.
Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@eng.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 12:16 PM
in response to: Gary Winiger
|
|
> > Well, they are static, no?
>
> Static to a given site. The issue is that the labels themselves are
> classified information for some customers - usually only the compartment
> bits - and as such it would be better if we could encrypt them so that
> the handling of disks that contain labels could be reduced.
That's why the internal format (aka hex label) is what is stored.
By official government ruling (at least from us DoD) it is
unclassified and may be view by anyone. Indeed the compartment
names are generally classified at the level of their name and
must not be visible below that level. label_to_str takes into
account these restrictions as well as produces the unclass version
of an m_label for storage where it doesn't need protection.
Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 12:20 PM
in response to: Gary Winiger
|
|
Gary Winiger wrote:
>>> Well, they are static, no?
>> Static to a given site. The issue is that the labels themselves are
>> classified information for some customers - usually only the compartment
>> bits - and as such it would be better if we could encrypt them so that
>> the handling of disks that contain labels could be reduced.
>
> That's why the internal format (aka hex label) is what is stored.
> By official government ruling (at least from us DoD) it is
> unclassified and may be view by anyone.
Does that then mean we can't allow for 'zfs get slabel' to return the
label_to_str() version ? I could live with that providing we can
provide the 'zfs set slabel=public' rather than needing to use the
internal format to do zfs set.
> Indeed the compartment
> names are generally classified at the level of their name and
> must not be visible below that level. label_to_str takes into
> account these restrictions as well as produces the unclass version
> of an m_label for storage where it doesn't need protection.
If the US DoD is happy with the internal format being treated as
unclassified then I'm fine with using a property for this providing the
issue of delegation is okay with the project team - ie it must follow
the normal delegation rules for properties - I would like to see
positive confirmation from the ZFS core team that they are comfortable
with this given the additional information provided.
--
Darren J Moffat
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
320
From:
US
Registered:
4/14/06
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 12:32 PM
in response to: darrenm
|
|
Darren J Moffat wrote:
> Gary Winiger wrote:
>>>> Well, they are static, no?
>>> Static to a given site. The issue is that the labels themselves are
>>> classified information for some customers - usually only the
>>> compartment bits - and as such it would be better if we could
>>> encrypt them so that the handling of disks that contain labels could
>>> be reduced.
>>
>> That's why the internal format (aka hex label) is what is stored.
>> By official government ruling (at least from us DoD) it is
>> unclassified and may be view by anyone.
>
> Does that then mean we can't allow for 'zfs get slabel' to return the
> label_to_str() version ? I could live with that providing we can
> provide the 'zfs set slabel=public' rather than needing to use the
> internal format to do zfs set.
'zfs get slabel' will work if it is run on a system with TX enabled,
with a compatible label encodings file, and with sufficient privilege to
translate the label. Otherwise it will just return the untranslated hex
label strings.
--Glenn
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@eng.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 12:53 PM
in response to: Gary Winiger
|
|
> > That's why the internal format (aka hex label) is what is stored.
> > By official government ruling (at least from us DoD) it is
> > unclassified and may be view by anyone.
>
> Does that then mean we can't allow for 'zfs get slabel' to return the
> label_to_str() version ? I could live with that providing we can
> provide the 'zfs set slabel=public' rather than needing to use the
> internal format to do zfs set.
Fortunately, no. Explicitly the translation would be
label_to_str(str_to_label(zfs get slabel), M_LABEL)
As I tried to say (below) takes into account the restrictions
(that is the caller must dominate the label being translated
or the translation will fail). This has been the case since
SunOS CMW 1.0.
> > Indeed the compartment
> > names are generally classified at the level of their name and
> > must not be visible below that level. label_to_str takes into
> > account these restrictions as well as produces the unclass version
> > of an m_label for storage where it doesn't need protection.
>
> If the US DoD is happy with the internal format being treated as
> unclassified then I'm fine with using a property for this providing the
> issue of delegation is okay with the project team - ie it must follow
> the normal delegation rules for properties - I would like to see
> positive confirmation from the ZFS core team that they are comfortable
> with this given the additional information provided.
OK then ;-) I'll be posting a summary of the issues discussed
and responses shortly so we're all on the same page.
Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@sac.sfbay.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 16, 2009 2:40 PM
in response to: Gary Winiger
|
|
> OK then ;-) I'll be posting a summary of the issues discussed
> and responses shortly so we're all on the same page.
During this case discussion a few points were raised. In order to work
towards convergence of the case the project team would like to respond to those
issues in summary. An updated spec will follow the convergence of the case.
Gary..
======
* PSARC/2007/315 Extensible Attribute Interfaces was referenced as a
dependency. The ZFS project team pointed out this was not a relevant
reference and that PSARC/2002/240 ZFS (Zettabyte Filesystem) was the
only case dependency required.
References to PSARC/2007/315 have been removed.
* What is the inheritance characteristic of the slabel property?
The slabel property is inherited just the same as the other
data set properties. Modifying the slabel's value requires
the specified privilege.
* How does zfs send deal with the slabel property?
send (and receive) preserve the slabel property. Making the
received data set available (mount) is restricted as specified
in the case materials mount policy.
* How is the slabel property related to delegation (zfs allow)?
Delegation deals with owner rights (Discretionary Policy as in
Discretionary Access Control, DAC), slabel is a Mandatory Policy
attribute. It deals with label based Mandatory Access Control,
MAC, thus unlike other zfs properties, additional policy applies
to the slabel property. In addition to having DAC rights to
modify the slabel property, the specified policy (privileges,
or setting to the label of the zone in which it is mounted
Read/Write) is required.
* Why have all three none/admin_low/admin_high; what is the relationship
between them?
The intent of this case is to prevent inadvertent access to labeled
data. The default slabel 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. As opposed to other
labels in a Trusted Extensions configuration, they are not
automatically set when mounted. Trusted Extensions administrators
have to explicitly specify how they want system data protected.
When mounted in the global zone, admin_low data sets must not have
the existing zoned property set and must be mounted read only.
labeled-(non-global)-zone admin_low data sets must be mounted read
only. admin_high labeled data sets, must not have the zoned property
set and may only be mounted in the global zone. This allows the
Trusted Extensions administrator to ensure that such labeled data
sets will not be unintentionally mounted in ways that could cause
inadvertent data access or modification.
* Why must zfs set slabel= and zfs get slabel only deal with internally
formatted labels?
There is no reason. The case will be updated to allow human
readable as well as internally formatted labels. Internally
formatted labels will be stored as the string value of the
slabel property. The zfs command will do the translation
using the standard Trusted Extensions interfaces which take
into account the calling user's rights to view/set human
readable label strings.
* What is the interaction between the zfs crypto project and this case?
The on disk format of the slabel string is public information
(unclassified) and requires no protection.
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
113
From:
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 17, 2009 7:50 AM
in response to: Gary Winiger
|
|
Gary Winiger wrote:
>> OK then ;-) I'll be posting a summary of the issues discussed
>> and responses shortly so we're all on the same page.
>
> During this case discussion a few points were raised. In order to work
> towards convergence of the case the project team would like to respond to those
> issues in summary. An updated spec will follow the convergence of the case.
>
> Gary..
> ======
>
> * PSARC/2007/315 Extensible Attribute Interfaces was referenced as a
> dependency. The ZFS project team pointed out this was not a relevant
> reference and that PSARC/2002/240 ZFS (Zettabyte Filesystem) was the
> only case dependency required.
>
> References to PSARC/2007/315 have been removed.
>
> * What is the inheritance characteristic of the slabel property?
>
> The slabel property is inherited just the same as the other
> data set properties. Modifying the slabel's value requires
> the specified privilege.
>
> * How does zfs send deal with the slabel property?
>
> send (and receive) preserve the slabel property. Making the
> received data set available (mount) is restricted as specified
> in the case materials mount policy.
>
> * How is the slabel property related to delegation (zfs allow)?
>
> Delegation deals with owner rights (Discretionary Policy as in
> Discretionary Access Control, DAC), slabel is a Mandatory Policy
> attribute. It deals with label based Mandatory Access Control,
> MAC, thus unlike other zfs properties, additional policy applies
> to the slabel property. In addition to having DAC rights to
> modify the slabel property, the specified policy (privileges,
> or setting to the label of the zone in which it is mounted
> Read/Write) is required.
>
> * Why have all three none/admin_low/admin_high; what is the relationship
> between them?
>
> The intent of this case is to prevent inadvertent access to labeled
> data. The default slabel 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. As opposed to other
> labels in a Trusted Extensions configuration, they are not
> automatically set when mounted. Trusted Extensions administrators
> have to explicitly specify how they want system data protected.
> When mounted in the global zone, admin_low data sets must not have
> the existing zoned property set and must be mounted read only.
> labeled-(non-global)-zone admin_low data sets must be mounted read
> only. admin_high labeled data sets, must not have the zoned property
> set and may only be mounted in the global zone. This allows the
> Trusted Extensions administrator to ensure that such labeled data
> sets will not be unintentionally mounted in ways that could cause
> inadvertent data access or modification.
>
> * Why must zfs set slabel= and zfs get slabel only deal with internally
> formatted labels?
>
> There is no reason. The case will be updated to allow human
> readable as well as internally formatted labels. Internally
> formatted labels will be stored as the string value of the
> slabel property. The zfs command will do the translation
> using the standard Trusted Extensions interfaces which take
> into account the calling user's rights to view/set human
> readable label strings.
>
> * What is the interaction between the zfs crypto project and this case?
>
> The on disk format of the slabel string is public information
> (unclassified) and requires no protection.
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris dot org
Two comments/requests from the ZFS team.
1) Please choose a more descriptive name for the property than 'slabel'.
Perhaps "securitylabel" or "seclabel" or something else?
2) Please make the property either not delegate-able or fully delegate-able.
By fully delegate-able we mean, no other privilege required if you've
been delegated permission to manipulate the property.
-tim
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
16
From:
US
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 17, 2009 2:40 PM
in response to: timh
|
|
Tim Haley wrote:
> Two comments/requests from the ZFS team.
>
> 1) Please choose a more descriptive name for the property than 'slabel'.
> Perhaps "securitylabel" or "seclabel" or something else?
The property will be named "mlslabel" (MLS = multi-level security), and the
updated spec will reflect this and explain the terminology. This is
chosen in
part due to considerations about distinguishing from other types of security
labels (e.g. FMAC).
> 2) Please make the property either not delegate-able or fully
> delegate-able.
> By fully delegate-able we mean, no other privilege required if you've
> been delegated permission to manipulate the property.
Accepted; the spec will be updated to reflect that mlslabel is specifically
not delegatable.
-Ric
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@sac.sfbay.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 17, 2009 4:22 PM
in response to: Gary Winiger
|
|
> From gww at eng dot sun dot com Tue Jun 9 18:02:31 2009
> Date: Tue, 09 Jun 2009 18:02:13 -0700 (PDT)
> From: Gary Winiger <gww at eng dot sun dot com>
> Subject: Redux: PSARC/2009/348 Security Labels for ZFS
> To: PSARC-ext at sun dot com
> Cc: rampart-dev-team at sun dot com, ric dot aleshire at sun dot 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 -----
>
>
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@sac.sfbay.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 17, 2009 4:25 PM
in response to: Gary Winiger
|
|
> 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.
Gary..
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Gary Winiger
gww@sac.sfbay.sun.com
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 18, 2009 12:20 PM
in response to: Gary Winiger
|
|
> > 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.
[...]
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
Posts:
113
From:
Registered:
3/9/05
|
|
|
|
Re: Redux: PSARC/2009/348 Security Labels for ZFS
Posted:
Jun 18, 2009 8:03 PM
in response to: Gary Winiger
|
|
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.
>
> [...]
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc at opensolaris dot org
|
|
|
|
|
