Solaris Trusted Extensions Reference Manual

File Formats

label_encodings(4)

NAME

label_encodings – label encodings file

Synopsis

/etc/security/tsol/label_encodings

Interface Level

This 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=

Description

The 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:

DEFAULT USER SENSITIVITY LABEL= sensitivity label: This option specifies the sensitivity label to use as the user's minimum sensitivity label if none is defined for the user in the administrative databases. The default value is the MINIMUM SENSITIVITY LABEL= value from the ACCREDITATION RANGE: section of the label encodings file.
DEFAULT USER CLEARANCE= clearance: This option specifies the clearance to use as the user's clearance if none is defined for the user in the administrative databases. The default value is the MINIMUM CLEARANCE= value from the ACCREDITATION RANGE: section of the label encodings file.

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:

word= word value; color= color value;

label= label value; color= color value;

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.

Examples

Example 1 A Sample LOCAL DEFINITIONS: Section

LOCAL 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;

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtsr
Stability Level	Mixed. See `INTERFACE LEVEL`, above.

Files

/etc/security/tsol/label_encodings: The label encodings file contains the classification names, words, constraints, and values for the defined labels of this system. It is protected at the label admin_high.

Diagnostics

The following diagnostics are in addition to those found in Appendix A of Compartmented Mode Workstation Labeling: Encodings Format:

Can't allocate NNN bytes for color names table.: The system cannot dynamically allocate the memory it needs to process the COLOR NAMES: section.
Can't allocate NNN bytes for color table entry.: The system cannot dynamically allocate the memory it needs to process a Color Table entry.
Can't allocate NNN bytes for color word entry.: The system cannot dynamically allocate the memory it needs to process a Color Word entry.
Can't allocate NNN bytes for DEFAULT USER CLEARANCE.: The system cannot dynamically allocate the memory it needs to process the DEFAULT USER CLEARANCE.
Can't allocate NNN bytes for DEFAULT USER SENSITIVITY LABEL.: The system cannot dynamically allocate the memory it needs to process the DEFAULT USER SENSITIVITY LABEL.
DEFAULT USER CLEARANCE= XXX is not in canonical form. Is YYY what is intended?: This error occurs if the clearance specified, while understood, is not in canonical form. This additional canonicalization check ensures that no errors are made in specifying the clearance.
DEFAULT USER SENSITIVITY LABEL= XXX is not in canonical form. Is YYY what is intended?: This error occurs if a sensitivity label specified, while understood, is not in canonical form. This additional canonicalization check ensures that no errors are made in specifying the sensitivity label.
Duplicate DEFAULT USER CLEARANCE= ignored.: More than one DEFAULT USER CLEARANCE= option was encountered. All but the first are ignored.
Duplicate DEFAULT USER SENSITIVITY LABEL= ignored.: More than one DEFAULT USER SENSITIVITY LABEL= option was encountered. All but the first are ignored.
End of File not found where expected. Found instead: XXX.: The noted extraneous text was found when the end of label encodings file was expected.
End of File or LOCAL DEFINITIONS: not found. Found instead: XXX.: The noted extraneous text was found when the LOCAL DEFINITIONS: section or end of label encodings file was expected.
Found color XXX without associated label.: The color XXX was found, however it had no label or word associated with it.
Invalid color label XXX.: The label XXX cannot be parsed.
Invalid DEFAULT USER CLEARANCE XXX.: The DEFAULT USER CLEARANCE XXX cannot be parsed.
Invalid DEFAULT USER SENSITIVITY LABEL XXX.: The DEFAULT USER SENSITIVITY LABEL XXX cannot be parsed.
Label preceding XXX did not have a color specification.: A label or word was found without a matching color name.
Word XXX not found as a valid Sensitivity Label word.: The word XXX was not found as a valid word for a sensitivity label.

Warnings

Creation 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.

Notes

This 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.

SunOS 5.10 Last Revised 31 May 2006

sel_config(4)

NAME | Synopsis | Description | Attributes | See Also

NAME

sel_config – selection rules for copy, cut, paste, drag and drop operations

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 Confirmation

This type of entry specifies whether a confirmation window, the selection confirmer, displays. Each entry has the form:

relationship: confirmation

relationship identifies the result of comparing the selected data's source and destination windows' labels. There are three allowed values:

upgradesl: The source window's label is less than the destination window's label.
downgradesl: The source window's label is higher than the destination window's label.
disjointsl: The source and destination windows' labels are disjoint. Neither label dominates the other.

confirmation specifies whether to perform automatic confirmation. Allowed values are:

n: Use manual confirmation, that is, display the selection confirmer window. This is the default.
y: Use automatic confirmation, that is, do not display the selection confirmer window.

Automatic Reply

A 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:

autoreply: value

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.

replytype: TARGETS
replytype: Pixel Sets
replytype: LENGTH
replytype: Type Of Monitor

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.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtsu

tnrhdb(4)

NAME

tnrhdb – trusted network remote-host database

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.

IP-address

This field is the IP address of the host or network that has the security properties that are specified by the template that is defined in the tnrhtp(4) database.

