Jump to content United States-English
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
More options
HP.com home
HP-UX System Administrator's Guide: Security Management: HP-UX 11i Version 3 > Chapter 7 Compartments

Compartment Rules and Syntax


Technical documentation

Complete book in PDF
» Feedback
Content starts here

 » Table of Contents

 » Glossary

 » Index

A compartment consists of a name and a set of rules. This section describes the four types of compartment rules:

  • File system rules

  • IPC rules

  • Network rules

  • Miscellaneous rules

Add rules to a rules file you create in the /etc/cmpt directory. You can edit this file using vi or a similar text editor. The rules file must have a .rules extension.

See compartments(5) for additional information.

Compartment Definition

Define compartments by configuring a name for each compartment, and associating one or more compartment rules with the compartment name. You can specify rules in any order.

The syntax for a compartment definition is as follows:

[sealed] [discover] compartment new_compartment_name { rules }



(Optional) A process in this compartment cannot gain privileges or change compartments by calling execve().


(Optional) Discover and automatically add rules so that compartment violations are overridden. This is a development feature to determine the rules necessary, and should not be used on a production system. See Section  for more information on this keyword.


Designates that the rule is a compartment definition.


The label associated with the new compartment. This label is case sensitive. For example, compartmenta and CompartmentA are different compartments.


Enclose the rules for this compartment.

For example:

sealed compartment server_children { /* Deny all access to any file system objects ... */

permission none / }
NOTE: The INIT compartment name is not case sensitive. INIT, init, and Init are all treated as the same compartment by the system.

Compartment specifications are preprocessed with cpp() before parsing begins. This is why you use cpp() directives such as #include, #define, #ifdef, and C-style comments to organize and document rules files.

File System Rules

File system rules govern access by processes to files and directories on the system. File system rules are inherited from a parent directory to all subdirectories and files within the parent, unless an explicit rule overrides inheritance.

By default, if no permissions are specified, all permissions are granted for a file system object.

The syntax for file system rules is as follows:

(permission|perm) permission_list file_object


permission or perm

Sets permissions for a file or directory.


The types of permission you can apply to a file or directory are:

  • none: Denies all permissions to a file or directory.

  • read: Controls the read access to the object. If the object is a file, reading and executing the file is controlled. If the object is a directory, searching and listing the directory is controlled. Additionally, due to inheritance, reading of all files under the directory is controlled. Files must have read access in order to be opened for execution.

  • write: Controls the write access to the object. If the object is a file, writing to the file is controlled. If the object is a directory, due to inheritance, writing for all files under the directory is controlled.

  • create: Controls the ability to create objects. This applies to directory objects only. This is inherited by all directories under the specified directory.

  • unlink: Controls the ability to delete objects. This applies to directory objects only. This is inherited by all directories under the specified directory.

  • nsearch: Controls the ability to search for an element if the file_object is a directory. This attribute is not inherited by subdirectories.


The full path name of the file or directory.

For example:

/* deny all permissions except read to entire system */ perm read  / /* except for this directory */ perm read,write,create,unlink /var/opt/server /* just read and write log files, not create them */ perm  read,write /var/opt/server/logs
NOTE: To grant any permission on a file system object, the compartment must have a minimum of read permission on every directory above that object. For example, to grant read and write permissions on /var/opt/tmp/file1, you must grant read permissions on /var/opt/tmp, /var/opt, /var, and /.

IPC Rules

Interprocess communication (IPC) rules govern how processes use interprocess communication methods between compartments. IPC communication methods include direct process-to-process communication or shared access to an IPC object. When an object is associated with a process, the object exists in the same compartment as the process that created it. You define compartment rules to describe the relationship between the process accessing the object and the object being accessed. When the rule describes two processes communicating with each other, you treat the second process as an object. The default behavior for IPC objects is that all operations between different compartments are prohibited unless explicitly allowed by a rule.

There are two types of IPC rules. The syntax for the first rule type is as follows:

(grant|access) (pty|fifo|uxsock|ipc) compartment_name



Specifies whether the rule is object-centric or subject-centric. The options are:

  • grant: Specifies an object-centric rule. This rule allows processes in the compartment compartment_name to access the specified IPC mechanism in the current compartment.

  • access: Specifies a subject-centric rule. This rule allows processes in the current compartment to access the specified IPC mechanism in the compartment compartment_name.


Specifies the method of communication this rule applies to. The options are:

  • pty: Specifies that the rule applies to pty used in interprocess communication.

  • fifo: Specifies that the rule applies to FIFOs.

  • uxsock: Specifies that the rule applies to UNIX domain sockets.

  • ipc: Specifies that the rule applies to SYSV and POSIX IPC objects, such as shared memory, semaphores, and message queues.


The name of the other compartment where processes in this compartment can communicate with.

For example:

/* allow the children to access UNIX domain */ /* sockets created by the parent compartment */

grant uxsock server_children

The second type of IPC rule governs process access. The syntax for this type of rule is as follows:

(send|receive) signal compartment_name



