Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

compartments(4) [hpux man page]

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)
Man Page

Featured Tech Videos