 |
» |
|
|
|
NAMEcompartments — HP-UX compartments files DESCRIPTIONHP-UX compartments are defined by creating one or more ASCII files in the
/etc/cmpt
directory.
Only file names ending with
.rules
are parsed for compartment 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
cpp
before parsing.
See
cpp(1).
You can use
cpp
directives such as
#include,
#define,
#ifdef,
and C/C++ style comments to organize and document the rules files. CONFIGURATION RULES SYNTAXA 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:
[sealed][discover]
compartment
new_compartment_name
{rules}
where the values are defined as follows:
- sealed
Indicates that any process in this compartment can not change its
compartment as a side-effect of the
exec()
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). - discover
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
discover. - compartment
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
init
compartment, which is case insensitive.
It can contain only alpha
numeric characters, underscore and hyphen
[a-z
A-Z]
[a-z
A-Z
0-9_-]*
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
Web
instead of
web). File System RulesFile 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: permission [none | all]
file_object permission
[nsearch][,
read][,
write][,
create][,
unlink]
file_object where the values are defined as follows:
- permission
Sets the permissions allowed for processes in this compartment to
access the
file_object
in the way specified. - none
Denies any access to the
file_object
for any process in this compartment.
If specified, none of the other possible arguments can be used. - all
Indicates all permissions on
file_object.
all
is an alias for the expression
nsearch,
read,
write,
unlink,
create. - nsearch
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. - read
Controls read access to the
file_object.
If the file_object is a file,
read
allows processes in this compartment to open the file for reading.
If the
file_object
is a directory, it allows processes in this compartment to list and search
the contents of this directory.
So this permission includes the above
mentioned
nsearch
permission also.
This access control is inherited, so any file or directory
under this
file_object
can be read or listed. - write
Controls write access to the
file_object.
If the
file_object
is a file,
write
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. - create
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 specified directory. - unlink
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 specified 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
MAXPATHLEN
bytes. Each component in the
file_object
name cannot exceed
MAXNAMELEN
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
/a/b/c/d
has four components. The
file_object
is literal; that is, wild card characters such as asterisk
(*)
cannot be specified. The
file_object
has no special or space characters.
All characters except
a-z,
A-Z,
0-9,
slash
(/),
dot
(.),
dash
(-),
underscore
(_),
and
colon
(:),
must be entered using the notation
%xx
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 (i.e., multiple hardlinks),
and the two names have different rules for any compartment,
vhardlinks
command generates warnings.
In order to successfully create a hard link (using
link()),
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
/orig,
is looback mounted on
/lofs,
any access to objects under these directories using either name
result in application of the rule corresponding to the path
beginning from
/orig
but not from
/lofs. IPC RulesIPC rules appear within a compartment definition and govern
how processes in this compartment can access another compartment's
IPC mechanisms 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:
(grant|access)
(pty|fifo|uxsock|ipc)
compartment_name
where the values are defined as follows:
- grant
Allows processes in the compartment
compartment_name
to access the specified IPC mechanism in this compartment.
This keyword specifies an object-centric rule. - access
Allows processes in this compartment to access the specified IPC
mechanism in compartment
compartment_name.
This keyword specifies a subject-centric rule. - pty
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. - fifo
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. - uxsock
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. - ipc
Applies to the following IPC mechanisms: System V shared memory
(for example, created using
shmget()),
System V and POSIX semaphores (for example,
created using
semget()
or
sem_open()),
and System V and POSIX message queues
(for example, created using
msgget()
or
mq_get()).
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:
(send|receive)
signal
compartment_name
where the values are defined as follows:
- send
Allows a process in this compartment to view or access processes in
compartment_name.
This keyword specifies a subject-centric rule. - receive
Allows a process in
compartment_name
to view or access processes in this compartment.
This keyword specified an object-centric rule. - signal
Identifies this as a signal IPC rule.
Even though the rule uses the keyword
signal,
in reality, it controls all aspects of process visibility.
For example, the output of the
ps
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.
Network RulesNetwork 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 compartment specified
in the rule.
For loopback communications, the subject and target compartments should be
of the processes that are communicating 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. Network rules use the following formats: (grant|deny)
(server|client|bidir)
(tcp|udp)
[port
ports]
[peer
port
ports]
compartment_name (grant|deny)
(server|client|bidir)
raw
protonum compartment_name where the values are defined as follows:
- grant
Allows access to the network described by this rule. - deny
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. - server
Applies to inbound traffic.
If the protocol is
tcp,
it allows processes in this compartment to
accept connections.
For
udp
and
raw,
this rule applies to all inbound packets. - client
Applies to outbound traffic.
If the protocol is
tcp,
it allows processes in this compartment to initiate connections.
For
udp
and
raw,
this rule applies to all outbound packets. - bidir
Applies to both inbound and outbound traffic.
If the protocol is
tcp,
it allows for connections to be initiated from the compartment, as well
as to be accepted by the compartment.
For
udp
and
raw,
his rule applies to traffic in both directions. - tcp
Applies to TCP protocol traffic only. - udp
Applies to UDP protocol traffic only. - raw protonum
Specifies the INET protocol to which this rule applies.
The
raw
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
getprotoent()
calls.
See
getprotoent(3N).
The protocol numbers corresponding to TCP and UDP (6 and 17) are not valid
in a raw configuration. - port
Specifies that this rule applies to a specific port.
If this is specified as part of the
peer
designation, the port applies to the other
end of the communication.
If not part of the peer designation, it 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.
It 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
getservent()
calls.
See
getservent(3N). - peer
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
bind().
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
MULTIBIND
section below. Miscellaneous RulesThese are rules that don't fit into the other categories:
Privilege limitation rules
Privilege Limitation RulesPrivilege limitations provide a fine control of privileges that
cannot be obtained by the processes in a compartment when calling
execve().
See
execve(2).
Privilege limitation rules use the following format:
disallowed privileges
privilege[,privilege...]
where the values are define as follows:
- disallowed privileges
Identifies this as a privilege limitation. - privilege[,privilege...]
is a comma separated list of privileges.
The compound privileges
basic,
basicroot,
policy,
and
none
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
basicroot,!mount,
all root replacement privileges except
mount
are disallowed.
If the privilege list is
none,mount,
only mount is disallowed.
If this is not specified for a compartment, it defaults to
policy
for
sealed
compartments and
none
for other compartments.
A disallowed privilege cannot be obtained as a side-effect of
exec()
calls even when the binary being executed has extended security
attributes indicating that the process gains that privilege.
As an example, suppose
mount
is a disallowed privilege in compartment
no_mounts,
and that binary
/usr/bin/magic_mount
is expected to receive the
mount
privilege by means of the following command:
setfilexsec -p mount -P mount /usr/bin/magic_mount When an unprivileged process in
no_mounts
compartment executes the binary,
it still would not see the
mount
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
0.
As an extension of the above example, if a process with effective
uid of
0
but without
mount
privilege in its effective set cannot use the
mount()
system call. Note that a disallowed privilege is still available to processes that
somehow obtain the privilege (for example, a process with the
mount
privilege in its effective set can enter the
no_mounts
compartment and use the
mount()
system call). Network Interface RulesNetwork 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:
- interface
Identifies this as an interface definition. - X[,X...]
A comma-separated list of the following entities:
A physical or virtual interface name, such as:
lan0,
vlan0. 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
ipv4_addr/mask,
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
ipv6_address/mask,
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
lan0
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 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 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. 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.
MULTIBINDPrevious 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 compartment 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
interface 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 processes Y hijacking
the ports or vice-versa, configure network rules and interface rules
such that no interface is accessible from both compartments on any
protocol. WARNINGSThe rules generated in
discover
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
create
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 insufficient especially when a given file has
multiple pathnames via hardlinks (the
discover
mode may add rules only for
one of the paths or may add conflicting rules for different paths). Also, the
disallowed
privileges rule is not generated in
discover
mode. If the
setrules
command happens to fail at boot, it could leave the
databases inconsistent and lead to unexpected errors from
getrules
command.
Hence it is recommended to use the
preview
option available in
setrules
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
nfs,
sendmail,
and so on, at boot time. It is adviced to have same access rule for all the ports in the
anonymous port range.
(The anonymous port range is configurable using the
ndd
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. FILESThe only rules files not described here that affect the compartment
rules on a system are those included through an
#include
directive.
The
/etc/cmpt
directory is used as the default search path
for
#include
directives that use relative paths. - /etc/cmpt/
The human-readable version of the compartment rules.
All files whose names end in
*.rules
that reside in the
/etc/cmpt
directory or its sub-directories are processed when setting rules. - /etc/cmpt-rules.bin
Binary equivalent of the combined human-readable rules files.
Do NOT edit this file directly.
|
Printable version
