Approaches to control downloadable/mobile executable content
============================================================

1. "Extensible Security Architectures for Java"
Authors: D. Wallach, D. Balfanz, D. Dean. E. Felten
Technical Report, Princeton Univ., April 1997

- principals are digital signatures accompanying applets
- principals map one-to-one with private keys
- the signatures represent endorsements of the code
by the signer

- policy engine which can store security policy decisions
on stable storage, answer questions about the current policy,
and query the user when an immediate decision is necessary
- pre-define groups of common privileges and give them 
user-friendly names (e.g. "typical game privileges" which might
refer to specific limited file system access, full-screen graphics,
and network access to the game server)
- such groupings allow a single dialog box to be presented to the 
user

3 approaches:

a. capabilities:
----------------
- all system resources are represented by capabilities
- an applet's top-level class is passed an array of capabilities
when initialize
- the system evaluates its security policy before starting the applet,
then passes it the capabilities for whatever resources it was allowed
- if an applet is to be denied al file system access, for example,
it need only not receive a file system capability
 
b. extended stack introspection:
--------------------------------
- each Java class is annotated with the set of principals who 
signed it
- the policy engine stores an access matrix identifying which 
principals may access which targets in the system
- when code wishes to use a privilege, it must explicitly enable
that privilege
- if the policy engine permits the access, an annotation is recorded
on the call-stack
- when a class which manages a potentially dangerous resource 
wishes to verify that somebody is permitted to use that resource, it
can examine the call-stack for these annotations

c. type hiding:
---------------
- a given security policy is enforced by controlling how
names in a program are resolved into runtime entities
- an entity can either be removed entirely from the name space
(thus causing mentioning its name to result in a runtime error)
or its name can be caused to refer to a different entity which is
compatible with the original
- environments for security policies can be created which replace
sensitive classes with compatible ones that check their arguments and
conditionally call the original classes



2. "Building Software Systems that Flexibly Control Downloaded Executable 
Content"
Authors: T. Jaeger, A. Prakash, A. Rubin
In Proc. of the 6th USENIX Unix Security Symposium, San Jose, CA, July 1996


Protection model:
-----------------
- principals (e.g users, groups, services) execute processes that
perform operations (e.g. read, write) on objects (e.g. files, devices).
- the permissions of a principal to perform operations in objects are
called the access rights of the principal
- a set of access rights is called an "access control domain"
- the access rights assigned to content should be enforced for the content
and any programs controlled directly by the content 
- access to the following types of objects needs to be controlled:
(a) application objects: a process can read and write objects in its memory
(b) file system: a process cam perform read, write and execute operations
(c) applications: a process can execute another application by creating a 
process for that application
(d) processes: a process can comunicate with other processes via pipes or
the file system
(e) environment: a process can execute its environment's scripts and
and read and write its environment variables
(f) network services: a process can communiacte with a service on the
network using a socket
(g) URLs: a process can download and read system objects by specifying a URL

Main tasks of the architecture:
-------------------------------
- authenticating content
- determining the access rights of content
- enforcing the access rights

Assumptions in the design of the architecture:
----------------------------------------------
- existence of a public key infrastructure that can be used to securely 
obtain the public key of any principal (thus, any principal can verify the
source and integrity of a message signed with a private key)
- identification of any I/O command in the content language (this is necessary
to control access to system objects)
- the operating system has an unmodified trusted computing base, protects
process domains, and provides authentication of principals (e.g. Trusted Mach
satisfies these requirements)

Components of the architecture:
-------------------------------
(1) local system services for access control
(2) a trusted, application independent interpreter (referred to as browser):
(3) an application-specific interpreter (optional)
(4) an interpreter for executing downloaded content

Functions of the respective components:
---------------------------------------
(1) provide operating system services for controlling operations external 
to the interpreters
(2) controls access to system objects by the application-specific interpreters
and downloadable content
(3) controls access to application objects and specifies the access rights of
downloaded content within its limited domain

