compartments(4)compartments(4)NAMEcompartments - HP-UX compartments files
DESCRIPTION
HP-UX compartments are defined by creating one or more ASCII files in
the directory. Only file names ending with are parsed for compartment
definitions. Collectively, these files define compartments and com‐
partment access rules for local system objects. System objects that
have compartment access controls defined include file system objects,
inter-process communication objects, and network objects.
The compartment specifications are pre-processed with the command
before parsing (see cpp(1)). You can use directives such as and C/C++
style comments to organize and document the rules files.
CONFIGURATION RULES SYNTAX
A compartment consists of a name and a set of rules. Compartments use
four kinds of configuration rules:
· file system rules,
· inter-process communication (IPC) rules,
· network rules, and
· miscellaneous rules.
Rules can be either subject-centric or object-centric. Subject-centric
rules control access by processes (subjects) in a compartment to
resources (objects) in other compartments. Object-centric rules con‐
trol access to resources (objects) in a compartment by processes (sub‐
jects) in other compartments.
Compartment definitions use the following format:
new_compartment_name
If the HP-UX ContainmentPlus product (version B.11.31.02 or later) is
installed on the system, compartment definitions use the following for‐
mat:
new_compartment_name
where the values are defined as follows:
Indicates that any process in this compartment can not change
its
compartment as a side-effect of the call, even
if the binary being executed has extended
security attributes indicating that the
process starts in a different compartment (see
exec(2)). For security purposes, the minimum
retained and minimum permitted privileges of
the binary are also ignored (and treated as
though both sets are empty sets).
Indicates that for all the processes in this compartment, the
required
mandatory access rules would be generated at
run time so that the process operations would
succeed. This is a development tool that
enables developers to identify all the
required mandatory access rules for the given
application by running it in a compartment
marked as
Indicates that this compartment shares the ownership of network
interfaces with default compartments such as,
the init compartment, and other compartments
that are marked as compartments. The owner‐
ship of network interfaces are typically spec‐
ified by network interface rules (see the fol‐
lowing section).
When a compartment is marked as a compartment,
all of the network interfaces that are config‐
ured to belong to this compartment are also
considered as belonging to the compartment and
all other compartments that are marked as com‐
partments. The compartment will be in favor
of using these network interfaces for network
communications, over using the other network
interfaces. When a compartment is marked as
compartment, it also shares the connectivities
through loopback interfaces with the compart‐
ment.
The keyword is valid only if the HP-UX Con‐
tainmentPlus product (version B.11.31.02 or
later) is installed on the system.
Indicates that no processes can be launched in this compartment
from
other compartments. Therefore, if the keyword
is specified for a compartment, then a process
cannot use routine to enter this compartment,
nor can it enter this compartment by executing
a binary file that is configured with the name
of this compartment as one of its extended
security attributes (see setfilexsec(1M)).
The keyword is valid only if the HP-UX Con‐
tainmentPlus product (version B.11.31.02 or
later) is installed on the system.
Designates that this is a compartment definition.
new_compartment_name
Specifies the name to be applied to the com‐
partment being defined. The name is case sen‐
sitive, except for the compartment, which is
case insensitive. It can contain only alpha
numeric characters, underscore and hyphen but
not any other special or space characters.
The total length of the compartment name can‐
not exceed 256 characters.
Encloses the new rules.
rules Set of rules defining the compartment. Each
rule appears on a line by itself.
Note that the compartment specification can be extended to include new
keywords in the future. HP strongly recommendeds that compartment
names begin with an uppercase character to avoid any future syntax
errors (for example, compartment instead of
If the HP-UX ContainmentPlus product (version B.11.31.02 or later) is
installed on the system, the keywords and can be specified in any
order.
File System Rules
File system rules govern access to the files and directories of the
file system. All file system rules are subject-centric.
File system rules use one of these two formats:
file_object
file_object
If the HP-UX ContainmentPlus product is installed on the system, the
file system rules using the following format are also supported:
file_object
where the values are defined as follows:
Sets the permissions allowed for processes in this compartment
to
access the file_object in the way specified.
Denies any access to the
file_object for any process in this compartment.
If specified, none of the other possible argu‐
ments can be used.
Indicates all permissions on
file_object. The parameter is an alias that
includes all parameters: and
Controls search access to the
file_object. The rule has an effect only if
file_object is a directory. It allows processes
in the compartment to perform lookup in the
directory. This access control is not inherited.
So even if a directory is searchable, any direc‐
tory underneath is not searchable unless it is
explicitly allowed.
Controls search and read access to the
file_object. The rule has an effect only if
file_object is a directory. It allows processes
in the compartment not only to lookup in the
directory (see the parameter), but also to list
contents of the directory. Same as the parame‐
ter, this access control is not inherited.
Therefore, even if a directory is searchable and
readable, any directory or file underneath it is
not searchable or readable unless it is explic‐
itly allowed.
The keyword is valid only if the HP-UX Contain‐
mentPlus product is installed on the system.
Controls read access to the
file_object. If the file_object is a file,
allows processes in this compartment to open the
file for reading. If the file_object is a direc‐
tory, allows processes in this compartment to
list and search the contents of this directory
(see the and parameters). This permission covers
the permission granted by the or parameter. But
unlike the or parameter, this access control is
inherited, so any file or directory under this
file_object can be read or listed.
Controls write access to the
file_object. If the file_object is a file,
allows processes in this compartment to open the
file for writing. This permission has no direct
effect if file_object represents a directory.
There is still an indirect effect as the access
control is inherited, so any file under this
file_object can be written to.
Controls create access to the
file_object. The rule has an effect only if
file_object is a directory. This access control
is inherited, so processes in this compartment
can create file objects anywhere under the speci‐
fied directory.
Controls delete access to the
file_object. The rule has an effect only if
file_object is a directory. This access control
is inherited, so processes in this compartment
can delete file objects anywhere under the speci‐
fied directory.
file_object Fully-qualified name of a file or directory.
This name is restricted in the following ways:
· The total length of the name of the file_object
cannot exceed bytes.
· Each component in the file_object name cannot
exceed bytes.
· There can be no more than 10 components in the
file_object name. Because one component must
be the name of the file or directory, there can
be no more than nine preceding components. For
example, the path has four components.
· The file_object is literal; that is, wild card
characters such as asterisk cannot be speci‐
fied.
· The file_object has no special or space charac‐
ters. All characters except slash dot dash
underscore and colon must be entered using the
notation where xx corresponds to the hexadeci‐
mal representation of the character. See
ascii(5) for translating an ASCII character to
its hexadecimal equivalent.
File system rules are based on the path name. One can specify rules
for an object that does not yet exist. In such a case, the rule
becomes operational when an object with that name is created. If a
file has two or more names (for example, multiple hardlinks), and the
two names have different rules for any compartment, command generates
warnings. In order to successfully create a hard link (using the new
name and the old name must have the same rules. As with discretionary
access control (DAC) methods, when a symbolic link is accessed, the
rule on the resolved file (not the link itself) is applied.
For example, when the directory is loopback mounted on any access to
objects under these directories using either name result in application
of the rule corresponding to the path beginning from but not from
When multiple file system rules are defined for the same pathname, the
rules will be aggregated. That is, the union of the permissions is
taken.
IPC Rules
IPC rules appear within a compartment definition and govern how pro‐
cesses in this compartment can access another compartment's IPC mecha‐
nisms and how processes in other compartments may access this compart‐
ment's IPC mechanisms. Since the default is to deny access, rules of
this type are only for allowing access. Rules of this type can be
either subject-centric or object-centric. Two formats are available
for IPC rules.
The first form of IPC rules controls process communication and uses the
following format:
compartment_name
compartment_name
If the HP-UX ContainmentPlus product (version B.11.31.02 or later) is
installed on the system, a new keyword is also supported and the first
form of IPC rules uses the following format:
compartment_name
compartment_name
where the values are defined as follows:
Allows processes in the
compartment_name compartment to access the speci‐
fied IPC mechanism in this compartment. This key‐
word specifies an object-centric rule.
Allows processes in this compartment to access the specified IPC
mechanism in compartment_name compartment. This
keyword specifies a subject-centric rule.
Applies to terminals (ptys and ttys) that are used to
communicate between processes. Note that these
rules are applied in addition to any file system
rules that control the path name representing the
terminal. Normally terminals do not have any com‐
partment until a process opens them. When a termi‐
nal without a compartment ID is opened, its com‐
partment ID is set to that of the process that
opened it. When all open file handles to the ter‐
minal are closed, the terminal's compartment ID is
unset.
Applies to named pipes (FIFOs) that are used to
communicate between processes. These rules are
applied in addition to any file system rules that
control the path name representing the named pipe.
Initially a FIFO has no compartment. When a
process opens the FIFO for the first time, its com‐
partment is set to that of the process. When all
processes close the FIFO, its compartment is unset.
Applies to UNIX domain sockets that are used to
communicate between processes. These rules are
applied in addition to any file system rules that
control the path name representing the socket. As
with FIFOs, initially a UNIX socket has no compart‐
ment. When a process opens the UNIX domain socket
for the first time, its compartment is set to that
of the process. When all processes close the UNIX
domain socket, its compartment is unset.
Applies to the following IPC mechanisms: System V shared memory
(for example, created using System V and POSIX sem‐
aphores (for example, created using or and System V
and POSIX message queues (for example, created
using or When an IPC object is created, its com‐
partment is set to that of the process that created
it. POSIX shared memory is implemented as standard
files; hence, POSIX shared memory obeys file system
rules, but not ipc rules.
Applies to Streams Local Transport Drivers that are
used to communicate between processes. Streams
Local Transport Drivers are also known as loopback
drivers, specifically, and The TLI/XTI applications
use these drivers to communicate between client and
server processes.
The keyword is valid only if the HP-UX Containment‐
Plus product (version B.11.31.02 or later) is
installed on the system. The keyword only has
effect when the tunable is set to See t_open(3),
t_connect(3), and cmpt_restrict_tl(5).
compartment_name
Name of the other compartment with which a process
in this compartment can communicate.
The second form of IPC rules governs process visibility and uses the
following format:
compartment_name
where the values are defined as follows:
Allows a process in this compartment to view or access processes
in
compartment_name. This keyword specifies a sub‐
ject-centric rule.
Allows a process in
compartment_name to view or access processes in
this compartment. This keyword specified an
object-centric rule.
Identifies this as a signal IPC rule.
Even though the rule uses the keyword in reality,
the signal IPC rule controls all aspects of process
visibility. For example, the output of the command
reflects the process visibility restrictions set
using this rule.
compartment_name
Name of the other compartment which processes in
this compartment can view or be viewed from.
When multiple IPC rules are defined for the same compartment, the rules
will be aggregated. That is, the union of the IPC mechanisms is taken.
Network Rules
Network rules control access between a process and a network interface,
as well as between two processes using loopback communications. They
do NOT control the communications through Streams Local Transport Driv‐
ers (see cmpt_restrict_tl(5) and the keyword).
If the HP-UX ContainmentPlus product is installed on the system, net‐
work rules can also control access between two processes using loopback
communications alone without changing the connectivities between a
process and a network interface.
These rules control the direction of network traffic (incoming, outgo‐
ing, or both) between the subject compartment and the target compart‐
ment specified in the rule. For loopback communications, the subject
and target compartments should be of the processes that are communicat‐
ing and not that of the interface being used for communication. Each
rule is specified by protocol (TCP, UDP, or any raw protocol number)
and the target compartment, and can optionally filter based on local or
peer port numbers (TCP and UDP only). If an explicit rule does not
match a communication attempt, the default is to deny communication.
If the HP-UX ContainmentPlus product is installed on the system, the
default rule for access between two processes through loopback communi‐
cations (excluding those through loopback interfaces) is also config‐
urable through the tunable. See ifconfig(1M) for more information
about loopback interfaces.
See cmpt_allow_local(5) for more information upon installation of the
HP-UX ContainmentPlus product.
Network rules use the following formats:
(ports] ports] compartment_name
(protonum compartment_name
If the HP-UX ContainmentPlus product is installed on the system, the
network rules using the following formats are also supported:
(ports] ports] compartment_name
(protonum compartment_name
where the values are defined as follows:
Allows access to the network
(both access between a process and a network inter‐
face, as well as between two processes using loop‐
back communications) described by this rule.
Denies access to the network
(both access between a process and a network inter‐
face, as well as between two processes using loop‐
back communications) described by this rule. This
rule is useful when you want to deny access for a
specific configuration (such as a single port), but
you want to allow all other access to the network.
Use it in conjunction with a general rule that
grants all other traffic.
Allows access described by this rule
between two processes using loopback communica‐
tions. The keyword is valid only if the HP-UX Con‐
tainmentPlus product is installed on the system.
Denies access described by this rule
between two processes using loopback communica‐
tions. The keyword is valid only if the HP-UX Con‐
tainmentPlus product is installed on the system.
Applies to inbound traffic.
If the protocol is it allows processes in this com‐
partment to accept connections. For and this rule
applies to all inbound packets.
Applies to outbound traffic.
If the protocol is it allows processes in this com‐
partment to initiate connections. For and this
rule applies to all outbound packets.
Applies to both inbound and outbound traffic.
If the protocol is it allows for connections to be
initiated from the compartment, as well as to be
accepted by the compartment. For and this rule
applies to traffic in both directions.
Applies to TCP protocol traffic only.
Applies to UDP protocol traffic only.
Specifies the INET protocol to which this rule applies.
The keyword is required if the protonum parameter
is specified. The protonum must be specified as
the number associated with a protocol. The names
and numbers of these protocols are available
through the calls. See getprotoent(3N). The pro‐
tocol numbers corresponding to TCP and UDP (6 and
17) are not valid in a raw configuration.
Specifies that this rule applies to a specific port.
If is specified as part of the designation, the
port applies to the other end of the communication.
If is not specified as part of the designation, the
port refers to the local end of the communication.
ports Specifies the actual port being controlled by this
rule. Must be specified as the number of the port.
The ports parameter can be a single port number, a
range of port numbers (such as, start of range -
end of range), or a comma separated list of port
numbers and range of port numbers. The names and
numbers of these ports are available through the
calls (see getservent(3N)).
Designates that the port specifier that follows applies to the
other end
of the communication.
compartment_name
Specifies the name of the compartment that is the
target of the rule. This is usually the interface
compartment name, but can also be specified as
another compartment to indicate a loopback communi‐
cation.
The network rules control how a process can communicate on a given port
and interface, and/or how the process can bind to a port or address.
In other words, the network rules are enforced at the time a communica‐
tion takes place, and when a process calls the routine. The multibind
facility enables processes to attach to IFADDR_ANY on a specific port
in different compartments having disjoint set of interface rules. See
the following section.
When multiple network rules are defined for the same compartment, the
rules will be aggregated. That is, the union of all the rules is
taken.
Miscellaneous Rules
Other rules are as follows:
· Privilege limitation rules
· Network interface rules
Privilege limitations provide a fine control of privileges that cannot
be obtained by the processes in a compartment when calling the routine.
See execve(2). Privilege limitation rules use the following format:
where the values are define as follows:
Identifies this rule as a privilege limitation.
A comma separated list of privileges.
The compound privileges and can also be used. An
exclamation mark before a privilege name removes it
from the list. For example, if the privilege list is
specified as all root replacement privileges except
are disallowed. If the privilege list is only mount
is disallowed. If the privilege list is not specified
for a compartment, the disallowed privilege list for
the compartment defaults to for compartments and for
other compartments.
Note that a disallowed privilege cannot be obtained as a side-effect of
calls even when the binary being executed has extended security
attributes indicating that the process gains that privilege. As an
example, suppose is a disallowed privilege in compartment and that
binary is expected to receive the privilege by means of the following
command:
When an unprivileged process in compartment executes the binary, it
still would not see the privilege in its potential set.
If a root replacement privilege is part of the disallowed privilege,
the privilege is not implicitly granted to a process with an effective
uid of As an extension of the above example, if a process with effec‐
tive uid of but without privilege in its effective set cannot use the
system call.
A disallowed privilege is still available to processes that somehow
obtain the privilege (for example, a process with the privilege in its
effective set can enter the compartment and use the system call).
When multiple disallowed privilege rules are defined, the rules will be
aggregated. Refer to priv_str_to_set(3) for information on how the
privileges string will be aggregated to the privilege set. Network
interface rules specify the compartment to which a network interface
belongs. If a network interface does not have a compartment, no net‐
work traffic in the INET domain (TCP/IP) is allowed to pass.
Network interface rules use the following format:
where the values are defined as follows:
Identifies this as an interface definition.
A comma-separated list of the following entities:
· A physical or virtual interface name, such as:
· An IPv4 address (for example, 192.168.0.1).
· An IPv6 address (for example,
FE80::123:1234:F8).
· A range of IPv4 addresses specified as where
mask represents the number of significant bits
of the address. For instance, an address
192.168.0.1/24 represents the address range
from 192.168.0.0 to 192.168.0.255.
· An IPv6 address range specified as where mask
represents the number of significant bits of
the address.
It is possible to configure the network interface rules such
that there are conflicts. Consider the following example:
Interface is assigned to compartment LAN0, IP address
range 192.168.0.0/16 is assigned to compartment IP_16, IP
address range 192.0.0.0/8 is assigned to compartment
IP_8, and IP address 192.168.0.0 is assigned to compart‐
ment IP.
Note that IPv4 address 192.168.0.0 belongs to all these
ranges specified in the rules for IP_8, IP_16, and IP.
If the interface lan0 is assigned an address of
192.168.0.0, there is an additional conflict.
Such conflicts are resolved as follows:
· An IP address or address range assignment has higher prece‐
dence than a name assignment. For instance, if lan0 is
assigned an IP address of 192.200.1.1, it would belong to
compartment IP_8, not LAN0.
· A rule specifying a more specific IP address range has a
precedence over a less specific IP address range. For
instance, if lan1 is assigned 192.168.0.1, it would belong to
compartment IP_16, not to IP_8.
· A rule with an exact IP address has a higher precedence than
other precedence rules. If lan0 were assigned an address of
192.168.0.0, it would have a compartment of IP.
In a compartment definition, you can define duplicate interface rules.
MULTIBIND
Previous versions of HP-UX have allowed a process to bind to a port on
an interface through which it cannot communicate. This limitation had
the side effect of potentially preventing other (more legitimate) pro‐
cesses from using the port on that interface; thus, effectively hijack‐
ing the port.
In this release, this limitation is removed. In particular, if a com‐
partment has no access to an interface, then processes in that compart‐
ment cannot hijack any ports on that interface.
This is referred to as multibind feature. To fully utilize this fea‐
ture, the compartments must be configured such that there is no inter‐
face that is accessible unless it can be used for communication.
For instance, if compartment X has access to interface lan0 only and
compartment Y has access to interface lan1 only, then processes in
either compartment cannot hijack ports from a process in another com‐
partment.
However, if X is allowed to access even a single port of lan1, it may
be able to hijack all ports of lan1. The current implementation is
more generous: if X is allowed to access only tcp ports of lan1, it can
hijack all tcp ports (but not udp ports) of lan1. Similarly, if X is
allowed to access only udp ports of lan1, it can hijack only udp ports
(but not tcp ports) of lan1.
However, this is an implementation detail and applications should not
depend on that. If the processes in X need to be protected from pro‐
cesses Y hijacking the ports or vice-versa, configure network rules and
interface rules such that no interface is accessible from both compart‐
ments on any protocol.
WARNINGS
The rules generated in mode are only suggestive in nature and need to
be verified.
The rules may be redundant (for example, identical rules may be gener‐
ated for a parent directory and for subdirectory instead of relying on
rule inheritance), may be correct yet meaningless (for example, a file
permission of on a file), and may be insufficient (for example, a net‐
work rule may be created only for a specific anonymous port instead of
the entire anonymous port range). The rules also may be insufficient
especially when a given file has multiple pathnames via hardlinks (the
mode may add rules only for one of the paths or may add conflicting
rules for different paths).
Also, the privileges rule is not generated in mode.
If the command happens to fail at boot, it could leave the databases
inconsistent and lead to unexpected errors from command. Hence, HP
recommends using the option available in to correct such errors and
reboot the system.
Since the network interfaces are usable only when assigned to a com‐
partment, every active interface must belong to a compartment for nor‐
mal operation. If none of the configured interfaces are assigned to
any compartment, inability to communicate can hang the system when try‐
ing to start services such as and at boot time. If the rules are not
all identical, and a process uses autobind to obtain a port number, the
system can reject such a bind request or can assign a port number that
does not allow it to communicate.
FILES
The only rules files not described here that affect the compartment
rules on a system are those included through an directive. The direc‐
tory is used as the default search path for directives that use rela‐
tive paths.
The human-readable version of the compartment rules.
All files whose names end in that reside in the
directory or its sub-directories are processed
when setting rules.
Binary equivalent of the combined human-readable rules files.
CAUTION: Do not edit this file directly.
SEE ALSOcmpt_tune(1M), getrules(1M), mount_lofs(1M), ndd(1M), setrules(1M),
t_connect(3), t_open(3), compartments(5), privileges(5).
compartments(4)
