Transcript 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)
–
•
Trusted Solaris 2.5 – 8, based on CDE, X11
–
•
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 readonly, 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