Specifies whether processes in the current compartment have access to view and alter process behavior from another specified compartment. The options are:

  • send: Specifies a subject-centric rule. Allows processes in the current compartment to send signals and view process data in the compartment compartment_name.

  • receive: Specifies an object-centric rule. Allows processes in the compartment compartment_name to send signals and view process data in the current compartment.


Specifies that this rule applies to signals and process visibility.


The name of the other compartment where processes in the current compartment can have access to view process information or to be viewed from.

For example:

/* allow the parent to send signals to children */ send signal server_children

Network Rules

Network rules govern access to network interfaces. Network rules also govern communication between processes that use INET domain communication (TCP/IP sockets and streams). The default behavior is to deny access to the network.

Network endpoints are treated as objects labeled with the compartment of the process that creates them. However, a network endpoint can be created by one process, then passed to another process, which can run in a different compartment. Access checks are performed on the compartment containing the endpoint when the endpoint was created, not the current compartment. Additionally, the endpoint passes its compartment configuration to accepting endpoints when it receives new connections.

INET domain endpoints are frequently used for interprocess communications. Be sure to configure the compartments accordingly.

The syntax for a network rule is as follows:

(grant|deny) (server|client|bidir) (tcp|udp|raw [protonum] ) [port port_num] [peer[portport]] compartment_name



Grants or denies the compartment access to the network traffic in the specified compartment. The options are:

  • grant

  • deny


Specifies which direction the rule applies to. The options are:

  • server: This rule applies to inbound requests only. For TCP, only incoming connections are controlled by this rule. For UDP and RAW, this rule applies to all inbound packets.

  • client: This rule applies outbound requests only. For TCP, only connection initiations are controlled by this rule. For UDP and RAW, this rule applies to all outbound packets.

  • bidir: This rule applies to both inbound and outbound requests. For TCP, connections initiated and received by the endpoint are controlled by this rule. For UDP and RAW, this rule applies to all packets passing through the endpoint.


Specifies the networking protocol that applies to this rule. The options are:

  • tcp: This rule applies to the TCP protocol.

  • udp: This rule applies to the UDP protocol.

  • raw: This rule applies to any other protocol in the INET domain.


The protocol number specified for this rule. The protonum option is relevant only for raw specification.


(Optional) Specifies that this rule applies to a specific port.


Identifies the port specified in this rule.


(Optional) The port information applies to the peer endpoint involved in the communication for this rule.


The compartment name associated with the peer endpoint or interface this rule applies to.

For example:

/* allow all inbound TCP connections(any port)from interfaces labeled lancmpt1 */

grant server tcp lancmpt1

/* allow DNS client lookups (both TCP and UDP) through interface labeled lancmpt1 */

grant client tcp port 53 lancmpt1
grant bidir udp port 53 lancmpt1 

/* allow only outbound telnet connections through interface labeled ifacelan0 */

grant client tcp peer port 23 ifacelan0

/* allow all TCP traffic except inbound telnet through interface labeled ifacelan0 */
/* the following two lines can be specified in either order */

grant bidir tcp ifacelan0 deny server tcp port 23 ifacelan0

/* allow inbound web server traffic through interface lan1cmpt */

grant server tcp port 80 lan1cmpt

For more information about network rules, see compartments(4).

Miscellaneous Rules

These are rules that do not fit neatly into any other rules category.

Network Interface Rules. A network interface rule specifies the compartment that an interface belongs to. A network interface that is not in a compartment cannot be brought on line.

NOTE: For stricter security policies, configure network interfaces in separate compartments from those assigned to processes. Define rules for network access for each compartment accordingly. Equal compartments are always granted full access to one another.

The network interface rule syntax is as follows:

compartment compartment_name { interface interface_or_ip[,interface_or_ip][...] }



Specifies that this is an interface definition.


A comma-separated list of interface names, IP address, or range of IP addresses. IP addresses or ranges can be specified as IPv4 addresses or IPv6 addresses with an optional mask.

For example:

compartment iface0 { /* Define the compartment for the network interface lan0 */ interface lan0 /* All addresses in the range */ interface }

compartment other_ifaces { /* Define the compartment for two of the other network interfaces */ interface lan1,lan5

Privilege Limitation Rules. A privilege limitation rule controls privilege inheritance. Any privilege named in a privilege limitation rule cannot be obtained when calling execve(2).

The syntax for privilege limitation rules is:

disallowed privileges privilege[,privilege[...]]


disallowed privileges

Specifies this as a privilege limitation rule.


A comma-separated list of privileges. You can use the following additional keywords:

  • all: disallows all privileges

  • none: allows all privileges

  • !: denotes except

For example:

/* Disallow all privileges except mount. */ disallowed privileges all,!mount

/* Disallow mount only. */ disallowed privileges none,mount

If privilege limitation rules are not specified for a compartment, the default privilege limitation is basicpolicy,mknod for every compartment except the INIT compartment. The INIT compartment default privilege limitation is none.

Example Rules File

An example rules file is located in /etc/cmpt/examples/sendmail.example.

Printable version
Privacy statement Using this site means you accept its terms Feedback to webmaster
© 2008 Hewlett-Packard Development Company, L.P.