Chapter 8 Case Study Solaris Trusted Extensions Chapter

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) – • Trusted Solaris 2. 5 – 8, based on CDE, X 11 – • Supported MAC, floating information labels 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, o. E, o. P, i. E and i. P (Limit, Inheritable, and observed/implementation Effective/Permitted) • If a process is not privilege aware, then o. E is set to i. E unless euid = 0 (then o. E=L), similarly o. P = i. P unless one of euid, ruid or suid is 0, in which case o. P=L. • When a process becomes privilege-aware, then i. E = o. E and i. P = o. P. Now o. X 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: – X 11 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