Principals:
-----------
(a) downloading principal: the principal who downloads and executes the
content
(b) remote principal: the principal responsible for the content
(c) system administrator: a trusted principal who understands the structure
of the downloading principal's system

Access control model:
---------------------
- a principal group is a set of principals with the same access rights
- an object group si a set of objects which are grouped for expressing
common access control requirements
- access rights of a principal group are defined by two types of 
specifications:
(a) domain rights: a tuple {p_group, allowed_ops, object_group} which 
describes a set of operations which the principal group p_group can perform
on an object_group
(b) exceptions: a tuple {p_group, precluded_ops, object_group'} which 
describes a set of operations which the principal group p_group is precluded
from performing on an object_group
- exceptions take precedence in the authorization mechanism; an operation is
granted only if a domain right grants the operation and no exception exists
that may preclude the operation

Downloading content:
--------------------
- content is downloaded in a content message which has 3 purposes:
(1) to provide the content
(2) to determine which interpreter should execute the content
(3) to authorize the execution of the content in that interpreter

- content message == quintuple (r, c, t, a, s), where:
(1) r is the identity of the remote principal
(2) c is the content
(3) t is the content type
(4) a is the content's authentication information
(5) s is an optional session identifier (for computations involving
multiple interactions)

- the content type is a MIME type of the form browser/application, where
browser refers to the fact that the content is controlled by the browser
interpreter, and application identifies an application-specific interpreter
in which the content will be executed (the .mailcap file is used to store
this information)
- the authentication information is a double a = (n, i), where n is a nonce
and i is the integrity verification field
- the nonce is a random value provided to prevent an attacker from replaying 
old messages (a timestamp and a per-remote-principal counter are used as the
nonce)
- if public key cryptography is used, the integrity verification field i is a 
digital signature of a message created from the concatenation of the remote 
principal name, content, type, and the nonce
- if symmetric key cryptography is used (for performance reasons), the 
integrity verification field i is a MAC computed with a hash function such as
SHA

Enforcing access rights:
------------------------ 
The browser:
(1) authorizes content operations
(2) provides safe implementations of these operations
(3) enables controlled execution of external software and network services

- authorization procedure:

authorize(args arg_types arg_ops)
	for arg in args, arg_type in arg_types, ops in arg_ops
		find object group for arg and arg_type
		for op in ops
			if domain rights grant op AND 
			no exception precludes op on arg then continue
			else return FALSE
	return TRUE

- once authorized, the browser can execute the procedure
- the browser provides safe implementations of open, socket, env and exec
operations; a call to authorize checks the content access rights prior to
calling the actual operation; since these commands are only available in
the browser and are protected by the authorization operation, only authorized
accesses to system objects are possible	



3. "A Secure Environment for Unstrusted Helper Applications"
Authors: I. Goldberg, D. Wagner, R. Thomas, E. Brewer
In Proc. of the 6th USENIX Unix Security Symposium, San Jose, CA, July 1996

Aim:
----
- to confine the untrusted software and data by monitoring and restricting
the system calls it performs

Threat model:
-------------
- helper applications and data downloaded by Web browsers are considered
untrusted and must be placed outside the host's trust perimeter

Design:
-------
- "reference monitor" style
- user-level mechanism that monitors an untrusted application
and diallows harmful system calls
- the untrusted application should not be able to access any part
of the system or network for which it has not been granted permission
(i.e. sandboxing)
- modular design for the program (called Janus) which is composed of:
	- a framework
	- dynamic modules, used to implement various aspects of a
	  configurable security policy by filtering relevant system calls

Implementation:
---------------
The OS:
- OS chosen is Solaris 2.4, which offers a good process-tracing facility 
through the /proc virtual file system

The policy modules:
- policy modules are dynamically loaded at runtime, so that different 
security policies can be configured for different sites, users, or applications
- policy modules need to make decisions as to:
	- which system calls to allow (e.g. close, exit, fork and read are 
	always allowed in the sample modules)
	- which system calls to deny (e.g. setuid, mount and chdir are always
	denied in the sample modules)
	- for which system calls a function must be called to determine what
	to do (e.g. open, rename, stat and kill): in this case the arguments of
	the system calls must be checked against the configurable security 
	policy specified in the parameters given to the module at load time

The framework:
- framework reads at startup a configuration file that lists which of the
modules should be loaded and optional parameters to pass to the modules
(e.g. "path alllow read, write /tmp/*" would load the path module and
would pass it the parameters "allow read, write /tmp/*" at initialization 
time)
- for each module specified in the config file, dlopen is used to dynamically
load the module into the framework's address space
- the list of system calls and associated values and functions in the module
is then merged into the framework's "dispatch table", which provides a linked
list that can be traversed to decide whether to allow or deny a system call
- the application to be run is fork-ed as a child process by the framework
and confined to a sandbox directory (in /tmp, a subdir with a random name)
- the application runs until it performs a system call; at this point, it is
put to sleep and a tracing process wakes up; the tracing process determines
which system call was attempted and then traverses the apropriate linked list
in the dispatch table, in order to determine whether to allow or deny the
sytem call

Installing the secure environment:
----------------------------------
- the most covenient solution is to specify the janus program in a mailcap
file - e.g.:
image/*; janus xv %s
application/postscript; janus ghostview %s
video/mpeg; janus mpeg_play %s

Limitations:
------------
- only helper applications which do not legitimately need many privileges
can be successfully run by the framework 
- specialization for a single operating system



4. "Confining Root Programs with Domain and Type Enforcement (DTE)"
Authors: K. Walker, D. Sterne, M. Badger, M. Petkac, D. Shermann, 
K. Oostendorp
In Proc. of the 6th USENIX Unix Security Symposium, San Jose, CA, July 1996

Background on DTE:
------------------
- DTE associates a domain with each running process and a type with each
object (e.g. file, packet)
- **kernel-level** DTE subsystem compares a process's domain with the type of
any file or the domain of any process it attempts to access
- DTE subsystem denies the attempt if the requesting process's domain does
not include a right to the requested access mode for that type
- DTE restricts root as well as non-root processes and operates in addition
to traditional Unix access bits
- DTE partitions a system according to the "principle of least privilege",
which grants each program only those access rights needed to perform its
assigned function
- DTE uses a human-friendly high-level language for specifying security 
policies called DTEL (DTE Language)

Constructs of DTEL:
-------------------
(1) "type" statement: 
- declares equivalence classes of data that are treated differently by the 
policy
(2) "domain" statement: 
- defines the access modes a process running in that domain is permitted to 
use when accessing objects of specified types (e.g. read, write, execute) or 
interacting with processes in other domain
- a process running in domain A may "transition" to domain B only by executing
one of B's entry points via exec()
- a process may transition to another domain by explicit request only if its
domain includes the "exec" mode of access to the target domain
- alternatively, a process may be automatically transitioned if its domain
includes "auto" mode access to the target domain
(3) "initial_domain" statement: determines the domain in which the system's
first process (usually /etc/init) starts
(4) "assign" statement: binds types of data to specific files or directories

DTE access modes:
-----------------
r: read
w: write
x: execute
d: directory traversal
c: creation --> extension of write mode; it identifies the type attribute
automatically associated with new objects if the creating process does not
explicitly specify a type

Protecting system binaries from Rootkit:
----------------------------------------
- Rootkit is chosen as an example of a hacker's toolkit: once an attacker
has penetrated a system and obtained root permission, Rootkit builds a 
hidden backdoor into the system by modifying several Unix programs and
utilities such as login, ls, netstat and ps

DTE strategy:
-------------
- create a special adminstrative domain having write access to system binaries
and their containing directories
- allow transitions into the domain only after performing strong user 
authentication and authorization checks
- all other processes, including root daemons, run in less powerful domains
that lack the write access
- if an attacker subverts a root daemon, its accesses will be confined 
according to the daemon's domain, and the attacker will be unable to replace
the programs that constitute Rootkit's hidden backdoor

DTE policy implementing the strategy:
-------------------------------------
(a) the policy partitions all processes into 4 domains:
(1) daemon_d: a domain for system daemons including init
(2) login_d: a domain for the DTE-enhanced login program
(3) user_d: a domain for ordinary user sessions
(4) admin_d: a domain for system administrator sessions

- the daemon_d domain includes an access right for transitioning to the
login_d domain so that the daemon that invokes login (getty) can start login
in the proper domain
- the login program acts as a gatekeeper, determining which user sessions 
should be started in the user_d and admin_d domains; consequently, the login_d
domain includes rights that allow transitions to those 2 domains

(b) all information in files and other objects is categorized into 5 types:
(1) generic_t: generic information created by user processes
(2) binaries_t: system binaries
(3) readable_t: Unix configuration files to which most processes need only
read access
(4) dte_t: DTE security meta-data 
(5) writable_t: miscellaneous system-generated information that many processes
may need to update

DTEL representation of the policy:
----------------------------------

type generic_t, binaries_t, dte_t, readable_t, writable_t;

domain	daemon_d = (/sbin/init),
		   (crwd->writable_t),
		   (rxd->binaries_t),
		   (rd->generic_t, readable_t),
		   (auto->login_d);

domain	login_d	 = (/usr/bin/login),
		   (crwd->writable_t),
		   (rd->generic_t, readable_t, dte_t),
		   setauth,
		   (exec->user_d, admin_d);

domain	user_d	 = (/usr/bin/{sh, csh, tcsh}),
		   (crwxd->generic_t),
		   (rwd->writable_t),
		   (rxd->binaries_t),
		   (rd->readable_t, dte_t);

domain	admin_d	 = (/usr/bin/{sh, csh, tcsh}),
		   (crwxd->generic_t),
		   (rwxd->writable_t, binaries_t, readable_t, dte_t);

initial_domain	 = daemon_d;

assign -r	generic_t	/;
assign -r	writeble_t	/usr/var, /dev, /tmp;
assign -r	readable_t	/etc;
assign -r -s	dte_t		/dte;
assign -r -s	binaries_t	/sbin, /bin,
				/usr/{sbin, bin}, /usr/local/bin;


Securing a Web browser:
-----------------------
- using DTE, users can be forced to run Web browsers in a constrained domain
that restricts access to the system's critical files
- sample policy presented which restricts NSCA's Mosaic and Netscape
- browsers are allowed to write only:
	- files that capture the history between sessions
	- other files in a designated scratchpad subdirectory in the user's
	home directory (the browsers may also download files into this 
	subdirectory)
- browsers cannot delete, modify or overwrite any other files in the system,
even if root privilege is obtained
- in addition, all files created in a browser's domain are labeled with a type
to which neither the browser, its progeny, nor any other process runnning in
an ordinary user's domain has execute access rights
- consequently, a browser cannot import or manufacture binaries that it or
other processes are able to execute, so it cannot plant Trojan Horse binaries
that users might execute inadvertently

Sample DTEL file for Web browser restriction:
---------------------------------------------

type	browser_t;
domain	browser_d =	(/usr/X11R6/bin/{Mosaic. netscape}),
			(crwd->browser_t),
			(rwd->writable_t),
			(rxd->binaries_t),
			(rd->generic_t, readable_t);

assign -r	browser_t	/usr/home/ken/{.MCOM-HTTP-cookie-file,
				.MCOM-preferences, .MCOM-global-history,
				.MCOM-cache, .MCOM-bookmarks.html};