The ANTS 2.0 security model
Andrew Whitaker: andrew@cs.washington.edu
1/22/01
Overview
ANTS2 contains a completely new security model versus ANTS
1.x. The previous security model was replaced for three reasons.
First, it relied on deprecated stack-inspection methods in the
SecurityManager class. Second, the 1.x security model only allowed
code to serve as a resource principal (this is a by-product of the
Java security model). Other types of resource principals make sense:
for example, an administrator may have permission to run a new routing
protocol, while an ordinary user cannot. Finally, the ANTS 1.x
security model was not extensible: code was either local (trusted) or
remote (not trusted).
The ANTS 2 security model implemements a simple, extensible security
model. We chose not to build on the Java2 security
model because Java mandates that privledges be associated with code
(see point 2 above). Also, we wanted to maintain Java1.x
compatability.
Implementation
ANTS2 implements a simple reference monitor access control
mechanism. A (logical) access control matrix describes principals
and permissions inside ANTS.
All of the classes pertaining to the security model are in the
ants.core.security package. Resource principals are represented by
the Principal
class, and permissions are represented by the Permission
class. All access control checks are mediated by the static
ReferenceMonitor
class:
ReferenceMonitor.checkPermission(Principal who, Permission what);
An abstract Policy
class represents the access control matrix. There
are two ways to specify the system security policy. First, a default
security policy is described in the SecurityDefaults class. Second, a
default policy can specified in the ANTS configuration (described below).
Policy
A custom security policy can be loaded by adding the '-policy
file
' flag to the node command in the ants
configuration file:
node 12.12.12.2 -policy policy.ser
where policy.ser is a file containing a serialized Policy
object.
Most users will be content with the policy contained in the
SecurityDefaults class. SecurityDefaults recognizes the following
principals:
- Admin: The PrimordialNode and the shell
- Bootstrap: The principal assigned to applications during startup
- LocalUsers: Local applications and protocols
- RemoteUsers: Remote applications and protocols
- DanteUser: The principal designed for the Dante client and server
- RouteUser: The principal designed for the routing protocol
And, SecurityDefaults defines the following basic permissions:
- MODIFY_ROUTES: Ability to modify the routing table.
- READ_NEIGHBORS: Ability to read the table of
immediate neighbors.
- MODIFY_NEIGHBORS: Ability to modify the table
of immediate neighbors.
- SHUTDOWN: Ability to shutdown a node (i.e., a process).
- LOG: Ability to write to the log files.
- SET_ADDRESS: Ability to set the Node's address.
- READ_PHYSICAL_PROTOCOL_SPEC: Ability to read
the physical protocol specificiation used by the node.
- READ_PHYSICAL_ADDRESS_SPEC: Ability to read
the physical address specification used by the node.
- LOCAL_SEND: Ability to send a capsule.
- START_THREAD: Ability to start a thread.
- ADMIN_PERMISSION: A permission that grants all
operations.
See the actual source of SecurityDefaults for the default associations
between principals and permissions.
By default, new protocols and applications are assigned as listed
above. The principal for an application can be
specified in the configuration file using the '-principal name
' flag.
Principals are NOT case-sensitive:
application ants.apps.dante.DanteServer -principal DanteUser
Notes
There is currently no policy editor that produces serialized policy
objects. As a stopgap measure, the SecurityDefaults.main method
writes the default policy to a file. We feel it is useful to gather
input on what types of security policies are useful before
constructing such a tool.