| Skip Navigation Links | |
| Exit Print View | |
|
man pages section 1M: System Administration Commands Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
man pages section 1M: System Administration Commands Oracle Solaris 11.1 Information Library |
- configure trusted networking properties
tncfg [-t template] [-e|-S [files|ldap]] [subcommand]
tncfg [-t template] [-e|-S [files|ldap]] -f command_file
tncfg -z zone [-e] [subcommand]
tncfg -z zone [-e] -f command_file
tncfg help
The tncfg utility creates, modifies, and displays the configuration of various networking properties related to Trusted Extensions. The command requires that the SMF service, svc:/system/labeld is enabled. It can be executed only in the global zone.
A template is a collection of network security properties that define the rules for labeling packets received from remote hosts. Four host types are supported: cipso, unlabeled, adaptive, and netif. Each template must specify one of these four host types. Hosts that are trusted to specify their own labels are assigned to cipso templates. Otherwise, hosts can be assigned to unlabeled or adaptive templates. When using an unlabeled template, a single default label must be specified. When using an adaptive template, the default label is not specified. Instead, the label is derived from the default label of the IP interface on which the packet is received.
The labeling properties of an IP interface are specified using the netif template type. For netif templates, the host address properties correspond to local interfaces, instead of remote hosts. These templates should be used when separate single-level networks are connected to corresponding labeled zones. Therefore, the default label of a netif template must equal the label of every zone with a network interface whose IP address matches a host address in that template. Futhermore, the lower-link corresponding to any such matching zone interfaces can only be assigned to other zones sharing the same label.
Hosts can be specified using hostnames, IP addresses, or masks. When masks are used, a prefix length that specifies how many bits are required for a match must be appended . Hosts cannot be assigned to more than one template. When masks are used, the entry with the longest matching prefix is used to associate a host with a template. Packets from hosts without a matching template are dropped.
Each template must include an upper and lower bound specifying the accreditation range of accepted labels. Additionally, up to four auxiliary labels can be specified to enumerate labels outside of this range. Services bound to multilevel ports can accept packets from hosts whose labels are within the accreditation range, or match one of the auxiliary labels.
Normally, the template settings and their corresponding hosts are persistently maintained in local files or by means of an LDAP directory, depending on the -S option. These settings are automatically loaded into kernel memory when the user commits the updates. If the -e (ephemeral) option is specified, only the current in-memory properties are displayed and updated. However, the list of hosts associated with an in-memory template is generally incomplete. To view the matching template for a specific host, use the get subcommand.
By default, an unlabeled template, admin_low, is installed with a default label of ADMIN_LOW, and two mask entries matching any IPv4 or IPv6 address, so that the global zone is initially able to contact any unlabeled hosts. It is recommended to remove these two mask entries once your network security policy is established. An additional template, cipso, is installed with no matching hosts. By default all local IP addresses are implicitly associated with this template, but it is recommended that they should be explicitly added to this or a new cipso-type template.
Searches for template and host entries are resolved in the order specified by means of the name service configuration file, /etc/nsswitch.conf. The keywords, tnrhdb and tnrhtp, are used to specify the search order for hosts and templates, respectively. Both the files and ldap repositories are supported, but it is recommended to specify files first.
Creating or modifying a template requires the authorization solaris.label.network.manage, which is included in the Object Label Management rights profile.
Zones are isolated execution environments described in zones(5). Trusted Extensions requires a zone brand called labeled to which special properties apply. Each labeled zone must have a unique label property at which it executes processes. This is also the label at which it will accept packets from remote hosts for services bound to single-level ports. Explicit multilevel port can also be specified. Services with the privilege net_bindmlp can bind to these ports, and accept packets within the accreditation range or the auxiliary label set associated with the remote host.
Non-global zones must be configured using zonecfg(1M) prior to configuring these properties. In general, updates to each zone's properties, including the global zone, are applied when it is booted. However, the multilevel port properties of running zones are reloaded into kernel memory when updates are committed. If the -e (ephemeral) option is specified, the zone must be in the ready or running state, and only its multilevel port properties can be updated.
Creating or modifying a zone's trusted networking properties requires the authorization solaris.label.zone.manage, which is included in the Object Label Management rights profile.
The set of valid properties depends on whether the -t or -z option was used. The two sets are referred to as the template context and the zone context.
Only a single property value can be specified at a time. Values containing white space must be quoted. An equal sign is required between the property and its value.
The values that can be specified in the template context properties are described below.
The initial value for the name is specified using -t option using the command line. If the name is changed, the current template properties are applied to the newly named template. In this way an existing template can be cloned for subsequent editing. However, to avoid conflicts, the host entries from the initial template are not copied to the new template. The specified name must not match an existing template.
When the unlabeled or netif host types are used, the value specified using the the def_label property is implicitly applied to the received packets. The cipso host type is used for hosts that are trusted to explicitly label their packets. The adaptive host type is used for hosts whose label is derived from the interface on which their packets are received. The default is unlabeled.
The default label assigned to IP packets that are not explicitly labeled by means of cipso or IPsec.
A positive integer specifying the Domain of Interpretation for the binary representation of the labels. The default is 1.
The minimum label in the accreditation range for IP packets that are accepted by multilevel services.
The maximum label in the accreditation range for IP packets that are accepted by multilevel services.
Additional labels, outside of the accreditation range, for IP packets that are accepted by multilevel services. Up to four labels may be specified, using the add subcommand repetitively.
A hostname or an IP address to which the template properties apply. For IP addresses, both IPv4 and IPv6 formats can be used, followed by an optional slash and prefix length specifying the number of bits to match again IP addresses. The IPv4 address 0.0.0.0 has an implied prefix length of zero, and matches any IPv4 address. Multiple host values can be specified, using the add subcommand repetitively. There is no specific limit.
The values that may be specified in the zone context properties are described below.
The name of the zone, which must have previously been configured using zonecfg(1M). The initial value for the name is specified using -z option on the command line. If the name is changed, the current zone properties are applied to the newly named zone. In this way an existing template can be cloned for subsequent editing. However, to avoid conflicts, the initial label value is not copied to the new zone configuration. The specified name must correspond to an existing zone without a trusted networking configuration.
Although multiple zones can share a single sensitivity label, at most one zone for each label can have its primary property set to yes. This indicates that the zone should be selected as the target of any operation that specifies only a label instead of a zone name, such as choosing the label of a desktop workspace, sharing an IP address, or relabeling a file.
By default all zones are created with their primary property set to yes, unless an existing primary zone with a matching label already exists. Primary zones are not required for any label except admin_low, which is reserved for the global zone. When primary is set to no, the desktop packages are not installed by default.
The sensitivity label of the zone. It must be unique if the zone's primary property is set to yes. Otherwise, if the session is interactive, the user is given the option to set the zone's primary property to no. The global zone value must be admin_low.
Specifies whether the zone responds to ping requests from hosts whose labels don't match the zone's label. The default is no.
A single port number, or a range of ports that privileged services can bind to and then accept requests from clients whose labels are with the accreditation range or the set of auxiliary labels specified in their matching templates. The port specification must be followed by a a protocol, either tcp or udp. This value applies to all interfaces that are private to the zone. Multiple mlp_private values can be specified, using the add subcommand repetitively. This is only limited by the number of available ports.
A single port number, or a range of ports that privileged services can bind to and then accept requests from clients whose labels are with the accreditation range or the set of auxiliary labels specified in their matching templates. The port specification must be followed by a protocol, either tcp or udp. This value applies to any all-zones interfaces, and must not overlap with the mlp_shared ports specifications for other zones. Multiple mlp_shared values can be specified, using the add subcommand repetitively. This is only limited by the number of available ports.
The following options are supported:
Specifies that the data is ephemeral, affecting only what is currently loaded into kernel memory.
Specifies the name of tncfg command file. command_file is a text file of tncfg subcommands, one per line.
Specifies the template name. If the named template does not exist, a new template is created. If neither -t nor -z is specified, the template context is assumed using cipso as the default template name.
The valid repositories are files and ldap. The repository specifies which name service will be updated. The default repository is files.
Specifies the zone name. The zone must have previously been configured by means of zonecfg(1M).
Subcommands can be provided on the command line or interactively. Multiple subcommands, separated by semicolons, can be specified on the command line by enclosing the entire set in quotation marks. The lack of subcommands implies an interactive session, during which auto-completion of subcommands can be invoked using the tab key.
The add, clear, and remove subcommands are used for properties that can accept multiple values. However, only one value can be specified at a time.
Subcommands which can result in destructive actions or loss of work have an -F option to force the action. If input is from a terminal device, the user is prompted when appropriate if such a subcommand is given without the -F option. Otherwise, the action is disallowed, with a diagnostic message written to standard error.
The following subcommands are supported:
Adds the specified value to the current property values. This subcommand can only be applied to properties that accept multiple values. Use the set subcommand for single-value properties.
Clears all of the values for the property. Only those properties that accept multiple assignments, using the add subcommand, can be cleared.
Commits the current configuration from memory to stable storage and into the kernel. The configuration must be committed for the changes to take effect. Until the in-memory configuration is committed, you can remove changes with the revert subcommand. The commit operation is attempted automatically upon completion of a tncfg session. Since a configuration must be correct to be committed, this operation automatically does a verify.
Deletes the specified template or zone configuration from the current name service.
Specify the -F option to force the action. If the deletion is allowed, its action is instantaneous and the session is terminated.
Displays configuration to standard output. Use the -f option to display the configuration to output-file. This option produces output in a form suitable for use in a command file.
Displays the template name corresponding to the specified host using the kernel's in-memory mapping.
Displays general help or help about a given topic.
Displays information about the current template or zone, or the specified property in a parseable format.
Lists the names of the templates or zones that have been configured.
Removes the specified value from the property. Only those properties that accept multiple assignments, using the add subcommand, can be removed.
Sets a given property name to the given value. Properties that can take multiple values are assigned using the add subcommand, instead of set.
Verifies the current configuration for correctness:
The required properties are specified;
the values are valid for each key word;
the user is authorized to specify the values.
Causes the configuration to revert to the last committed state. The -F option can be used to force the action.
Exits the tncfg session. A commit is automatically attempted if needed. You can also use an EOF character to exit tncfg. The -F option can be used to force the action.
Example 1 Using the info Subcommand
The command below displays the properties of a cipso template are displayed. The subcommand is specified on the command line.
example% tncfg -t cipso info
name=cipso
host_type=cipso
doi=1
min_label=ADMIN_LOW
max_label=ADMIN_LOW
host=10.5.233.74Example 2 Using the export Subcommand
The following example shows an interactive session that exports the configuration of a zone in a format the could be imported to another machine with an equivalent zone.
example% tncfg -t public tncfg:public> export set name=public set host_type=cipso set doi=1 set def_label="PUBLIC" set min_label="PUBLIC" set max_label="CONFIDENTIAL : NEED TO KNOW" add aux_label="SANDBOX PLAYGROUND" add host=myserver.oracle.com add host=10.5.0.0/16 tncfg:public> exit
Example 3 Assigning Properties to a Zone
In the following example, the public zone is configured to be a multi-level NFS server.
example% tncfg -z public
tncfg:public> info
name=public
label=PUBLIC
visible=no
tncfg:public> add mlp_private=111/tcp
tncfg:public> add mlp_private=111/ucp
tncfg:public> add mlp_private=2049/tcp
tncfg:public> commit
tncfg:public> exitSuccessful completion.
An error occurred.
/etc/security/tsol/tnrhtp
/etc/security/tsol/tnrhdb
/etc/security/tsol/tnzonecfg
See attributes(5) for descriptions of the following attributes:
|
The invocation and subcommands are committed. Output, except for the export and info subcommands, is Not-an-Interface.
tnctl(1M), tnd(1M), tninfo(1M), txzonemgr(1M), zonecfg(1M), nsswitch.conf(4), attributes(5), labels(5), zones(5)
The Labeled Zone Manager, txzonemgr(1M), is an alternative application for configuring Trusted Extensions. It invokes the tncfg command internally, and provides an interactive GUI-based user interface.
|