About Security Families

Computers (hosts or routers) that share the same template are considered to be part of the same security family.

The SMC Security Families tool is used to:

The templates specify labels and other security attributes that are used by the trusted networking software to control communications with other computers. If a computer does not have a template assigned, no communications are allowed with that computer.

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.

The Security Administrator role assigns the templates with the appropriate security attributes to each computer, either using default templates, adding new templates, or modifying existing templates if needed, before assigning them to computers.

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.

Contents

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:

For how to use IP labels for trusted routing or how to change the default DOI, see Advanced Security Attributes.

Top ^

How the Host Type is Used

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.

Top ^

How the Accreditation Range is Used

The Minimum Label and the Maximum Label are used in the following ways:

Top ^

How the DOI is Used

A default Domain of Interpretation is assigned in the default templates for all host types.

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.

DOIs in Trusted Solaris IPv4 Packets

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

DOIs in Trusted Solaris IPv6 Packets

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.

Top ^

How the Default Label is Used

Each unlabeled or RIPSO-type computer is assigned a single label in the Default Label field. The Default Label assigned to an unlabeled or RIPSO-type computer should reflect the level of trust that is appropriate for the computer and its users. For RIPSO hosts, the Default Label should be the same as the RIPSO Label (which is a combination the RIPSO Send Class and the RIPSO Send PAF).

How the Default Clearance is Used

Each single-label computer (with the Unlabeled or RIPSO host type) is assigned a clearance in the Default Clearance field. The clearance sets the upper limit for write operations performed on the Trusted Solaris computer by someone on the unlabeled host. For example, on an unlabeled computer with a Default Label of CONFIDENTIAL and Default Clearance of SECRET, a user who is working on a file system mounted from a Trusted Solaris host can open an upgraded file with a label of SECRET and write into it (if the file's name is known to that user).

Top ^

How Forced Privileges are Used

One or more privileges can be specified in the Forced Privileges field of a template that has the unlabeled host type.

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.

How Allowed Privileges are Used

Remote Trusted Solaris computers can usually be trusted to provide correct privileges. If needed, the privileges that a remote Trusted Solaris computer is allowed to use can be controlled by specifying a restricted set of privileges in the Allowed Privileges field of a template with the Trusted Solaris host type.

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.

Top ^

How Advanced Security Attributes are Used

The Advanced Security Attributes tab in the Security Families Template dialog is for setting the following options.

Top ^

How IP Labels are Used

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.

Top ^

How Default Templates are Used

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.

Default Templates for Trusted Solaris Computers

A computer running Trusted Solaris can be assigned any template that has the Trusted Solaris host type. The three default templates with the Trusted Solaris host type are tsol, tsol_cipso, and tsol_ripso.
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.

Top ^

Default Templates for Unlabeled or RIPSO Computers

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.

Default Templates for CIPSO and TSIX Computers

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.
Top ^

How the Wildcard Entry and Prefix Length are Used

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 delete an existing template, the security administrator role does the following substeps:

    1. Selects the template.

    2. Uses the right (menu) button to choose Delete from the pull-down menu.
  • Top ^

    How the Security Administrator Role Uses the Tabs in the Template Manager

    When the Security Administrator role chooses Add->Template or Properties either the New Template or Modify Template dialogs comes up with the tabs shown in the following table.

    General
      Name
      Host Type
      Trusted Solaris
      Unlabeled
      RIPSO
      CIPSO
      TSIX
    Access Control Attributes
      Accreditation Range
      Minimum Label
      Maximum Label
      Defaults
      Label
      Clearance
    Advanced Security Attributes
      Domain of Interpretation
     

    IP Options
      IP Label
      none
      CIPSO
      RIPSO
      RIPSO Send Class
      Top_Secret
    Secret
    Confidential
    Unclassified
      RIPSO Send PAF
      GENSER
    SIOP-ESI
    SCI
    NSA
    DOE
      RIPSO Return PAF
      GENSER
    SIOP-ESI
    SCI
    NSA
    DOE

      Privileges
      Forced
      Allowed

    Top

    For More Information

    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.