HP-UX Secure Resource Partitions (SRP) A.02.02 Administrator's Guide

1.3 Planning Considerations and Best Practices

This section contains information to consider when planning an SRP deployment and best practices to

follow when managing a system with SRP compartments.

1.3.1 Compatibility with Other Partitioning Continuum Products

HP-UX SRP is a component of the Partitioning Continuum for HP-UX and is compatible with HP-UX

nPartitions, HP-UX vPar, and Integrity Virtual Machine (VM) solutions. You can create an SRP in any

HP-UX OS image; the OS image can exist in an nPartition, vPar, Integrity VM, or directly on non-

partitioned server hardware.

1.3.2 Coexistence with the INIT Compartment

The INIT compartment is a permanent, default compartment defined by the Security Containment

product. The INIT compartment provides a comprehensive host-based view of the system. By default,

all system processes and services (all processes started by the init process) run in the INIT

compartment, and the INIT compartment has access to all files and processes. The INIT

compartment also has access to all interfaces configured in other compartments, including the

ifaces compartment and all SRPs. (When you run srp_sys –setup, the Security Containment product

is initially enabled, it creates the ifaces compartment and assigns all network interfaces currently

installed on the system to ifaces.)

1.3.2.1 Using the INIT Compartment

You must perform system administration activities in the INIT compartment. By default, a login to the

system console or a network based session (ssh, telnet) to the iface compartment IP addresses

will result in a session in the init compartment. To verify that your session is in the init compartment,

you can use the following command to return the name of the compartment you are running in:

getprocxsec -c

1.3.2.2 Address Collisions with INADDR_ANY and IN6ADDR_ANY Sockets in the INIT Compartment

Because the INIT compartment has access to all network interfaces configured in other

compartments, it is possible for a socket owned by a process running in the INIT compartment that

binds to the wildcard IP address INADDR_ANY or IN6ADDR_ANY to bind to the specified port number

on all IP or IPv6 interfaces on the system. This means that socket owned by a process in the INIT

compartment can bind to an IP address that is configured for another compartment. (Note that

compartments other than INIT can bind only to IP addresses for which they been explicitly

configured access.)

An address collision can occur if a process in the INIT compartment and a process in an SRP

compartment attempt to use the same port number and either process attempts to bind the socket to

the INADDR_ANY or IN6ADDR_ANY address. If both sockets have the SO_REUSEADDR option set,

both bind calls will succeed, but either socket may receive a given connection request. If both sockets

do not have the SO_REUSEADDR option set, the second bind call will fail.

1.3.2.2.1 Address Collisions with sshd Daemons

One example of a network daemon that might have problems with address collisions is the sshd

daemon. By default, the sshd daemon binds its socket to TCP port 22 on the wildcard IP address

INADDR_ANY (or IN6ADDR_ANY, if the IPv6 address family is specified). If an sshd daemon is runs

in the INIT compartment with the default configuration and a second sshd daemon starts in an SRP

compartment and attempts to bind its socket to TCP port 22 on the compartment IP address, the bind