The SMC Security Families tool is used to:
The site's security administrator decides which computers should be allowed to communicate with the site and which security attributes each computer needs to have assigned for these purposes.
Templates can be assigned directly to a computer or indirectly through a wildcard entry that assigns a template to a network address that includes the computer.
Overview of Attributes Assigned in Templates
Every template has a Host Type, which determines which protocol is used to communicate with the computer that is assigned the template. Every template also has a Accreditation Range (consisting of a Minimum Label and a Maximum Label) and a default DOI (Domain of Interpretation). Each host type has its own set of additional required and optional security attributes, which are described below:
Templates for the Unlabeled and
RIPSO host types specify a
Default Label that is used
to control communications with computers that operate at a single label
(such as Solaris or RIPSO-cognizant operating systems).
Because communications with these computers are essentially
limited to the Default Label, they are referred to as single-label
computers.
The template for the Trusted Solaris host type has an Allowed Privileges field that can optionally be used to limit the privileges accepted from the remote computer.
The template for any host type can be used to specify IP labels to be used in trusted routing of packets.
Name | Protocols and Notes |
---|---|
Trusted Solaris |
The TSOL protocol simplifies passing security attributes between computers
running Trusted Solaris 2.x or later. TSOL is a derivative of the TSIX(RE) 1.1 - SAMP protocol that passes the security attributes in a similar place in the network protocol stack and uses similar header structures. The TSOL protocol passes security attributes in binary form and thus does not require token mapping.
NOTE: For communication between Trusted Solaris computers, either the Trusted Solaris or TSIX host type can be assigned in the templates, depending on whether you want the labels to be transmitted in binary form or in token form. If only the labels' names differ on two computers while the labels' binary representations are the same, the Trusted Solaris host type can be assigned. If the labels' names are the same but the labels' binary representations are different on both Trusted Solaris computers, the TSIX host type can be assigned. |
Unlabeled | This host type is assigned to computers running Solaris or other unlabeled operating systems to specify a default label and default clearance to apply to communications with the unlabeled computer. Also, a minimum and maximum label can be set to allow the sending of packets to an unlabeled gateway for forwarding when the packets' labels do not match the default label and would therefore not be sent to the computer as a destination. |
RIPSO | Revised IP Security Option (RIPSO) described in the IETF RFC 1108. It specifies a DoD IP labeling method to incorporate labels into IP packets, which are then used for network mandatory access control checks. A fixed RIPSO label specified in the template is applied to network packets interchanged with the particular host. Though this functionality does not fully meet the RFC specifications, it is expected to supply sufficient functionality where RIPSO labels are needed. |
CIPSO | Common IP Security Option (CIPSO) protocol TSIX(RE) 1.1 is used to specify security labels that are passed in the IP options field. CIPSO labels are derived automatically from the data's label. Tag type 1 is used to pass the CIPSO security label. This label is then used to make security checks at the IP level and to label the data in the network packet. |
TSIX | Trusted Security Information Exchange for Restricted Environments (TSIX/RE) protocol uses token mapping to pass security attributes. Can be used for computers running Trusted Solaris or other TSIX-cognizant operating environments. |
To set the range of labels that can be used when communicating with a computer.
In order for a packet to be sent to a computer, the label of the packet must be within the label range assigned to the computer in its template.
To set a label range for packets being forwarded through an unlabeled or RIPSO gateway.
The label range can be specified in the template for an unlabeled or RIPSO host type to enable the computer to receive a packet for forwarding, even when the packet's label is not the same as the Default Label.
Two computers need to have the same DOI in order to communicate. Organizations with the same DOI need to agree among themselves about how labels and other security attributes are to be interpreted.
As mentioned under How the Host Type is Used, either the Trusted Solaris or TSIX host type can be specified in templates assigned to Trusted Solaris computers.
In Trusted Solaris IPv4 packets, the DOI is carried in the packet along with the label. In an IPv4 packet, the specified DOI is included both with the IP options (if any are specified) and in the SAMP header.
Headers ( Options [IP options including DOI] ) | SAMP including DOI | Data |
In Trusted Solaris IPv6 packets, label information is carried in multilevel security (MLS) options portion of the packet's Headers. Because label information is in the Headers portion of the packet, the packet's label can be used for routing.
NOTE: With IPv6, trusted routing using IP labels is not supported.
Headers ( Options [SAMP MLS options including DOI] | Data |
If you want to specify another DOI than the default, go to the Advanced Security Attributes tabs.
An unlabeled computer does not understand about privileges. Specifying privileges in this field affects only how the Trusted Solaris computer handles requests from a program that is running on the unlabeled computer.
Privileges can be specified to allow a client from an unlabeled computer to do something not otherwise permitted, such as reading a file whose label dominates that of the client or communicating with X clients owned by another user.
Processes running on a remote Trusted Solaris system communicate their effective privileges as part of their security attributes. You can locally restrict those privileges to the ones that are specified in the Allowed Privilege set.
The Advanced Security Attributes tab in the Security Families Template dialog is for setting the following options.
Replace the default domain of interpretation (DOI) by entering an integer into the DOI field.
Two organizations that use the same DOI for communicating need to agree among themselves to interpret label information the same way.
Choose either "none," "CIPSO," or "RIPSO" from the IP Label pull-down menu.
When the CIPSO IP label is assigned in a template, then the label of the outgoing packet is derived from the actual label of the data on the Trusted Solaris computer. The security administrator needs to plan ahead to ensure that the labels defined in the label_encodings((4) file map well to CIPSO labels. The classification value must be less than or equal to 255. All compartment bit numbers must be less than or equal to 239.
Because the ADMIN_HIGH label exceeds the limits stated above, packets with the ADMIN_HIGH label are dropped by default. To enable ADMIN_HIGH labels to be sent across network interfaces, the security administrator needs to edit the /etc/system file and set the tsol_admin_high_to_cipso flag to 1 on all computers involved. When tsol_admin_high_to_cipso is set, the ADMIN_LOW label is mapped to a CIPSO label with a classification value of 255 and with all compartment bits from 0 to 239 turned on. The security administrator also must ensure that no label in the user accreditation range has a classification of 255 with all compartment bits from 0 to 239 or higher turned on, because that label would be indistinguishable from the remapped ADMIN_HIGH label. Also, to ensure that all labels are mappable, the security administrator needs to ensure that no user label has any compartments numbered above 239.
If you choose RIPSO, you need to choose a RIPSO Send Class, an optional RIPSO Send PAF, and RIPSO Return PAF from the pull-down menus.
PAF means Protection Authority Flag. Any Send PAF specified is used like a compartment name along with the classification to make up the RIPSO label (as in Top_Secret SCI). The PAF specified in the Return PAF is used in labeling ICMP messages that can be generated as errors in response to incoming RIPSO labeled packets. The Send Class is also sent back with the RIPSO error in an ICMP message.
The RIPSO label should have the same name as the Default Label assigned to the host. Make sure to specify the same RIPSO label and RIPSO PAFs for the sending host, all gateways, and the destination host.
If a computer has an IP Label type of RIPSO or CIPSO specified in its template, the specified type of IP label is put into outgoing packets, and the incoming packets from the specified host must contain an IP label of the specified type.
IP labels can be used for trusted routing. Packets with an IP label are only forwarded to routers whose label range allows the specified IP label.
Some organizations have the requirement to label all of their packets with RIPSO or CIPSO labels, unless the packets are being sent to unlabeled computers directly connected to the network. Others need to use IP labels for trusted routing of packets going to certain destination hosts.
In a homogeneous Trusted Solaris security domain, this is accomplished by assigning a template with the Trusted Solaris host type and an IP label of either RIPSO or CIPSO to all or some Trusted Solaris computers. (The easy way to do this is to assign the appropriate default template, either tsol_ripso [Trusted Solaris with RIPSO] or tsol_cipso [Trusted Solaris with CIPSO]).
Similarly a template with the TSIX host type can also be configured with CIPSO or RIPSO labels to achieve the same labeling of packets for TSIX hosts. And, of course, packets to and from a host assigned a template with a CIPSO or RIPSO host type carry either a CIPSO or RIPSO IP label.
The IP Options supported in the templates for the Unlabeled host type provide a way to label packets coming into a Trusted Solaris security domain from unlabeled computers. Unlabeled packets become labeled when they pass through Trusted Solaris/ripso or Trusted Solaris/cipso gateways on their way to other Trusted Solaris/ripso or Trusted Solaris/cipso computers. The RIPSO or CIPSO labels are stripped from packets before they are delivered to unlabeled computers, which are typically outside the security domain. To accomplish this, administrators can specify an IP label of RIPSO or CIPSO in the template for an unlabeled host.
Multiple templates are defined for some host types.
Templates can be modified to assign restricted accreditation ranges and security attributes, when needed, to computers (either hosts or routers) with whom communications are allowed.
The simplest and safest configuration is to enable communication only among Trusted Solaris computers that share the same label_encodings(4) file. To set up such a configuration, the System Administrator role can assign the default tsol template or other similar template with the Trusted Solaris host type to all Trusted Solaris computers. No modifications are needed.
tsol | Assign this or a similar template with the Trusted Solaris host type to a Trusted Solaris computer when you do not plan to specify IP labels for trusted routing. |
tsol_cipso | Assign this or a similar template with the Trusted Solaris host type to a Trusted Solaris computer when you plan to use CIPSO labels for trusted routing. |
tsol_ripso | Assign this or a similar template with the Trusted Solaris host type to a Trusted Solaris computer when you plan to use RIPSO labels for trusted routing. |
Trusted Solaris supports communications with computers running operating environments that do not recognize labels (such as the Solaris operating environment). A computer that does not recognize labels or that uses RIPSO labels must be assigned a single label and a clearance that limit communications with that computer. Before assigning a template that has the Unlabeled or RIPSO host type to an unlabeled host, specify the following:
WARNING: When creating or modifying a template for an unlabeled or RIPSO-type computer, do not forget to change the default label to reflect the level of trust that you have determined is appropriate for the unlabeled or RIPSO-type computer and its users. Customers who report problems with not being able to communicate with remote single-label computers at the expected label have almost always forgotten to specify that label in the Default Label field.
The default unlabeled templates and the ripso_top_secret templates are valid only when the default label_encodings(4) file is used or another label_encodings uses the same label names and binary representations for the labels.admin_low |
This template is assigned to the wildcard address 0.0.0.0 by default
because it is needed at the initial boot time
before the system is configured.
The template assignment is stored in local tnrhdb/tnrhtp(4) files
in /etc/security/tsol
because the name server is not yet available.
The admin_low template should not be used at any other
time.
Once the system is installed, the security administrator should either
remove the 0.0.0.0 entry entirely or change it to assign
a template with an appropriate host type and security attributes.
The security administrator needs to make an entry that assigns a template with the appropriate host type and security attributes to every computer that the host needs to contact when it boots: name service master, routers, loghost, the local computer's own IP address(es), and any audit server. The security administrator makes these entries using the SMC Security Families Remote Host tool with the Files scope on each Trusted Solaris computer. |
unclassified | When the unclassified label is defined in the default or another similare label_encodings(4) file, you can use this template to assign the unclassified label to an unlabeled computer. |
confidential | When the default or other label_encodings(4) file has the confidential label defined, you can use this template to assign the confidential label to an unlabeled computer. |
secret | When the default or other label_encodings(4) file has the secret label defined, you can use this template to assign the secret label to an unlabeled computer. |
top_secret | When the default or other label_encodings(4) file has the top_secret label defined, you can use this template to assign the top_secret label to an unlabeled computer. |
ripso_top_secret | When the default or other label_encodings(4) file has the top secret label, and the computer recognizes RIPSO labels, you can use this template to communicate with the computer using the Top_Secret RIPSO label. |
cipso | For a computer that recognizes CIPSO labels. |
tsix | For a computer running Trusted Solaris or other TSIX-cognizant operating environment, when you want to pass security attributes in token form. |
A wildcard IP address is the IP address of a subnetwork. A subnetwork is defined by its IP address and its netmask. The netmask determines the prefix that has to be common to all the addresses belonging to a subnetwork.
For example, the IP address 129.150.123.0 is a wildcard with a netmask = 255.255.255.0. The subnet is made up of all the IP addresses between 129.150.123.1 and 129.150.123.255.
A optional Prefix Length can be specified in the form of an integer. The prefix length determines the size of the subnet and is the number of 1 bits in the netmask.
Conventional subnetting is based on the following addressing scheme:
class A addresses: a.0.0.0, or a | class B addresses: a.b.0.0, or a.b | class C addresses: a.b.c.0, or a.b.c |
netmask = 255.0.0.0 | netmask = 255.255.0.0 | netmask = 255.255.255.0 |
prefix length = 8 | prefix length = 16 | prefix length = 24 |
With variable-length subnetting, the prefix length does not have to be a multiple of 8. For example, you can have the IP address 129.150.123.224, with a netmask = 255.255.255.224, and a prefix length = 27, covering the addresses between 129.150.123.225 and 129.150.123.255. IPv4 network addresses can have a prefix length between 1 and 32. IPv6 network addresses can have a prefix length between 1 and 128.
The trusted network software looks first for an entry that specifically assigns the host to a template, and if it does not find a specific entry, the software looks for the subnetwork entry that best matches the hosts's IP address (a subnetwork with the longest prefix length to which that address belongs).
If a computer's IP address cannot be matched to an entry, communication with that computer is not permitted.
A default 0.0.0.0 entry matches all computers that are not otherwise matched by other entries.
Sites that need to strictly control remote access
should remove the 0.0.0.0 entry using the Remote Hosts
tool and to carefully assess whether to use any
wildcard addresses. (For more information, see the
tnrhdb(4) man page.)
How the Security Administrator Role
Uses the Security Families Tool
Double-clicks the Security Families tool.
All currently-defined templates display in the right hand pane.
To add a new template, the security administrator role does the following:
Chooses Action->Add Template.
The New Template dialog displays.
Supplies the desired values in the fields in the Template Manager.
Clicks OK
To modify an existing template, the security administrator role does the following:
Double-clicks the name of a template.
The Modify Template dialog displays with the name of the currently selected template at its top.
Supplies the desired values in the fields in the Template Manager.
Clicks OK
To change the assignment of a computer or network to a template, the security administrator role does the following:
Double-clicks the name of a template.
All computers and networks that are currently in the same Security Family display in the right hand pane.
Double-clicks the icon for the computer or network.
Chooses Action->Properties.
The Modify Remote Host Entry dialog displays with the IP address of the network or computer at its top.
Supplies the desired values in the fields in the Template Manager.
Clicks OK
To assign an existing template to a computer or network, the security administrator role does the following substeps:
Double-clicks the name of a template.
All computers currently defined in the same Security Family display in the right hand pane.
Chooses Action->Add Host.
The New Remote Host Entry dialog displays.
Types in either the Hostname or the IP Address for any computer or network to which the template should be assigned.
If a Hostname is entered, the IP address is looked up. If an IP Address is entered, then the hostname is looked up. The IP Address field accepts any valid IPv4 or IPv6 address for the computer or network.
Types in an optional Prefix Length that indicates the length of the network portion of the address.
Chooses the name of a template from the Template pull-down menu.
Clicks OK.
Selects the template.
General
|
Access Control Attributes
|
Advanced Security Attributes
|
For more about trusted network security attributes and databases,
see the Trusted Solaris Administration
Overview and the Trusted Solaris Administrator's Procedures manuals,
which are available at http://docs.sun.com
and on the AnswerBook CD shipped with the operating environment software.
See the tnrhdb
(4) man page for more about fallback and wildcard entries;
see the tnrhtp
(4) man page for more about templates.