 |
» |
|
|
|
A compartment consists of a name and a set of rules.
This section describes the four types of compartment 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 } |
where: - sealed
(Optional) A process in
this compartment cannot gain privileges or change compartments by
calling execve(). - discover
(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. - compartment
Designates that the rule
is a compartment definition. - new_compartment_name
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 ... */ |
| | | |  | 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 |
where: - permission or perm
Sets permissions for a file or directory. - permission_list
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.
- file_object
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 |
where: - Access
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.
- Method
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.
- compartment_name
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 |
where: - Direction
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.
- signal
Specifies that this rule
applies to signals and process visibility. - compartment_name
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 |
where: - Access
Grants or denies the compartment
access to the network traffic in the specified compartment. The options
are: - Direction
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.
- Protocol
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.
- protonum
The protocol number specified
for this rule. The protonum option is relevant only
for raw specification. - port
(Optional) Specifies that
this rule applies to a specific port. - port
Identifies the port specified
in this rule. - peer
(Optional) The port information
applies to the peer endpoint involved in the communication for this
rule. - compartment_name
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][...]
} |
where: - interface
Specifies that this is an
interface definition. - interface_or_ip[,interface_or_ip][...]
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 192.168.0.0-192.168.0.255 */
interface 192.160.0.0/24
} |
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[...]] |
where: - disallowed privileges
Specifies this as a privilege
limitation rule. - privilege[,privilege[...]]
A comma-separated list of privileges. You can use the following additional
keywords: all: disallows
all privileges none: allows
all privileges
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
