Chapter 8

Case Study: Solaris Trusted Extensions

Chapter Overview

• History and Introduction

• Trusted Extensions Access Control

• Solaris Compatibility

• Trusted Extensions Mediation

• Process Rights Management(Privileges)

• Role-Based Access Control (RBAC)

• Trusted Extensions Networking

• Trusted Extensions Multilevel Services

• Trusted Extensions Administration

History

• 1990: Sun OS MLS 1.0 based on Sun-view

• 1992: Sun OS CMW (Compartmented Mode Workstation Requirements)

– Supported MAC, floating information labels

• Trusted Solaris 2.5 – 8, based on CDE, X11

– Control Access, RBAC, Label Sec Protection

• 2001: Solaris 10.3 with the Trusted Extensions including MLS support of GNOME

– Kernel and windows system donated to open source community

Introduction

• Solaris supports both traditional DAC and label-based MLS. The latter requires the Trusted Extensions Layer.

• Complete mediation for file access, network access, printing and devices.

• Labeled objects

• Reduced rights on root processes, similar to DTE

• Focus is Confidentiality.

• Trusted extensions included: modifying kernel, new administrative applications, and modifying some others.

Trusted Extensions Access Control

• MLS – BLP with restricted write-up.

• Confinement Similar to DTE

• ad-hoc work-arounds

• Information flows described by sensitivity levels and categories.

• Roles to limit the rights of root processes.

• Discrete rights (one of 68) may be granted to an application

Trusted Extensions Access Control (2)

• Labels consist of classifications/levels + compartments/categories.(256+256 bits)

• Mapping of names to labels is specified in a DB private to the Trusted Path

• Label ranges = clearances, assigned to users, network attributes, workstations, devices.

• Two default labels: admin_low & admin_high

Solaris Compatibility

• Care was taken to make all old applications run under Solaris, by:

– not changing file attributes

– Keeping the OS API unchanged.

• Protection was achieved through “Solaris Containers” (zones), which runs applications virtualized in isolation.

The Unix chroot facility

• A means by which a process can be run restricted to a subtree of the whole tree.

• Requires presence of all files and resources required by the process in the subtree.

• Is the basis for BSD jails and Solaris zones.

Trusted Extensions Mediation

• Mediation is done at the zone level:

– Labels are associated with zones and network endpoints.

– Zones are assigned sensitivity levels.

– Customized with their set of files and system resources.

– Mounted file system labels are derived from the host/zone mounting the system. Files/directories have the same label as their mount point. - No modification to file system structure required.

– Processes are uniquely labeled according to their zone and isolated from processes in other zones.

– Zones are usually cloned; copy on write is used for writable files.

File Mediation

• Local file systems are only writable at the zone's label.

• Can be shared via loopback or NFS mounts.

• MLS protections are enforced on the mounts

• Some Integrity protection is also provided (shared file systems are mounted read-only, labeled admin_low; imported file systems also import their integrity label)

File Mediation II

• Writing up to regular files is not possible because the files are not visible; the only way to write up is through named pipes, loopback mounted into higher level zones.

• Labels determined at mount time based on host and zone labels: kernel ensures MLS policy.

• Reading down, exporting files, directories up, policy is configurable when zone is booted.

• Each zone has an upper bound privilege.

• Communication within a zone is Unix traditional.

Labels example

Process Rights Management(Privileges)

• Each process runs with a set of privileges: root processes can have some privileges taken away, other processes can have some privilege(s) added.

• (Linux calls these capabilities, see man 7 capabilities)

• Makes it easier to enforce least privilege.

• 68 discrete priveleges, managed with Service Management Facility, RBAC or ppriv(1)

• Each process has four privilege sets:

– I Inheritable set

– P Permitted set

– E Effective set

– L Limit set

Solaris privilege sets

Privilege Bracketing and Relinquishing

• Privileges can be enabled/disabled, dropped or relinquished as needed by a program.

• A process becomes “Privilege Aware” when it manipulates one of its privilege sets.

• Note six privilege sets: L, I, oE, oP, iE and iP (Limit, Inheritable, and observed/implementation Effective/Permitted)

• If a process is not privilege aware, then oE is set to iE unless euid = 0 (then oE=L), similarly oP = iP unless one of euid, ruid or suid is 0, in which case oP=L.

• When a process becomes privilege-aware, then iE = oE and iP = oP. Now oX is invariant under uid changes.

Privilege Bracketing and Relinquishing II

Returning to non-privilege aware state requires that if the ID is 0, then privilege set = L. Attempted on exec.

When a process is no longer privilege aware, its i-privilege set may be changed for root ids. For non-root-ids, privilege is set to inheritable subset already there.

Initially, try E' = P' = I' = L&I on exec.

Privileges whose absence can cause malfunctions are called “unsafe”; if a setuid process lacks an unsafe privilege, the setuid will not be honored.

Controlling Privilege Escalation

• A single privilege may lead to a process gaining more privileges. The security policy requires explicit permission for those additional principles.

• Manipulation examples: /dev/kmem /dev/dsk/*, setuid(0...)

• Try to limit the number of processes running uid 0.

• Also consider safeguards (for example: OK to lock memory, but how much?)

Role-Based Access Control (RBAC)

• RBAC is one of the most important MAC policies available.

• Idea is that the label for a user corresponds to the tasks they are supposed to accomplish.

• Introduced in Solaris 8.

• Figure follows...

Relationship between RBAC elements

RBAC Authorizations

• The RBAC authorization definitions are stored in a database called auth_attr.

• Lines in the database consist of an authorization name followed by a list of privileges/commands.

• Names ending in grant allow the assignee to delegate authorizations.

• Authorizations are used in concert with other system access control mechanisms but are checked after the regular Unix controls.

RBAC Rights Profiles

• Collection of overrides

• Can contain authorizations, commands and other rights profiles.

• Can be assigned to a role or a user.

• Optionally, a command can be assigned attributes: uid/euid, gid/euid, and privileges which may be added or limited to the command.

Roles

• Special identity

• Similar to a normal user.

• Has own UID, GID, home directory, shell and password.

• Differs from a normal user in two ways:

– It is not possible to log into a role.

– A role can only be assumed/accessed by a previously authorized user.

• cron and batch are independent of role assumption.

Converting the superuser into roles

• root can no longer log in directly.

• Access to root is only allowed to those possessing the proper credentials and explicit approval.

• Many rights profiles; by default:

– Primary Administrator (all root privileges)

– System Administrator

– Operator

Trusted Extensions Networking

• Single-level remote hosts are assigned an implicit level which is recognized based on their IP address.

• Multi-level remote hosts are trusted to use a range of levels which they specify on each packet using Commercial IP security Option (CIPSO).

• The network attributes database is kept in an LDAP directory.

• Ipsec is used for integrity protection..

• Zones can be assigned one IP address, many addresses, or they can share an IP address with other zones by labeling packets.

Trusted Extensions Multilevel Services

• By default:

– X11 with CDE or Gnome

– Printing: Internet protocol or BSD protocol

– NFS

– LDAP

– Label Translation Service

– Name Service Cache Daemon

• Optionally Web servers, Secure Shell, etc. (via Trusted Path)

• Many services polyinstantiated in each zone.

Trusted Extensions Multilevel Services II

• Users log in via Trusted Path, authorized to their multilevel desktop (CDE or GNOME) and presented with a range of labels to work with. The window system starts the session in the users default zone.

• Provisions are available to change the label of the workspace or create additional workspaces.

• Windows are labeled according to the zone/host.

• Cut/paste and drag and drop is mediated by the Trusted Path.

Multilevel Cut and Paste