Browse Prior Art Database

Unprotected Libraries on a Protected Machine

IP.com Disclosure Number: IPCOM000111150D
Original Publication Date: 1994-Feb-01
Included in the Prior Art Database: 2005-Mar-26
Document File: 2 page(s) / 98K

Publishing Venue

IBM

Related People

Fishel, EA: AUTHOR [+4]

Abstract

A method for allowing an unprotected library on a protected system is described. Locally evaluated applications can gain performance benefits by using fast interfaces to specific objects that are only allowed to exist within unprotected libraries.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Unprotected Libraries on a Protected Machine

      A method for allowing an unprotected library on a protected
system is described.  Locally evaluated applications can gain
performance benefits by using fast interfaces to specific objects
that are only allowed to exist within unprotected libraries.

      Many system architectures define pointers with capabilities.
Of these two types of pointers, system pointers and space pointers
can have capabilities.  These capabilities allow someone possessing
the pointer containing capabilities to use the pointed to object when
they do not have any public or private authorities to the object.
System pointers can support the following capabilities:

o   Object operational authority

o   Object management authority

o   Object existence authority

o   Data read authority

o   Data add authority

o   Data update authority

o   Data delete authority

      Space pointers always have the data capabilities described
above.  This means that if someone has a space pointer to a space
they can use that pointer to read or write that space.

      Because of the capabilities incorporated into the pointer,
anyone with a space pointer to a user domain object can read or write
that object even if they have no authority to the object.  For a
secure system, such as one with a C2 Department of Defense (DOD)
rating, the use of pointer capabilities is not allowed.  One reason
pointer capabilities are not allowed is that there is no way to audit
the passing of secure data from one user to another.  This is because
when more than one job is allowed to use user domain objects to store
and retrieve pointers, it allows those jobs to use the pointers to
share data without an audit record being generated.  A second reason
is that any user who can save a space pointer in a permanent user
domain object can use the pointer in the future to access objects and
data they are no longer authorized to, again without generating an
audit record.

      From a security point of view, this issue was resolved by
restricting the creation of user domain objects on a secure system
and providing APIs so that applications could still change and
retrieve the data.  This solution provided all the security and
integrity that is required.  It also provided the ability to audit
the actions of user or the actions on objects.  Unfortunately, it
caused a serious problem for our customers and third party
application providers, because it meant that application providers
would need to make extensive code changes to their applications to
change from using MI instructions and pointers to using an API and no
pointers.  The resulting code would be much slower.

    ...