- 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
Customer Web Site Configuration
The Service Provider grants a certain amount of configuration control to authorized customer administrators. Most of the customers activities are beyond the scope of this article, but we will discuss how the customer configures the web server and updates the web content.
The Service Provider creates one or more administrative accounts for each customer. No such administrative accounts need to run as root, nor are there any files owned by root within their label range. In fact, even if they were given the root password it would do them no good since they are neither authorized to assume the root role, nor to write down to the Admin_Low label. For example, an administrative account for Customer1, created using the SMC Users tool, would have an /etc/user_attr entry like the following:
c1admin::min_label=C1;clearance=C1 HTTP FTP CGI;\ profiles=C1 Rights; |
The customer's web configuration files would be owned by c1admin, and maintained at the C1 label; therefore, no privileges would be required for most operations, such as maintaining the web server configuration file, or adding Web users via htpasswd. The C1 Rights profile would be used to start and stop the web server since that will typically require the use of privilege. It should also include the authorization solaris.login.remote for remote access to telnet and ftp. The authorization is listed in the /etc/security/prof_attr entry as follows:
C1 Rights:::Rights for Customer 1 Administrator:\ auths=solaris.login.remote;help=index.html |
In addition, an /etc/security/exec_attr entry that includes the apachectl shell script is as follows:
C1 Rights:tsol:cmd:::/usr/apache/bin/apachectl:uid=nobody;\ gid=nobody;clearance=C1 HTTP FTP CGI;label=C1 HTTP FTP;\ privs=proc_owner,net_privaddr |
Access to Other Compartments
Since c1admin is cleared for all C1 compartments, he or she can operate at the HTTP FTP or CGI compartments. For example, if c1admin could telnet to c1webserver, the connection would be made at the C1 HTTP FTP label. However, in a hardened environment, remote login could be blocked for that interface by a firewall rule.
The SunScreen™ 3.2 Firewall has been optimized for Trusted Solaris 8 OE, and its ability to block access to specific ports on specific interfaces complements the label-based polices discussed in this article. By default, most trusted services listen for connections at any label from any interface. Therefore, firewall rules should be applied to restrict these services.
A more flexible way to provide access to other compartments is by use of explicit profile entries. For example, a wrapper to switch to the CGI compartment could be done as follows:
#!/bin/sh # Start a new profile shell # For clarity, display the current label value in the prompt PS1='plabel|cut -f2'" " export PS1 /usr/bin/pfsh |
If this wrapper is stored as /usr/local/bin/gotoCGI, then the following exec_attr entry provides the c1admin access to the CGI compartment from the C1 label.
C1 Rights:tsol:cmd:::/usr/local/bin/gotoCGI;label=C1 CGI;\ clearance=C1 CGI |
Access to the CGI compartment is only available from the C1 label because the clearance specified in such a profile entry must dominate both the current process label and the new label. For example, the c1admin could telnet to c1accounts and successfully use the gotoCGI wrapper, but the wrapper would fail with c1webserver since the default label, C1 HTTP FTP is not dominated by C1 CGI.
Specifying Pathnames for Web Configuration Files
Multilevel Directories (MLDs) are often used in the Trusted Solaris OE to allow processes running at different labels to use the same pathnames when reading and writing data. The real pathname to a file in an MLD is dependent on the label of the process which opens it. By default, Apache looks for its server configuration file in /etc/apache/http.conf. The directory /etc/apache could be converted into an MLD to polyinstantiate a unique instance for each customer. Although this approach is automatic, it is not convenient in this case since each web server runs at a higher label than its configuration file.
It is easier to create unique pathnames for each customer and use MAC to restrict each customer's files to be those processes which dominate the customer's minimum label, e.g., C1. Similarly, the DocumentRoot directory should not be an MLD, either. Instead, the Service Provider should create these directories with the customer's label and ownership. The disjoint labels assigned to directories and files provides strong isolation without the complexity and overhead of using chroot(1M) to create disjoint directories
The path to the configuration file can be explicitly passed to the web server as a command line option, with each customer having a unique pathname for their configuration file which is maintained in a regular directory at a unique label. In our previous article, we discussed how the script /etc/init.d/apache could be modified to provide for labeled execution. Here we make a few more modifications to provide a unique pathname for each customer's server configuration file:
#!/bin/sysh
#
#ident "@(#)apache.sh 1.3 99/11/10 SMI"
#
# extract customer name and profile name from script name
CUSTOMER='basename $0|cut -f2 -d .'
setprof ${CUSTOMER}
CONF_DIR=/home/${CUSTOMER}admin
if [ ! -d ${CONF_DIR} ]; then
exit 0
fi
# Allow webservers to create entries PID entries in /var/run
setfacl -m group:webserver:rwx /var/run
setfacl -m mask:rws /var/run
|
The /usr/apache/bin/apachectl file is similarly modified to find the $CONF_DIR using the process label:
# Extract customer name from process label
CUSTOMER='plabel -s|tr -s [:upper:] [:lower:]|\n
cut -d [ -f2|cut -d ' ' -f1'
CONF_DIR=/home/${CUSTOMER}admin
HTTPD="/usr/apache/bin/httpd -f ${CONF_DIR}/http.conf"
|
For each customer, a hard link to the init.d script is created in /etc/rc3.d based on the customers name, for example:
# ln /etc/init.d/apache /etc/rc3.d/S50apache.c1 |
Specifying the Security Attributes for the Web Server
The Service Provider is responsible for system security, which includes the maintenance of rights profiles. A rights profile, with a name corresponding to the link's suffix, must be created in which the label, clearance, uid, gid, and privileges (if any) are specified. The contents and format of this profile were discussed in the previous article. In this context, the exec_attr entry to start the Apache web server would look as follows:
c1:tsol:cmd:::/usr/apache/bin/apachectl:uid=nobody;\ gid=webserver;clearance=C1 HTTP FTP CGI;label=C1 HTTP FTP;\ privs=proc_owner,net_privaddr # c1:tsol:cmd:::/usr/bin/setfacl:clearance=C1 HTTP FTP CGI;label=C1 HTTP FTP |
When using suexec, it is necessary for all the web servers to run with the same user ID that was specified when suexec was compiled. The default value is set to nobody in the Solaris OE distribution. The web server is not privileged to change its user ID, so the Service Provider must specify this value in the rights profile. Furthermore, the web server is not privileged to write to files owned by root, so a common group, webserver, is specified. A group ACL is set on the MLD /var/run in which the web server records its process ID (this ACL is applied at boot time since /var/run is mounted on swap). The logging directory /var/apache/logs uses this group ID as well.
Customer Web Server Configuration
It is the responsibility of the customer to properly configure the web server, but there are no settings that c1admin can choose that will allow access to any other customers, since they are all compartmentalized. Even if the web server is misdirected to the wrong IP address, for example, it won't affect any other customers because the ports on every interface are polyinstantiated. Furthermore, this containment prevents a customer from creating local hyperlinks to another customer's files.
Setting Up Anonymous FTP
Since ftpd is managed by inetd, the server is automatically started with the same label as the requesting client. For anonymous ftp, the setup procedure described in the man page ftpd(1M) is essentially the same in Solaris OE and Trusted Solaris OE. The only additional considerations are that the procedure should be done at the Admin_Low label, and the directory ~ftp/pub should be an MLD. The home directory for ftp should not be an MLD because everything but the contents of the pub directory is the same for all customers, and protected at the Admin_Low label.