Contained WithinFind More DocumentationFeatured Support Resources |  Descargar este libro en PDF (937 KB)
File Formatslabel_encodings(4)NAME | Synopsis | Interface Level | Description | Extended Description | Examples | Attributes | Files | Diagnostics | See Also | Warnings | Notes NAME
Synopsis/etc/security/tsol/label_encodings Interface LevelThis file is part of the Defense Intelligence Agency (DIA) Mandatory Access Control (MAC) policy. This file might not be applicable to other Mandatory policies that might be developed for future releases of Solaris Trusted Extensions software. Parts of the label_encodings file are considered standard and are controlled by Defense Intelligence Agency document DDS-2600-6216-93, Compartmented Mode Workstation Labeling: Encodings Format, September 1993. Of that standard, the parts that refer to the INFORMATION LABELS: and NAME INFORMATION LABELS: sections are Obsolete. However, the INFORMATION LABELS: section must be present and syntactically correct. It is ignored. The NAME INFORMATION LABELS: section is optional. If present, it is ignored but must be syntactically correct. The following values in the optional LOCAL DEFINITIONS: section are obsolete. These values might only affect the obsolete bltos(3TSOL) functions, and might be ignored by the label_to_str(3TSOL) replacement function: ADMIN LOW NAME= ADMIN HIGH NAME= DEFAULT LABEL VIEW IS EXTERNAL DEFAULT LABEL VIEW IS INTERNAL DEFAULT FLAGS= FORCED FLAGS= CLASSIFICATION NAME= COMPARTMENTS NAME= DescriptionThe label_encodings file is a standard encodings file of security labels that are used to control the conversion of human-readable labels into an internal format, the conversion from the internal format to a human-readable canonical form, and the construction of banner pages for printed output. On a Solaris Trusted Extensions system, the label_encodings file is protected at the label admin_high. The file should be edited and checked by the security administrator using the Check Label Encodings action in the System_Admin folder in the Application Manager. Extended Description
In addition to the required sections of the label encodings file that are described in Compartmented Mode Workstation Labeling: Encodings Format, a Solaris Trusted Extensions system accepts optional local extensions. These extensions provide various translation options and an association between character-coded color names and sensitivity labels. The optional local extensions section starts with the LOCAL DEFINITIONS: keyword and is followed by zero or more of the following unordered statements: The final part of the LOCAL DEFINITIONS: section defines the character-coded color names to be associated with various words, sensitivity labels, or classifications. This section supports the str_to_label(3TSOL) function. It consists of the COLOR NAMES: keyword and is followed by zero or more color-to-label assignments. Each statement has one of the following two syntaxes:
where color value is a character-coded color name to be associated with the word word value, or with the sensitivity label label value, or with the classification label value. The character-coded color name color value for a label is determined by the order of entries in the COLOR NAMES: section that make up the label. If a label contains a word word value that is specified in this section, the color value of the label is the one associated with the first word value specified. If no specified word word value is contained in the label, the color value is the one associated with an exact match of a label value. If there is no exact match, the color value is the one associated with the first specified label value whose classification matches the classification of the label. ExamplesLOCAL DEFINITIONS:
DEFAULT USER SENSITIVITY LABEL= C A;
DEFAULT USER CLEARANCE LABEL= S ABLE;
COLOR NAMES:
label= Admin_Low; color= Pale Blue;
label= unclassified; color= light grey;
word= Project A; color= bright blue;
label= c; color= sea foam green;
label= secret; color= #ff0000; * Hexadecimal RGB value
word= Hotel; color= Lavender;
word= KeLO; color= red;
label= TS; color= khaki;
label= TS Elephant; color= yellow;
label= Admin_High; color= shocking pink;
AttributesSee attributes(5) for descriptions of the following attributes:
Files
Diagnostics
The following diagnostics are in addition to those found in Appendix A of Compartmented Mode Workstation Labeling: Encodings Format: See Alsochk_encodings(1M), label_to_str(3TSOL), str_to_label(3TSOL), attributes(5), labels(5) Solaris Trusted Extensions Label Administration Defense Intelligence Agency document DDS-2600-6216-93, Compartmented Mode Workstation Labeling: Encodings Format, September 1993. WarningsCreation of and modification to the label encodings file should only be undertaken with a thorough understanding not only of the concepts in Compartmented Mode Workstation Labeling: Encodings Format, but also of the details of the local labeling requirements. The following warnings are paraphrased from Compartmented Mode Workstation Labeling: Encodings Format. Take extreme care when modifying a label encodings file that is already loaded and running on a Solaris Trusted Extensions system. Once the system runs with the label encodings file, many objects are labeled with sensitivity labels that are well formed with respect to the loaded label encodings file. If the label encodings file is subsequently changed, it is possible that the existing labels will no longer be well-formed. Changing the bit patterns associated with words causes existing objects whose labels contain the words to have possibly invalid labels. Raising the minimum classification or lowering the maximum classification that is associated with words will likely cause existing objects whose labels contain the words to no longer be well-formed. Changes to a current encodings file that has already been used should be limited only to adding new classifications or words, changing the names of existing words, or modifying the local extensions. As described in Compartmented Mode Workstation Labeling: Encodings Format, it is important to reserve extra inverse bits when the label encodings file is first created to allow for later expansion of the label encodings file to incorporate new inverse words. If an inverse word is added that does not use reserved inverse bits, all existing objects on the system will erroneously have labels that include the new inverse word. NotesThis file is only meaningful for the DIA MAC policy. Parts of it are obsolete and retained for ease of porting. The obsolete parts might be removed in a future Solaris Trusted Extensions release. Defining the label encodings file is a three-step process. First, the set of human-readable labels to be represented must be identified and understood. The definition of this set includes the list of classifications and other words that are used in the human-readable labels, relations between and among the words, classification restrictions that are associated with use of each word, and intended use of the words in mandatory access control and labeling system output. Next, this definition is associated with an internal format of integers, bit patterns, and logical relationship statements. Finally, a label encodings file is created. The Compartmented Mode Workstation Labeling: Encodings Format document describes the second and third steps, and assumes that the first has already been performed. NAME | Synopsis | Interface Level | Description | Extended Description | Examples | Attributes | Files | Diagnostics | See Also | Warnings | Notes sel_config(4)NAME | Synopsis | Description | Attributes | See Also NAME
Synopsis/usr/dt/config/sel_config Description
The sel_config file specifies how a system that is configured with Trusted Extensions behaves when a user transfers data between windows that have different labels. Transfer operations include cut-and-paste, copy-and-paste, and drag-and-drop. There are two types of entries in this file: automatic confirmation and automatic reply. Automatic ConfirmationThis type of entry specifies whether a confirmation window, the selection confirmer, displays. Each entry has the form:
relationship identifies the result of comparing the selected data's source and destination windows' labels. There are three allowed values: confirmation specifies whether to perform automatic confirmation. Allowed values are: Automatic ReplyA single user operation can involve several flows of information between the source and destination windows. The automatic reply set of entries provides a means to reduce the number of confirmations that are required of the user. There must be one entry of this form:
If value is y (for yes), then the remaining entries of the set are used as attributes for the selection data (rather than the actual contents) to complete the operation without confirmation. If value is n (for no), then the remaining entries are ignored. Defaults can be specified for any type field that appears in the Confirmer window. Below are some sample entries for defaults.
The TARGETS entry, when used, returns the list of target atoms that are supported by the source window. The Pixel Sets and Type Of Monitor entries are used for animation during a drag-and-drop operation. The LENGTH entry specifies the number of bytes in the selection. AttributesSee attributes(5) for descriptions of the following attributes:
See AlsoNAME | Synopsis | Description | Attributes | See Also tnrhdb(4)NAME | Synopsis | Description | Examples | Attributes | Files | See Also | Warnings | Notes NAME
Synopsis/etc/security/tsol/tnrhdb Description
The tnrhdb database specifies which remote-host template to use for each host, including the local host, in the distributed system. tnrhdb works together with the tnrhtp(4) database to enable the administrator to establish the security and network accreditation attributes for each host. If a host's IP address cannot be matched to some entry in the tnrhdb database, communication with the host is not permitted. The trusted network software uses a network “longest prefix of matching bits” mechanism when looking for a tnrhdb entry for a host. The software looks first for an entry that is specific to the host. If the software does not find a matching entry, the software falls back to searching for an entry with the longest prefix of a matching bit pattern, and so on. Note – The actual numeric value of the subnet address or other subnetting information on the system (for example, from the netmasks(4) file) are not considered by this mechanism. Using the “longest prefix of matching bits” mechanism, an IPv4 wildcard entry (IPv4 address 0.0.0.0) has a prefix length of 0 and hence can match any IPv4 address. Each entry in tnrhdb consists of a line of the form IP-address:template. After each modification to the tnrhdb database, the administrator should run tnchkdb(1M) to check the syntax. If this database is modified while the network is up, the changes do not take effect until tnctl(1M) updates the kernel. ExamplesExample 1 Sample IPv4 Entries
Example 2 Sample tnrhdb FileThe templates in the following example are first defined in the tnrhtp, then used in the tnrhdb file. The example shows a host that uses the template cipso, a host that uses the template public, and a host that uses the template needtoknow. There are two subnets. One subnet uses the template internal, and the other subnet uses the template secret. Every other host uses the template default-template that is specified in the wildcard entries for IPv4 hosts and IPv6 hosts.
AttributesSee attributes(5) for descriptions of the following attributes:
FilesSee Alsosmtnrhdb(1M), hosts(4), ipnodes(4), netmasks(4), tnchkdb(1M), tnctl(1M), tnd(1M), tninfo(1M), tnrhtp(4), tnzonecfg(4), attributes(5) Chapter 12, Trusted Networking (Overview), in Solaris Trusted Extensions Administrator’s Procedures WarningsChanging a template while the network is up can change the security view of an undetermined number of hosts. NotesThe colon (:) character is a database separation character. If the colon is used as part of a data field, it must be escaped with a backslash (\), as in fe80\:\:a00\:20ff\:fea0\:21f7. The administrator might want to create one tnrhdb entry for each host that runs Trusted Extensions software, and make one subnet entry that applies to all unlabeled hosts that have the same security attributes. Then, the administrator can make a separate entry for each host that must be assigned a different set of security attributes. NAME | Synopsis | Description | Examples | Attributes | Files | See Also | Warnings | Notes tnrhtp(4)NAME | Synopsis | Description | Examples | Attributes | Files | See Also | Warnings NAME
Synopsis/etc/security/tsol/tnrhtp Description
The tnrhtp database of templates is specified by the administrator for convenience when assigning accreditation and security attributes for each host in the distributed system, including the local host and network. tnrhtp works together with tnrhdb(4). IP addresses in tnrhdb can be assigned only to templates that are defined in the tnrhtp database. After each modification to the tnrhtp database, the administrator should run tnchkdb(1M) to check the syntax. Each entry in the template database is entered as one long line. The fields of the entry are separated by semicolons (;):
A pound sign (#) as the first character of a line indicates a comment line, which is ignored. If the tnrhtp database is modified while the network is up, the changes do not take effect immediately unless tnctl(1M) is used to update the template entries. Otherwise, the changes take effect when next polled by the trusted network daemon, tnd(1M). Administrators are allowed to add new templates and modify attributes of existing templates while the network is up. ExamplesExample 1 Unlabeled Host EntriesFor the sake of clarity on this man page, examples are shown using a continuation character (\). In the database file, however, the backslash is not permitted because each entry is made on a single line.
Unless the label at which you want to communicate with an unlabeled host is ADMIN_LOW, you should not use the above template. Rather, you should use a template that matches an entry in your label encodings file. The following example matches an entry in the sample label_encodings file.
Example 2 CIPSO Host Entry
AttributesSee attributes(5) for descriptions of the following attributes:
FilesSee AlsoWarningsChanging a template while the network is up can change the security view of an undetermined number of hosts. Allowing unlabeled hosts onto a Solaris Trusted Extensions network is a security risk. To avoid compromising the rest of your network, such hosts must be trusted in the sense that the administrator is certain that these unlabeled hosts will not be used to compromise the distributed system. These hosts should also be physically protected to restrict access to authorized individuals. If you cannot guarantee that an unlabeled host is physically secure from tampering, it and similar hosts should be isolated on a separate branch of the network. NAME | Synopsis | Description | Examples | Attributes | Files | See Also | Warnings tnzonecfg(4)NAME | Synopsis | Description | Examples | Attributes | Files | See Also NAME
Synopsis/etc/security/tsol/tnzonecfg Description
The tnzonecfg database is a list of Solaris Trusted Extensions zone configuration entries for the local host. The database is indexed by zone name. Each configuration entry specifies a zone's label, multilevel port (MLP), and other zone-related information for zone creation. Each entry in the zone configuration database consists of five fields. Each entry is on one long line, with fields of the entry separated by colons (:).
A pound sign (#) as the first character of a line indicates a comment line, which is ignored. After each modification to the tnzonecfg database, the administrator should run tnchkdb(1M) to check the syntax. If this database is modified while the network is up, the changes do not take effect until tnctl(1M) updates the kernel. ExamplesExample 1 Sample Zone Configuration EntriesIn the database file, each zone entry is made on a single line. In this example, there are four non-global zones: public, internal, needtoknow, and restricted. Only the global zone and the public zone have MLPs. In the global entry, the zone-mlp-list value of 111/tcp;111/udp;2049/tcp;6000-6003/tcp specifies these ports as MLPs in the global zone only. The shared-mlp-list value of 6000-6003/tcp specifies these ports as MLPs for the shared IP addresses, that is, for the labeled zones. With a network-policy of 1, only the global zone accepts incoming packets from a host whose label is different from its own. In the public entry, the network-policy value of 0 restricts it to receiving public non-transport traffic. The zone-mlp-list value of 8080/tcp makes the public zone's web browser port an MLP. The 8080 tcp port in the other zones is a single-level port, so is not listed. Similarly, each labeled zone has a single–level 111 port, 2049 port, and so on.
AttributesSee attributes(5) for descriptions of the following attributes:
FilesSee Alsosmtnzonecfg(1M), tnchkdb(1M), tnctl(1M), tnd(1M), tninfo(1M), zonecfg(1M), label_encodings(4), tnrhdb(4), tnrhtp(4), attributes(5) Solaris Management Console Tools in Solaris Trusted Extensions Administrator’s Procedures NAME | Synopsis | Description | Examples | Attributes | Files | See Also TrustedExtensionsPolicy(4)NAME | Synopsis | Description | Attributes | Examples | Files | See Also NAME
Synopsis/usr/X11/lib/X11/xserver/TrustedExtensionsPolicy /usr/openwin/server/etc/TrustedExtensionsPolicy Description
TrustedExtensionsPolicy is the configuration file for Trusted Extensions X Server Extension (SUN_TSOL). SUN_TSOL provides security policy enforcement. This enforcement is based on Mandatory Access Control (MAC) and Discretionary Access Control (DAC). Blank lines and comments in the TrustedExtensionsPolicy file are ignored. Comments start with a pound sign (#). The format of the file is as follows:
where keyword can be one of the following: For possible keyword values, see the /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy file for the Xorg X server. For Xsun, see the /usr/openwin/server/etc/TrustedExtensionsPolicy file. AttributesSee attributes(5) for descriptions of the following attributes:
ExamplesThe following entry in the TrustedExtensionsPolicy file
polyinstantiates the
If the entry is missing, or commented out, the Similarly, the following entry instantiates the WM_ICON_SIZE property once:
If the entry is missing, or commented out, the WM_ICON_SIZE property is polyinstantiated. Files
See AlsoXGetAtomName(3X11), attributes(5) NAME | Synopsis | Description | Attributes | Examples | Files | See Also |
|||||||||||||||||||||||||||||||||||||||||||||||
|