An entry can be a host address, for example, 10.100.100.201 or fe80\:\:9\:20ff\:fea0\:21f7. Or an entry can be an IPv4 or IPv6 subnet address.

An IPv4 subnet entry can take the form of a subnet address with an explicit prefix length (10.100.128.0/17) or the form of a subnet address with trailing zero octets that imply a prefix length (10.100.0.0).

An IPv6 subnet entry must take the form of a subnet address with a prefix length (fe80\:\:/10). See NOTES for the use of the backslash in tnrhdb entries.

When IPv4 subnet entries are specified by using the implied prefix length format, the actual prefix length will take the value 0, 8, 16, or 24 when there are 4, 3, 2, or 1 trailing zero octets, respectively. An entry with a non-zero value in the final octet is interpreted as a host address and implies a prefix length of 32. See EXAMPLES for sample IPv4 entries.

template

This value must be a valid template name in the tnrhtp database. For information on the security attributes, see tnrhtp(4).

More than one IP address can use the same template. If this database is modified while the network is up, the changes do not take effect until after tnctl(1M) is used to update the remote-host entries. Administrators are allowed to add new entries and modify existing entries while the network is up. The template field cannot contain any white spaces.

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.

Examples

Example 1 Sample IPv4 Entries

IPv4 Entry      Host Address    Implied Prefix
                or Wildcard?    Length
==============  ==============  ==============
0.0.0.0         Wildcard        0
10.0.0.0        Wildcard        8
10.100.0.0      Wildcard        16
10.0.100.0      Wildcard        24
10.0.100.100    Host Address    32

Example 2 Sample tnrhdb File

The 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.

 #
 # Assume that templates default-template, cipso, public,
 # internal, needtoknow, and secret are defined in the
 # tnrhtp database.
 #
 # the first two entries are addresses of the IPv4 and
 # IPv6 loopback interfaces
   127.0.0.1:cipso
   \:\:1:cipso
   10.0.0.1:cipso
   192.168.120.6:public
   192.168.120.0:internal
   192.168.120.7:needtoknow
   192.168.121.0:secret
   0.0.0.0:default-template
   0\:\:0/0:default-template
   fe80\:\:a00\:20ff\:fea0\:21f7:cipso

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtsg
Stability	Project Private

Files

/etc/security/tsol/tnrhdb: Trusted network remote-host database

Warnings

Changing a template while the network is up can change the security view of an undetermined number of hosts.

Notes

The 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.

SunOS 5.10 Last Revised 16 Jun 2006

tnrhtp(4)

NAME

tnrhtp – trusted network remote-host templates

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 (;):

template_name:attr

