 |
» |
|
|
|
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).
Hence, you can use
cpp
directives such as
#include,
#define,
#ifdef,
and 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]
compartment
new_compartment_name
{rules} where the values are defined as follows:
- sealed
Indicated that a process in this compartment does 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). - 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.
- {}
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.
Hence, 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 the following format: permission ([none|all]|[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.
i.e., an alias for the expression
read,
write,
unlink,
create. - 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 the contents
of this directory.
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 (e.g., using
link(2)),
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. When a directory, say,
/orig,
is looback mounted on say,
/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 directory containing 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 directory containing 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.
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 format: (grant|deny)
(server|client|bidir)
(tcp|udp|raw
protonum)
[port
port]
[peer
port
port]
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
Applies to the specified protocol number in the INET domain.
The
protonum
parameter is required if the
raw
keyword is specified. - protonum
Specifies the INET protocol to which this rule applies.
It is only valid with the
raw
keyword.
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. - port
Specifies the actual port being controlled by this rule.
Must be specified as the number of the port.
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, but not how the process can bind a port or address.
In other words, the network rules are enforced at the time a
communication takes place, not when a process calls
bind(2).
Suppose that a compartment is configured such that it has no access to
port 8088 on
lan0
interface.
A process in this compartment can still succesfully bind a socket
to port 8088 on an address that corresponds to the
lan0
interface.
However, it will not be able to receive or send any packets on the
socket.
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 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 all /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: interface
interface[[,interface]...]] where the values are defined as follows:
- interface
Identifies this as an interface definition. - interface[[,interface]...]
A comma-separated list of network interface names.
Both physical lan device names and VLAN names are supported.
FILESThe only rules files not described here that affect the compartment
rules on a system are those included through an
#include
directive.
- /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.
|
