Chapter 8

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