Sending messages, mail, and data sets all work similarly with regard to labeling in an MLS environment.
If write-down is allowed, messages, mail, and data sets that are created do not inherit the label of the user who created them. Instead, they will be unclassified and users can access the data, if access rules allow it.
However, when write-down is prohibited, messages, mail, and data sets inherit the label of the user who creates them. For example, if you write a message while logged on at SECRET, the message is labeled SECRET. In a write-down protected MLS environment, to enable sites to send BRODCAST messages across all labels of the system, the security administrator must set the facilities that are used to send BRODCAST messages to the lowest label on the system (SYSLOW). To send a BRODCAST message, one must log on at the lowest label of the system (SYSLOW). Messages can be sent up but not down. These protections ensure that a user cannot place sensitive data in a message that can be received and stored at a level where unauthorized users can access it.
Examples: sending messages
Bill logs on with the SYSHIGH label. He can send messages, mail, or data sets to Mary, who is logged on with the SYSHIGH label, and to John, who is logged on with the SYSHIGH label.
Bill can send a message to Jane, who is logged on at the SECRET label, but she cannot receive the message while logged on at the SECRET label. When she logs on with a SYSHIGH label she can receive Bill's message. Until she does, however, she cannot view the message.
If Bill sent Mary a SYSHIGH data set, it would not appear in her reader until she logged on with her SYSHIGH label.
Jennifer is logged on with the SYSLOW label (the system low), can send a BRODCAST message about a company meeting to users at all labels of the system. Any user can read the message without having to log off his current label.
An MLS system does not permit a classified user to delete a classified data set that is at a higher label than his current label. A user must have a label that dominates that of the object he wants to delete.
When MLS is active and write-down is allowed, data sets that are created do not inherit the label of the user who created them. Instead, they will be unclassified until an authorized security administrator labels them. Therefore, users can access the data as long as it remains unclassified. However, once a security administrator classifies the data, MAC access to it is determined by label dominance checking rules.
When MLS is active and write-down is prohibited, the data set inherits the session security label of the user who created it. When a user logs on with a SECRET label and creates a data set, that data set is labeled SECRET.
When MLS is active and write-down is not protected, a new data set will not be labeled by the system at the time it is created. Also, if it was not assigned a security label by the security administrator before it was created, the data set will be unlabeled (“unclassified”). Thus, if the data set is renamed, the new data set will not have a security label unless it is assigned one by the security administrator.
When MLS is active and write-down is protected, when an existing data set (“old data set”) is renamed, if the newly named data set (“new data set”) does not have a security label, then the security label of the old data set will be used as the security label of the new data set.
When a data set is renamed, read/write access is requested, which requires the user's security label to be equal to the old data set's security label (if it has a label), to rename it. If the data set does not have a label, the user can rename it, as long as access rules permit it. In most cases, the new data set label will be equal to the old data set label, except when the old data set label is SYSNONE or SYSMULTI and the user label isn't.
In the case where the old data set name and the new data set name both already have security labels, but they are different from each other, the following requirements must be met in order for the data set to be successfully renamed, as long as access rules also permit it:
When MLS is active and write-down is allowed, users can copy classified data as long as their security labels are not disjoint, based on MAC label dominance checking rules. The user's security label must dominate the security label of the data.
When MLS is active and write-down is protected, the data's security label must be equivalent to the user's security label. The following examples explain what happens when a user attempts to copy a data set when write-down is prohibited.
Example: Copy a dataset
In this example, Bill logs on at LABELA.
Bill's security label grants him access to the WORK.DISCOVER data set, which is also labeled with LABELA.
Bill copies the WORK.DISCOVER data set (LABELA) to the WORK.ATLANTIS data set (LABELA).
Bill can copy the data set because his label is equal to the label of the new data set.
Bill logs on at LABELB.
Bill copies WORK.DISCOVER to the new WORK.ATLANTIS that is then labeled LABELB.
Example: Copy a dataset
Jim logs on with LABELD.
Jim's manager tells him that the members of the data set WORK.BUDGET (LABELD) should be moved to the WORK.ACTUAL data set (LABELE).
Jim cannot copy the WORK.BUDGET data set (LABELD) to the WORK.ACTUAL data set (LABELE) because the label of the data set (LABELE) does not equal his label (LABELD) and he cannot write down.
If Jim logs on with LABELE, he cannot get read access to the data set WORK.BUDGET (LABELD). Jim must reclassify the data set. To reclassify this data set, Jim must enlist the help of the security administrator who is authorized to reclassify data. The security administrator is trusted to follow the reclassification procedures. To give Jim the ability to move members of the data set WORK.BUDGET (LABELD) to the WORK.ACTUAL data set, the security administrator could reclassify WORK.ACTUAL from LABELE to LABELD. After the security administrator reclassifies the data sets, Jim can copy the data sets.
Only authorized security administrators can reclassify data. CA Top Secret creates a logging record each time a subject or object is reclassified. In this way, the site can monitor when data sets get reclassified, how the classification changes, and who executes the change.
Note: A security administrator can also give a user “controlled write-down” authorization, to allow a user to declassify data without having to reclassify it. This is not recommended, except in special cases.
|
Copyright © 2010 CA Technologies.
All rights reserved.
|
|