dn6d.config(4M) DG/UX B2 Security R4.12MU02 dn6d.config(4M)
NAME
dn6d.config - configuration file for the Trusted IP daemon, dn6d
SYNOPSIS
/etc/tcb/dn6/dn6d.config
OVERVIEW
The Trusted IP daemon, dn6d, manages TCP/IP sessions (where a session
is any communication between two TCP/IP endpoints). The
configuration file, which is /etc/tcb/dn6/dn6d.config by default,
controls how dn6d decides which sessions to accept and which sessions
to reject. If a session is accepted, the configuration file also
specifies how to manage the attributes associated with the session.
In particular, the configuration file contains an ordered list of
rules. When dn6d receives a request for a session, the rules are
searched until a match for the request is found. A request can match
a rule based upon: directions (in, out, or forward), local/source
address, local/source port, remote/destination address,
remote/destination port, next hop address, incoming interface,
outgoing interface, and session type. (The session type specifies
whether attributes are to actually be transmitted between the two
endpoints.) If a request matches a rule, then the actions associated
with the rule determine whether to accept or reject the request. If
no matching rule is found for a request, the request is rejected.
For example, the following configuration file contains two rules:
not-him and default.
config = (
rule = (
not-him = (
directions = (in,out),
remote-hosts = (his-machine),
actions = (reject,log)
),
default = (
actions = (accept)
)
)
)
The first rule, not-him, says to reject and log all requests
generated by both incoming packets from and outgoing packets to his-
machine; the packets are assumed to be unlabeled (i.e. contain no
security attributes). The second rule, default, says to accept all
other unlabeled requests. The absence of a directions and remote-
hosts field in the default rule means to match any direction and
remote address. Note that the names of the rules, not-him and
default, can be any name; however, the rule's name should be
descriptive of what the rule does.
See the Rules section below for a complete description of each field
of a rule.
DESCRIPTION
The general format of the dn6d.config file is of the form name =
value where name identifies some component of the configuration and
value is the value for that component. The value is a list, name, or
number. Each list is delimited by parentheses and the elements of a
list are separated by commas. Each element of a list is then a name,
a number, or of the form name = value.
For example, consider the previous configuration file again.
config = (
rule = (
not-him = (
directions = (in,out),
remote-hosts = (his-machine),
actions = (reject,log)
),
default = (
actions = (accept)
)
)
)
The top-level config component has as its value a list of one
element: rule; rule has as its value a list of two elements: not-him
and default; not-him has as its value a list of two elements: remote-
hosts and actions; etc.
The top-level format of the configuration file is as follows:
config =
(
param = (Parameters),
local-names = (Local Names),
alias = (Aliases),
domain = (Domains),
rule = (Rules)
)
Note that the ordering of the top-level components is significant.
For example, since a rule can reference an alias name and a domain
name, both the alias and domain sections should precede the rule
section.
Directives are also allowed anywhere in the configuration file. Each
directive is of the form <init:command:command line> where command
line is a shell command line which is passed to popen(). The output
resulting from the execution of the command line is then read as if
the configuration file contained this output.
A comment may be specified as a "C" style comment, which starts with
a "/*" and continues until it reaches "*/".
Attribute Tokens
The valid attribute tokens in the configuration file are: MAC-label,
MAC-tuple, info-label (information label), CAP (effective
capabilities), required-CAP (required capabilities), ACL, default-
ACL, credentials (UID, GID, etc), auth-info, audit-mask, auth-ID, and
PID.
A base attribute is an attribute which cannot be decomposed. For
example, hierarchy and category are base attributes which compose a
MAC-label attribute, while an auth-ID is both an attribute and a base
attribute since it cannot be decomposed. The valid base attribute
tokens are: hierarchy, category, capability (the base attribute used
to compose a CAP or a required-CAP), auth-info, audit-mask, auth-ID,
PID (process identifier), and UID (user identifier).
As described above by the top-level format, the major components of
the configuration file are parameters, local names, aliases, domains,
and rules. Each of these components is described in detail in the
remaining sections.
Parameters
Parameters control various aspects of Trusted IP. The parameter list
consists of parameter names and their values. For example, the
following parameter list denotes the default values for the log-level
and engine-state parameters.
param = (
log-level = normal,
engine-state = normal
)
Each parameter and its possible values and meanings is described
below.
log-level
The value of the log-level parameter controls the amount of
logging information written to the file /etc/tcb/dn6/dn6d.log
by dn6d. The valid values of log-level are as follows and are
cumulative with regard to the amount of information logged:
none No logging.
normal Log abnormal daemon errors such as ENOMEM; also log
when the daemon is started and restarted.
devel Development mode in which all rejections due to an
unknown remote host error are also concisely logged.
setup System setup mode in which all accepts and rejects are
logged concisely.
debug Debug mode in which additional information specifying
why a request was rejected is also logged.
all Additional attribute mapping information is logged.
engine-state
The value of the engine-state parameter is used to decide
whether to accept or reject network session requests. The
valid values are:
normal Use the rules to make decisions regarding session
requests.
accept-all
Accept all session requests without using the rules.
reject-all
Reject all session requests without using the rules.
Local Names
The local names consist of a list of names and the corresponding
integer value for each base attribute. Local names are used in the
domain section to map local names to network names and vice-versa.
For example, for the UID base attribute the following list maps the
user identifier nobody to the value 1 and the user identifier
somebody to the value 2.
local-names = (
UID = (
nobody = 1,
somebody = 2
)
)
Each local name and value must be unique with respect to all other
names and values for the same base attribute.
Aliases
The alias section provides a mechanism for associating an alias with
a group of hosts or services/ports. Once an alias is defined, it can
be referenced by a rule as described in the Rules section. There are
two types of aliases which can be referenced by a rule: host group
and service group aliases.
Host Group Aliases
A host group alias allows you to associate a single name with
a group of hosts. For example, you might want to deny access
to any host in the NoAccessHosts host group, and both log and
deny access to any host in the RealBadHosts host group.
alias = (
host-group = (
NoAccessHosts = (
1.2.3.4,
1.2.5.0:0xffffff00,
$RealBadHosts
)
RealBadHosts = ()
)
)
The host-group keyword marks the beginning of the host group aliases.
The elements of a host group can be a simple IP address, an IP
address followed by a subnet mask, or another host group alias
prefixed by the $ character. Note also that a host group can be
empty. Therefore, the NoAccessHosts host group contains 1.2.3.4 and
all hosts on the 1.2.5 subnet.
Service Group Aliases
A service group alias allows you to associate a single name
with a group of services or ports. For example, the
ServicesToReject service group could be referenced by a rule
so that all services in this group are rejected on the system.
alias = (
service-group = (
ServicesToReject = (
$Telnet,
$NonReservedPorts
),
Telnet = (
TCP/23
),
NonReservedPorts = (
TCP/1025 - 65535,
UDP/1025 - 65535
)
)
)
The service-group keyword marks the beginning of the service group
aliases. The elements of a service group can be a protocol followed
by a port or port range, or a service group alias prefixed by the $
character. The possible protocols are: TCP,UDP,raw-IP, or IP. The
IP protocol includes any protocol other than TCP, UDP, or raw-IP.
Domains
A single domain defines how to map attributes from local to network
representation, and vice-versa. Each domain in the domain list is of
the following form:
domain-name = (
DOI = doi value,
weight-factor = weight value,
representations = representation list,
formats = format list,
mappings = mappings list
)
The remainder of this section describes each field of a domain
definition.
DOI The doi value is an unsigned 32-bit integer which is
transmitted on the network to denote a particular domain.
weight-factor
The weight value is an unsigned 8-bit integer which rates the
ability of the local system to map attribute values to and
from the network representation associated with this domain;
the greater the weight value, the more precise the ability of
the local system to perform the mapping.
representations
The representation list contains a list of valid
representations for each attribute. Currently, the only
supported representation is binary. For example, the
following representation list denotes that a binary
representation is valid for the MAC-label and auth-ID
attributes.
representations = (
MAC-label = (binary),
auth-ID = (binary)
)
formats
The format list contains a list of formats for each attribute.
Associated with each format is an unsigned 8-bit integer which
is the CIPSO tag type value used in the network packet to
denote the associated attribute and format. The possible
formats for the MAC-label and info-label attributes are bit-
vector (a bit for each possible category), enumeration (an
unsigned 16-bit integer for each category present), and range
(a sequence of unsigned 16-bit integer pairs for each range of
categories).
The only possible format for all other attributes is standard.
For example, the following format list says that a MAC-label
can be in bit-vector format (denoted by a CIPSO tag type of 1)
or in enumeration format (denoted by a CIPSO tag type of 2)
but not in range format, and that the auth-ID standard format
is denoted by a CIPSO tag type of 130.
formats = (
MAC-label = ( bit-vector = 1, enumeration = 2 ),
auth-ID = ( standard = 130 )
)
Note that if multiple formats are in the list for a particular
attribute, the most concise format is chosen to transmit a
packet.
mappings
The mappings list is used to convert base attributes from
local to network representation, and vice-versa. Therefore,
there is an element in the list for each base attribute which
has the following format:
base-attribute = (
modes = (modes list),
network-names = (network-names list),
network-from-local = (network-from-local list),
local-from-network = (local-from-network list)
)
All of the fields above are described in the following
sections.
modes The modes list is used to determine how to map between
local and network representations and consists of one
or more of the following modes.
direct Local and network representation are identical,
so no conversion is necessary; therefore,
simply perform a direct copy. Note that this
mode takes precedence over all other map modes.
one-to-one
Converting to local from network representation
is the inverse operation of converting to
network from local. If this mode is used, the
network-from-local mappings are used in reverse
to map to local from network; therefore, the
local-from-network values are not referenced.
exact Exact mode only applies to the category
attribute. Exact mode requires that there be,
for a particular mapping request, sufficient
information in the remaining sections of the
mappings list to convert each category to the
target representation. If exact mode is set
and there is a category in the request which
can't be mapped, then an error occurs and the
request is denied. If exact mode is not set
and there is a category in the request which
can't be mapped, then the category is ignored;
that is, no categories are set in the target
representation corresponding to the
unrecognized category.
network-names
The network-names list is a mapping of network names to
network integer values. The format of the network-
names list is similar to that of the local names list
contained in the top-level config list. Each element
of the network name list is of the form name = integer.
For example, for the hierarchy base attribute, the
following list maps "TOP SECRET" to the value 10 and
UNCLASSIFIED to the value 1.
network-names = (
"TOP SECRET" = 10,
UNCLASSIFIED = 1
)
Each network name and value must be unique with respect
to all other names and values for the same domain and
base attribute.
network-from-local
Each element of the network-from-local list maps a
local name to a network name, and therefore indirectly
maps a local value to network value. If one-to-one
mode is set, each element also maps a network
name/value to a local name/value. For example, for the
hierarchy base attribute, the following list maps the
local name RESTRICTED to the network name "TOP SECRET"
and the local name UNCLASSIFIED to the network name
UNCLASSIFIED.
network-from-local = (
"TOP SECRET" = RESTRICTED,
UNCLASSIFIED = UNCLASSIFIED
)
Note that a network and a local name can be the same;
however, this does not necessarily imply that the
corresponding values are equal.
local-from-network
If one-to-one mode is set, the local-from-network list
is not used. Otherwise, each element of the local-
from-network list maps a network name to a local name,
and therefore indirectly maps a network value to
network value. For example, for the category base
attribute, the following list maps the network name
NATO to the local name FINANCE and the network name
PENTAGON to the network name PERSONNEL.
local-from-network = (
FINANCE = NATO,
PERSONNEL = PENTAGON
)
Rules
The rule list is an ordered list which is used to determine how to
handle network session requests. When dn6d receives a request for a
session, the rules are searched until a match is found for the
request. A request can match a rule based upon: directions (in, out,
or forward), local/source address, local/source port,
remote/destination address, remote/destination port, next hop
address, incoming interface, outgoing interface, and session type.
The information contained in the first matching rule is used to
determine whether to accept or reject the request, whether or not to
log any information pertaining to the request, and how to manage the
request if it is accepted. Therefore, each rule contains matching
information, actions to be performed if a match occurs, and
management information to be used if one of the actions is to accept
the request.
In particular, each rule is of one of the following two formats. The
first format is used to match requests for local sessions, which are
sessions with at least one local endpoint. The second format is used
to match requests for forwarded sessions, which are sessions between
two remote endpoints (i.e. a request to forward a packet). Note that
the only difference between the two formats is that local and remote
for local sessions is replaced by src (source) and dst (destination)
for forwarded sessions.
rule-name = (
directions = (in,out),
local-hosts = hosts,
remote-hosts = hosts,
nxt-hop-hosts = hosts,
in-interfaces = hosts,
out-interfaces = hosts,
local-services = services,
remote-services = services,
session-types = session types,
actions = actions,
network-attributes = attributes,
default-attributes = attribute values,
object-attributes = attribute values
)
rule-name = (
directions = (forward),
src-hosts = hosts,
dst-hosts = hosts,
nxt-hop-hosts = hosts,
in-interfaces = hosts,
out-interfaces = hosts,
src-services = services,
dst-services = services,
session-types = session types,
actions = actions,
network-attributes = attributes,
default-attributes = attribute values,
object-attributes = attribute values
)
A rule may contain only a subset of these fields for either rule
format. For example, if you want to match a request regardless of
what the incoming or outgoing interfaces are, then the rule need not
contain the in-interfaces or out-interfaces fields.
The remainder of this section describes each of the possible fields
for a rule.
directions
A request can be generated by one of three possible
events: a packet destined for the local system is
received (in), a packet is transmitted by the local
system (out), or a packet is received by the local
system and is being forwarded to another system
(forward). The value of the directions field defines
which of these three types of events/requests to match.
Typically, the value will be either (in,out) for
sessions involving packets being sent from or to the
local system, or forward for sessions being forwarded
through the local system.
local-hosts
For local sessions only. If local-hosts is
present, the local address from the request
must be in the associated hosts in order for
the request to match the rule. The local
address of the request is defined to be the
source address for an outgoing packet or the
destination address for an incoming packet. If
local-hosts is absent, the local address from
the request automatically matches the rule.
The associated hosts (as found in several of
the fields for a rule) is a list of hostnames
and IP addresses. Each hostname or IP address
can be followed by :address-mask which means to
match on the part of the address which
corresponds to a 1 in address-mask. For
example, the following local-hosts field of a
rule has as it's value a list of hosts
containing my-machine and any IP address
beginning with 128.123.4.
local-hosts = ( my-machine, 128.123.4.0:0xffffff00 )
remote-hosts
For local sessions only. If remote-hosts is
present, the remote address from the request
must be in the associated hosts in order for
the request to match the rule. The remote
address of the request is defined to be the
destination address for an outgoing packet or
the source address for an incoming packet. If
remote-hosts is absent, the remote address from
the request automatically matches the rule.
See local-hosts above for a description of the
value of hosts.
src-hosts
For forwarded sessions only. If src-hosts is
present, the source address from the request
must be in the associated hosts in order for
the request to match the rule. If src-hosts is
absent, the source address from the request
automatically matches the rule.
See local-hosts above for a description of the
value of hosts.
dst-hosts
For forwarded sessions only. If dst-hosts is
present, the destination address from the
request must be in the associated hosts in
order for the request to match the rule. If
dst-hosts is absent, the destination address
from the request automatically matches the
rule.
See local-hosts above for a description of the
value of hosts.
nxt-hop-hosts
The next hop host is defined to be the next
host to receive the packet in route to the
destination address. If nxt-hop-hosts is
present, the next hop host for the request must
be in the associated hosts in order for the
request to match the rule. If nxt-hop-hosts is
absent, the next hop host from the request
automatically matches the rule.
See local-hosts above for a description of the
value of hosts.
in-interfaces
If in-interfaces is present, the IP address of
the incoming interface must be in the
associated hosts in order for the request to
match the rule. If in-interfaces is absent,
the incoming interface from the request
automatically matches the rule. Note that this
field is useful to detect a packet which has an
incorrect (spoof) source address.
See local-hosts above for a description of the
value of hosts.
out-interfaces
If out-interfaces is present, the IP address of
the outgoing interface must be in the
associated hosts in order for the request to
match the rule. If out-interfaces is absent,
the outgoing interface from the request
automatically matches the rule.
See local-hosts above for a description of the
value of hosts.
in-interfaces
If in-interfaces is present, the IP address of
the incoming interface must be in the
associated hosts in order for the request to
match the rule. If in-interfaces is absent,
the incoming interface from the request
automatically matches the rule.
See local-hosts above for a description of the
value of hosts.
local-services
For local sessions only. If local-services is
present, the local port from the request must
be in the associated services in order for the
request to match the rule. The local port of
the request is defined to be the source port
for an outgoing packet or the destination port
for an incoming packet. If local-services is
absent, the local port from the request
automatically matches the rule.
The associated services (as found in several of
the fields for a rule) is a list of service or
port ranges. Each service or port range is of
the form {TCP|UDP|raw-IP} f4/min [ - max ],
where min and max are service names or port
numbers. For example, the following local-
services field of a rule contains telnet and
all reserved UDP ports.
local-services = ( TCP/"telnet", UDP/0-1023 )
remote-services
For local sessions only. If remote-services is
present, the remote port from the request must
be in the associated services in order for the
request to match the rule. The remote port of
the request is defined to be the destination
port for an outgoing packet or the source port
for an incoming packet. If remote-services is
absent, the remote port from the request
automatically matches the rule.
See local-services above for a description of
the value of services.
src-services
For forwarded sessions only. If src-services
is present, the source port from the request
must be in the associated services in order for
the request to match the rule. If src-services
is absent, the source port from the request
automatically matches the rule.
See local-services above for a description of
the value of services.
dst-services
For forwarded sessions only. If dst-services
is present, the destination port from the
request must be in the associated services in
order for the request to match the rule. If
dst-services is absent, the destination port
from the request automatically matches the
rule.
See local-services above for a description of
the value of services.
session-types
In order for a network session request to match
a rule, the session type in the request must be
one of the session types. The valid session
types are as follows.
unlabeled
No attributes are to be transmitted
between the local/source and
remote/destination endpoint.
CIPSO:domain-name
Attributes are to be transmitted between
the local/source and remote/destination
endpoint in CIPSO format and are in the
network representation defined by the
domain domain-name.
For example, the following session types denote
that a network session request matches if it
contains attributes in CIPSO format with a DOI
value equivalent to that of the domain
DGdomain, or if it contains no attributes.
session-types = ( CIPSO:DGdomain, unlabeled )
For outgoing network session requests, the
current session type may be unknown if the host
corresponding to the destination IP address has
not yet been communicated with. In this case,
the first session type in the list is always
matched. In the above example, CIPSO format in
the DGdomain is used to transmit packets for
the session.
actions
The actions specify what actions are to be
performed if a network session request matches
all of the above fields of a rule. The
possible actions are accept and reject (which
are mutually exclusive), and log (which causes
information from a request to be logged
according to the value of the log-level
parameter).
For example, the following actions associated
with a rule specify that, should a request
match the rule, then the request should be
accepted and logged according to the value of
the log-level parameter.
actions = ( accept, log )
network-attributes
The attributes associated with the network-
attributes field specify which attributes are
actually required to be transmitted between the
two endpoints of the session. For each
attribute which is supported by the local host
but which is not one of the network-attributes,
a default value for the attribute must be
provided through the default-attributes field
as described below.
The associated attributes is a list of
attribute names. For example, the following
network-attributes field of a rule requires
that the MAC-label and auth-ID attributes be
transmitted between the two endpoints of the
session.
network-attributes = ( MAC-label, auth-ID )
If the local host supports the MAC-label, auth-
ID, and CAP attributes, then since the CAP
attribute is not transmitted between the two
endpoints, a default CAP value must be
provided.
default-attributes
The attribute values associated with the
default-attributes field specify the default
attribute values for the session. Default
attribute values are used to assign an
attribute value to an unlabeled incoming packet
or to insert an attribute value into an
outgoing packet for which there is no local
value.
The associated attribute-values is a list of
attributes and their associated values. The
value can be defined in the local names section
or defined elsewhere on the system. For
example, the following default-attributes field
has a MAC-label value of SESSIONLO (defined by
the MAC alias mechanism) and a UID value of
nobody (defined in the local-names section).
default-attributes = ( MAC-label = SESSIONLO, UID = nobody )
object-attributes
The attribute values associated with the
object-attributes field specify the attributes
associated with the rule as an object. Access
checks are then made to make sure that an
incoming or outgoing packet (acting as a
subject) can write to the rule object.
For example, the following limits MAC-label
values to be between ADMINLO and ADMINHI, and
the user must have the DGCAPADMINNET
capability.
object-attributes = (
MAC-tuple = "-L ADMINLO -H ADMINHI",
required-CAP = "DGCAPADMINNET"
)
See default-attributes above for a description
of the value of attribute-values.
FILES
/etc/tcb/dn6/dn6d.config
SEE ALSO
dn6d(1M)
Licensed material--property of copyright holder(s)