A pound sign (#) as the first character of a line indicates a comment line, which is ignored.

template_name

Is a character string that names the template that is being defined. The string is case-sensitive. Only the first 31 characters of string are read and interpreted. You can use any printable character in template_name except for field delimiters, newline, or the comment character.

attr

Is a list of semicolon (;) separated key=value pairs that describe the attributes of the template. All keys are mandatory unless otherwise indicated, even if no value other than none is set. The following keys are currently interpreted by the system.

host_type

Takes one of two defined values, unlabeled and cipso. The cipso host type is for hosts that use CIPSO (Common IP Security Options - Tag Type 1 only) to label packets.

def_label

Defines the default attributes to be applied to incoming data from remote hosts that do not support these attributes. This key is valid for the unlabeled host type only.

doi

Is the domain of interpretation. In the case of the unlabeled host type, this is the domain of interpretation for the def_label.

The domain of interpretation defines the set of rules for translating between the external or internal representation of the security attributes and their network representation. When systems that are configured with Trusted Extensions software have the same doi, they share that set of rules. In the case of the unlabeled host type, these systems also share the same interpretation for the default attributes that are assigned to the unlabeled templates that have that same doi.

min_sl, max_sl

Specifies the label accreditation range for the remote hosts that use this template. All labels are specified in a shortened hexadecimal format, except for the administrative labels ADMIN_LOW and ADMIN_HIGH.

For gateway systems, min_sl and max_sl define the default range for forwarding labeled packets. The label range for routes is typically set by using a route(1M) subcommand with the -secattr option. When the label range for routes is not specified, the min_sl to max_sl range in the tnrhtp database is used.

sl_set

Specifies the security label set which is allowed for the remote hosts that use this template. For gateway systems, the labels in sl_set are used for forwarding labeled packets. sl_set is optional. The maximum number of labels in a set is 4.

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.

Examples

Example 1 Unlabeled Host Entries

For 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.

# Sample ADMIN_LOW template entry for machines or networks.
# Note that the doi field is required.
#
admin_low:host_type=unlabeled;\
def_label=ADMIN_LOW;\
min_sl=ADMIN_LOW;\
max_sl=ADMIN_HIGH;\
doi=1;

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.

# Sample PUBLIC template entry
# based on the sample label_encodings file.
#
public:host_type=unlabeled;\
def_label=0x0002-08-08;\
min_sl=ADMIN_LOW;\
max_sl=ADMIN_HIGH;\
doi=1;

Example 2 CIPSO Host Entry

# Labeled host template
#
h1_allzones:host_type=cipso;\
min_sl=ADMIN_LOW;\
max_sl=ADMIN_HIGH;\
doi=1;

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtsg
Stability	Project Private

Files

/etc/security/tsol/tnrhtp: Trusted network remote-host templates

Warnings

Changing 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.

SunOS 5.10 Last Revised 16 Jun 2006

tnzonecfg(4)

NAME

tnzonecfg – trusted network zone configuration database

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 (:).

zone-name:label:network-policy:zone-mlp-list:shared-mlp-list
global:ADMIN_LOW:1:6000-6003/tcp:6000-6003/tcp

A pound sign (#) as the first character of a line indicates a comment line, which is ignored.

zone-name

Is the name for the zone. This name is used when the zone is configured. See zonecfg(1M), under the -z zonename option, for the constraints on zone names.

label

Is the label for the zone. This field is used to label the zone when the zone is booted. The label can be in shortened hexadecimal format or in text format. The labels are defined in the label_encodings file. Each zone must have a unique label.

network-policy

Is the policy for handling all non-transport traffic. This field is used to decide for non-MLP traffic if an exact zone label is required or if a label range match is allowed. The value 0 indicates strict zone label matching for inbound packets. If this field is set to 1, the receiving host accepts packets within the host's accreditation range.

ICMP packets that are received on the global zone IP address are accepted based on the label range of the global zone's tnrhtp entry if the global zone's network-policy field is set to 1. When this field is set to 0 for a zone, the zone will not respond to an ICMP echo request from a host with a different label.

zone-mlp-list

Is the multilevel port configuration entry for a zone on the IP addresses that belong to that zone. zone-mlp-list is a list of semicolon-separated MLP configuration entries. Each MLP configuration entry is specified by port/protocol or port-range/protocol. For example, 6001-6003/tcp means that tcp ports 6001, 6002, and 6003 are all MLPs.

An MLP is used to provide multilevel service in the global zone as well as in non-global zones. As an example of how a non-global zone can use an MLP, consider setting up two labeled zones, internal and public. The internal zone can access company networks; the public zone can access public internet but not the company's internal networks. For safe browsing, when a user in the internal zone wants to browse the Internet, the internal zone browser forwards the URL to the public zone, and the web content is then displayed in a public zone web browser. That way, if the download in public zone compromises the web browser, it cannot affect the company's internal network. To set this up, tcp port 8080 in the public zone is an MLP (8080/tcp), and the tnrhtp template for the public zone has a label range from PUBLIC to INTERNAL.

shared-mlp-list

Is the multilevel port configuration entry for shared IP addresses. shared-mlp-list is a list of semicolon-separated MLP configuration entries. Each MLP configuration entry is specified by port/protocol. Other zones do not have access to this port/protocol on shared interfaces. It is a configuration error to specify the same port/protocol in the shared-mlp-list field of more than one zone.

A shared IP address can reduce the total number of IP addresses that are needed on the system, especially when configuring a large number of zones. If network traffic is received on a shared interface, on a port that is specified in a zone's shared-mlp-list, the traffic cannot be received by other zones.

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.

Examples

Example 1 Sample Zone Configuration Entries

In 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.

#
    # Sample global zone configuration file
    #
    # Multilevel Port (MLP) specification:
    #
    #       MLP                     PURPOSE
    #       ---                     -------
    #       111                     Port Mapper
    #       2049                    NFSv4 server
    #       6000-6003               Multilevel Desktop
    #
    global:ADMIN_LOW:1:111/tcp;111/udp;2049/tcp;6000-6003/tcp:6000-6003/tcp
    public:PUBLIC:0:8080/tcp:
    internal:0x0004-08-48:0::
    needtoknow:0x0004-08-68:0::
    restricted:0x0004-08-78:0::

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtsg
Stability	Project Private

Files

/etc/security/tsol/tnzonecfg: Trusted network zone configuration database

TrustedExtensionsPolicy(4)

NAME

TrustedExtensionsPolicy – configuration file for Trusted Extensions X Server Extension

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:

keyword{space|tab}value

where keyword can be one of the following:

atom: Label this atom ADMIN_LOW, so that XGetAtomName(3X11) succeeds.
property: Instantiate this property once. The default is to polyinstantiate a property.
selection: Polyinstantiate this selection. The default is to instantiate the selection once.
extension: Disable this extension.
privilege: Implicitly allow this window privilege on all clients.

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.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWxwts

Examples

The following entry in the TrustedExtensionsPolicy file polyinstantiates the Dtpad program:

selection Dtpad

If the entry is missing, or commented out, the Dtpad program is instantiated once.

Similarly, the following entry instantiates the WM_ICON_SIZE property once:

property WM_ICON_SIZE

If the entry is missing, or commented out, the WM_ICON_SIZE property is polyinstantiated.

Files

/usr/X11/lib/X11/xserver/TrustedExtensionsPolicy: Configuration file for Trusted Extensions X Server Extension