- Using Labels for Containment
- Labeled Processes
- Service Provider Network Configuration
- Customer Web Site Configuration
- Resource Constraints
- Summary
- Acknowlegements
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Service Provider Network Configuration
Each customer is assigned two IP addresses which are created using logical interfaces. This is sometimes referred to as virtual hosting. The customer's web server binds to one of these IP addresses, and the other is used for administrative activities like uploading new data, and remote login. Although the number of interfaces can be scaled up for larger configurations, we will limit the discussion to two customers for clarity. A multi-homed host with two interfaces, hme0 and hme1 is used. The interface hme0 is connected to the Internet and has two logical interfaces per customer. TABLE 2 summarizes the configuration for two customers, with a multilevel interface to backend Tomcat servers.
TABLE 2 Functionality of Network Interfaces
|
Interface |
IP address |
Hostname |
Services |
|
hme0:0 |
192.168.0.1 |
c1accounts |
telnet, ftp |
|
hme0:1 |
192.168.0.2 |
c1webserver |
http, anonymous ftp |
|
hme0:2 |
192.168.0.3 |
c2accounts |
telnet, ftp |
|
hme0:3 |
192.168.0.4 |
c2webserver |
http, anonymous ftp |
|
hme1 |
192.10.10.1 |
tsolweb |
admin |
|
(separate host) |
|
|
|
|
hme0 |
192.10.10.2 |
tsolasp |
JSP |
Each logical interface is defined in a corresponding hostname file. For example the file /etc/hostname.hme0:0 contains c1accounts, which, in turn, is defined in /etc/inet/hosts. The entries for hostname.hme1 and hostname.hme0 on the second host are automatically created since they represent the default interfaces on each of the two Trusted Solaris machines.
Associating Labels with Network Interfaces
Each network interface, whether real or logical, has four labels associated with it. In addition to the default label discussed above, there is a default clearance. These attributes are applied to connections which are initiated remotely. The policy for transmission through a network interface is based on two additional labels which specify an upper and lower bound, called the accreditation range.
Outgoing packets must be routed through an interface with an accreditation range containing the label of the packet, or they are dropped. Incoming packets are dropped unless they are within the accreditation range of the interface on which they are received. This policy can be contrasted to a firewall, which can block packets targeted at a specific host or port. In this configuration, processes with the CGI compartment are blocked from any communication through the logical interfaces, whether inbound or outbound.
Each of the interfaces with connections to the Internet will communicate using its specified default label. An additional interface for the internal use of the Service Provider will accept all labels because it will be communicating on a protected wire. Packets within the Service Provider's network will be explicitly labeled using the tsol protocol which transmits label attributes within each packet. The interface label assignments are summarized in TABLE 3.
TABLE 3 Default Labels and Accreditation Ranges for Network Interfaces
|
Interface |
Default Label and Clearance |
Minimum Label |
Maximum Label |
|
hme:0 |
C1 |
Admin_Low |
C1 |
|
hme0:1 |
C1 HTTP FTP |
Admin_Low |
C1 HTTP FTP |
|
hme0:2 |
C2 |
Admin_Low |
C2 |
|
hme0:3 |
C2 HTTP FTP |
Admin_Low |
C2 HTTP FTP |
|
hme1 |
Private Intranet |
Admin_Low |
Service Provider |
|
(separate host) |
|||
|
hme0 |
Private Intranet |
Admin_Low |
Service Provider |
NOTE
In order to use dynamic routing on an interface, the minimum label must be Admin_Low. Routing protocols broadcasts, multicasts, and unicasts are always sent at the Admin_Low label.
These values are maintained in the trusted network interface database, tnidb. Like most of the databases which are unique to Trusted Solaris OE, it is stored in the directory /etc/security/tsol. Except for the label_encoding file discussed above, all of the databases which assign labels can be maintained by authorized administrators using GUI tools, command line utilities, or direct editing. The Solaris™ Management Consol software has been extended in the Trusted Solaris OE, and provides full support for applying labels to network interfaces, hosts, commands, users, and roles. For example, the GUI to assign a label to a network interface is shown in FIGURE 2.
){kind=link}
FIGURE 2 Solaris Management Console Interface Manager Label GUI
Associating Services With Interfaces
FIGURE 3 demonstrates how the data paths between the various services are compartmentalized.
){kind=link}
FIGURE 3 Virtualized Services with the Service Provider Network
From a client's perspective, each of these interfaces might as well be a separate machine because MAC rules prevent unprivileged services bound to the different network interfaces from communicating with each other. Furthermore, access to these interfaces can be restricted to authorized individuals through authentication policies and by limiting the services bound to these interfaces3.
Associating Labels with Incoming Packets
Packets delivered to a Trusted Solaris OE are labeled upon receipt. The value of the label depends on several factors, including the attributes associated with the sender, and the network interface from which the packet was received. In this configuration, the Trusted Solaris OE automatically labels each incoming request using the default label of the interface specified in the packet's target IP address. Network packets which originate from within a Trusted Solaris software system are normally sent with the label of the process sending the data.
Hosts that do not transmit explicit labels, and are referred to as unlabeled. Packets received from unlabeled hosts are implicitly labeled by matching their source address against a kernel cache of trusted networking templates. These templates provide the rules for interpreting the security attributes of remote hosts. The association of an IP address to a template is based on administrative assignments maintained in the tnrhdb database.
Hosts may be explicitly assigned a template or implicitly via network wildcard assignments. If the template which most closely matches the source IP address specifies a default label value, then that label is applied to the packet. Otherwise, the default label assignment for the interface is applied (as described in the preceding Associating Labels With Network Interfaces section). If no default value is specified, the packet is dropped. The value 0.0.0.0 is the most general wildcard. Assigning the InterfaceDefault template to this wildcard, specifies that the incoming labels for remote hosts will be determined by attributes of the interface. The IP addresses associated with the directly connected interfaces all use the tsol template. The template assignments are maintained in the remote host database, tnrhdb, and are shown in the following example.
0.0.0.0 InterfaceDefault 192.168.0.0 tsol 192.10.10.0 tsol |
These templates are defined in the remote host template database, tnrhtp. The tsol template is included by default, and should be assigned to all local IP addresses. The following is an example of the InterfaceDefault entry.
InterfaceDefault:host_type=unlabeled;def_label=empty;def_cl=empty;min_sl=Admin_Low;max_sl=Admin_High; ip_label=none;ripso_label=empty;ripso_error=empty;doi=0; |