Print-friendly Version

This article provides a general overview of the Trusted Solaris 8 networking feature support relevant to the IP version 6 (IPv6) protocol. A description of the design and implementation methodology is included.

Information in a multilevel-secure operating system, like Trusted Solaris 8, is assigned a label. The label contains security attributes used to enforce access controls required by a security policy. Labeling IP packets is an effective means of extending security attributes and controls across a network.

Estimates of the cost, worldwide, to repair damage caused by viruses, Trojan horses, and the like exceeds $1 trillion per year. As a result, multilevel security is being used outside the traditional government and military circles because, when combined with other technologies, it has the ability to meet emerging IT security needs.

Trusted operating systems, such as Sun's Trusted Solaris, take a proactive approach to the security problem by providing exceptionally strong features and assurances in accordance with access controls. These systems provide a Trusted Computing Base (TCB) to enforce security policy. Security policies are the set of rules that determine who is allowed to accesses what and how they are allowed to access it. The trustworthiness of a system originates from the guarantee, up to a certain level of assurance, that all accesses to objects by subjects from software running on the TCB are controlled and cannot, therefore, compromise the protection mechanisms of the TCB.

Multilevel-secure operating systems, such as Trusted Solaris, are operating environments built around the Bell-Lapadula mathematical and foundation model. This model was originally designed for the military environment where data is classified into multiple levels of sensitivity (such as unclassified, confidential, secret, top secret) and people are assigned a clearance, which designates the highest level of sensitivity they are allowed to read.

The model follows two rules:

• Write-up
• Read-down

The write-up rule states that a subject can only write to an object at a higher level. The read-down rule states that a subject can only read from an object at a lower level. Together, these constitute Mandatory Access Control (MAC) rules.

The Bell-Lapadula model proves that if these two simple rules are rigorously implemented, no information can leak from a higher security level to a lower one.

Being a multilevel-secure distributed operating environment, Trusted Solaris 8 implements the MAC rules plus additional protection mechanisms:

• Trusted Path - to prevent users from Trojan horse attacks
• Role Based Access Control (RBAC) - to set limitations on what a user is authorized to do within a set of actions defined within a rights profile

In addition, finer privileges are used to:

• Implement the Principle of Least Privilege (PLP)
• Aid in safer remote administration
• Minimizes the damage from buffer overflow-like attacks

TRUSTED NETWORKING OVERVIEW

The protection mechanisms described above are generally achieved by associating every piece of information in the system with a label containing its security attributes. The label of an object, such as a file or a device, might also contain the sensitivity of that object (such as confidential, secret, public, engineering-use only). The label of a subject, such as a process, may contain the credentials of that process (such as owner, clearance, the set of effective privileges it is running with).

Within a single host, the kernel has visibility to all of the security attributes of the information it is accessing, from file systems to device and process tables. However, when a network separates the subject and the object, the receiving operating environment needs to retrieve both the credentials of the remote process and the security attributes of the data, to properly enforce the access control rules. In the Trusted Solaris 8 operating environment, this is achieved by attaching security attributes in a label with an IP packet.

IPv6 versus IPv4

The IPv6 protocol has two main differences from its version 4 predecessor:

• Version 6 has a richer addressing architecture that can accommodate:
  • A wider addressing space (128 bits)
  • More varied addressing types (unicast, multicast, anycast)
  • Additional scopes (link-local, site-local, global)
• Version 6 has a more flexible packet format with a basic header followed by a chain of optional extensions that allows the packet to communicate more information.

Unlike its predecessor, IPv6 did not originally have any explicit labeling. In fact, RFC 2401 foundation specification only suggested that implicit labeling be used with IPv6 packets--by creating a separate IPSec security association per label.

The RFC 2401 draft addressed the limitations of the implicit labeling schema and proposed a generalized labeled security option to be used in a hop-by-hop or destination extension header of the IPv6 packet.

IPv6 Support in Trusted Solaris 8

