compartments(4) Kernel Interfaces Manual compartments(4)
NAME
compartments - 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 compart-
ment definitions. Collectively, these files define compartments and compartment 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 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 control
access to resources (objects) in a compartment by processes (subjects) in other compartments.
Compartment definitions use the following format:
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 indi-
cating 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 more
of 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
Designates that this is a compartment definition.
new_compartment_name
Specifies the name to be applied to the compartment being defined. The name is case sensitive, 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 cannot 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 may be extended to include new keywords in the future. It is strongly recommended that compartment
names begin with an uppercase character to avoid any future syntax errors (for example, compartment instead of
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
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 arguments can be used.
Indicates all permissions on
file_object. is an alias for the expression
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
directory underneath is not searchable unless explicitly allowed to.
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 directory, allows processes in this compartment to list and search the contents of this direc-
tory. This permission includes the above mentioned permission also. 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 pro-
cesses in this compartment can create file objects anywhere under the specified 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 pro-
cesses in this compartment can delete file objects anywhere under the specified directory.
file_object Fully-qualified name of a file or directory. This name is restricted in the following ways:
o The total length of the name of the file_object cannot exceed bytes.
o Each component in the file_object name cannot exceed bytes.
o 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.
o The file_object is literal; that is, wild card characters such as asterisk cannot be specified.
o The file_object has no special or space characters. All characters except slash dot dash underscore and colon must
be entered using the notation where xx corresponds to the hexadecimal 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 do 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 looback 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 processes in this compartment can access another compartment's IPC mecha-
nisms and how processes in other compartments may access this compartment'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
where the values are defined as follows:
Allows processes in the compartment
compartment_name to access the specified IPC mechanism in this compartment. This keyword specifies an object-centric
rule.
Allows processes in this compartment to access the specified IPC
mechanism in compartment compartment_name. 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 compartment until a process opens them. When
a terminal without a compartment ID is opened, its compartment is set to that of the process that opened it. When all
open file handles to the terminal are closed, the terminal's compartment ID is unset.
Applies to named pipes (FIFOs) 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 named pipe. Initially a FIFO has no compartment. When a process opens the FIFO for the
first time, its compartment 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. Note that 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 compartment. 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 semaphores (for example, created using or and System V and POSIX message
queues (for example, created using or When an IPC object is created, its compartment 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.
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 subject-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.
These rules control the direction of network traffic (incoming, outgoing, 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 communi-
cating and not that of the interface being used for communication. Each rule is specified by protocol (TCP, UDP, or any raw protocol num-
ber) 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.
Network rules use the following formats:
(ports] ports] compartment_name
(protonum compartment_name
where the values are defined as follows:
Allows access to the network described by this rule.
Denies access to the network 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.
Applies to inbound traffic.
If the protocol is it allows processes in this compartment 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 compartment 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 associ-
ated with a protocol. The names and numbers of these protocols are available through the calls. See getprotoent(3N).
The protocol 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 speci-
fied 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. ports 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 getser-
vent(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 communication.
The network rules control how a process can communicate on a given port and interface, as well as how the process can bind to a port or
address. In other words, the network rules are enforced at the time a communication takes place, and when a process calls 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 section below.
When multiple network rules are defined for the same compartment, the rules will be aggregated. That is, the union of the all the rules is
taken.
Miscellaneous Rules
Other rules are as follows:
o Privilege limitation rules
o Network interface rules
Privilege limitations provide a fine control of privileges that cannot be obtained by the processes in a compartment when calling See
execve(2). Privilege limitation rules use the following format:
where the values are define as follows:
Identifies this as a privilege limitation.
is 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.
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 effective uid of but without privilege in its effective set cannot use the
system call.
Note that a disallowed privilege is still available to processes that somehow obtain the privilege (for example, a process with the privi-
lege 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 network 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:
o A physical or virtual interface name, such as:
o An IPv4 address (for example, 192.168.0.1).
o An IPv6 address (for example, FE80::123:1234:F8).
o 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.
o 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 compartment 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 inter-
face lan0 is assigned an address of 192.168.0.0, there is an additional conflict.
Such conflicts are resolved as follows:
o An IP address or address range assignment has higher precedence 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.
o 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.
o 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, of course,
had the side effect of potentially preventing other (more legitimate) processes from using the port on that interface; thus, effectively
hijacking the port.
In this release, this limitation is removed. In particular, if a compartment has no access to an interface, then processes in that com-
partment cannot hijack any ports on that interface.
This is referred to as multibind feature. To fully utilize this feature, 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 compartment.
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
actually a bit 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 com-
partments 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 generated 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
network rule may be created only for a specific anonymous port instead of the entire anonymous port range). The rules also may be insuffi-
cient especially when a given file has multiple pathnames via hardlinks (the mode may add rules only for one of the paths or may add con-
flicting 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 compartment, every active interface must belong to a compartment for normal
operation. If none of the configured interfaces are assigned to any compartment, inability to communicate can hang the system when trying
to start services like and so on, at boot time. command.) If not all rules are identical, and a process that uses autobind to obtain a
port number, the system may reject such a bind request or may 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 relative 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.
Do NOT edit this file directly.
SEE ALSO
cmpt_tune(1M), getrules(1M), mount_lofs(1M), ndd(1M), setrules(1M), compartments(5), privileges(5).
compartments(4)