The security enforcement code in Trusted Solaris 8 resides in security policy modules. These modules can be invoked via policy hooks by the various Solaris kernel modules and utilities. Policy hooks are routines that enforce security policy. The term "hooks" is used because security policy module code is highly structured and well defined, which causes the code to "place itself" appropriately when and where needed. Policy hooks were added to the TCP, UDP, and IP code to handle IPv6 labels that are carried in the destination extension header.

Outbound Traffic

In general, the following steps are taken for outbound traffic:

1. A streams message block arrives from the stream head, with its security attributes.
2. The message is passed to the policy module that performs the export accreditation checks. The policy module determines if the message requires a label (this determination is made based on the security family of the destination host).
3. If labeling is required, then the label is constructed from the message's security attributes, and the transport module is programmed to add a destination extension header with that label.
4. The transport module completes construction of the labeled IPv6 packet and sends the labeled packet to the IP.

Trusted Solaris 8 implements an advanced socket API for IPv6, RFC 2292, which specifies a programming interface to send ancillary data. The IPv6 packet labeling code inside the Trusted Solaris policy routines invoke the kernel-side of that API.

For UDP, the data is interpreted as if it was sent using the IPv6 advanced API version of sendmsg() with a control message containing a hop-by-hop and a destination header. Because the kernel generates the control message, the usual consistency and permission checking steps are skipped.

For TCP, ancillary data can be sent only using per-socket options, but not on a per-packet basis. Furthermore, when TCP transmits a packet that becomes dissociated from a user's sending system call (for example, during a re-transmission), the packet will enter a blocked state and wait for a transmission window in order to slide. Once blocked, the packet will resume transmission when TCP volunteers control packets. For these reasons, labeling cannot be performed when the messages are received by TCP from upstream. Rather, labeling is delayed until the moment the message to the IP is about to be forwarded.

Inbound Traffic

1. An mblk request arrives from the DLPI driver to the IP.
2. The policy module reconstitutes the security attributes of the incoming packet using a template derived from both the originating packet and the destination extension header.
3. If the packet passes the import accreditation checks, it is kept for delivery and the message is then delivered to the correct IP client.

Conclusion
The globalization of the economy, and the growing outsourcing market, are creating new requirements for stronger access controls, remote administration, and secure coexistence of virtually separated domains. Multilevel security products have provided solutions to similar needs in restricted government circles, with high levels of assurance. The Trusted Solaris 8 operating environment is a significant step in integrating these advanced security features for business.

Additional Reading
Advanced Sockets API for IPv6, Stevens, W. and M. Thomas. RFC 2292, February 1998.

Department of Defense Trusted Computer System Evaluation Criteria, US National Computer Security Center. DoD 5200.28-STD, US Department of Defense, Ft. Meade, MD. December 1985 (the "Orange Book").

Generalized Labeled Security Option for IPv6, Belgaied, K. and G. Winiger. The IETF Internet Draft (belgaied-ipv6-lsopt-00.txt), expires August 22, 2001.

Internet Protocol, Version 6 (IPv6) Specification, Deering, S. and R. Hinden, (1998). RFC 2460, December 1998.

IP Version 6 Addressing Architecture, Hinden, R. and S. Deering. RFC 2373, July 1998. Labeled Security Protection Profile, National Security Agency, Information Systems Security Organization, Ft. Meade, MD. October 8, 1999.

Modern Operating Systems, Tanenbaum, A. S. (2001). Prentice Hall. 2001 RBAC in Unix Administration, Faden, G. Proceedings of the fourth ACM workshop on role-based access control. October 28 - 29, 1999, Fairfax, VA USA.

Secrets and Lies, Digital Security in a Networked World, Schneier, B. Wiley Computer Publishing, 2000.

Secure Computer Systems: Mathematical Foundations and Model, Bell, D.E. & LaPadula, L.J. Technical Report M74-244. The MITRE Corporation, Bedford, MA, May 1973.

Security Architecture for the Internet Protocol, Kent, S., and R. Atkinson. RFC 2401, November 1998.

Trusted Operating Systems: Fit and Function, Service Management Strategies, Zammas, J. META Group, File: 832. November 2, 1999.

Trusted Solaris 8 Operating Environment: A Technical Overview
(http://www.sun.com/software/solaris/whitepapers.xml)

June 2001