unifying contracts, permissions, and capabilities

7.5:

merge:

. dynamic permission setting .

. sometimes a var needs {read, write, exe} status under prgm control;

eg, locals of a program

which are external to that program's subprograms

can specify which subprogram can have what access .

. it can create local names dynamically

-- a filesystem that is local to a program .

. it can either statically declare var's as const,

or dynamically set permissions like this:

obj`access(user: rwe) .

. imagine that your program controls variables

with exactly the same power with which you control files:

not only do you have creation-time or compile-time control

of how a variable can be accessed;

you also control at run-time, whether to create a new variable,

what to name it, and how it can be accessed .

. this is thinking like a lisp programmer:

the simplest path to automating your intelligence

is to give your automation

all the same controls that your intelligence has,

so that you can code it just the way you do it .

. it is also simplifying a language

to unify all similar features .

. the next step is moving from permissions to capabilities .

. rather than obj's saying who has what access;

the agents come with contracts that explain

what access they need,

and then the system insures

that they stick to their contractual access limits .

7.6:

unifying permissions with cap's is part of oop contracts,

simple objects like Number have an empty contract:

they don't interact with anything .

. complex contracts include files used, files kept,

other objects or systems being communicated with,

info being communicated,

7.7: adda/dimensions of contracts:

. contracts are usually literals,

an immediate value that the compiler can use,

but they also need to be parametric (a parameter of generics)

and inheritable from employer .

7.23: adda/capabilities:

. adda does not have to be inefficient in its total control of resources:

its allowances are set as read-only pointers .

. the capabilities are expressed as

read-only pointers to the allowed functions .

. if capabilities change,

the pointer becomes invalid,

and the process then throws an exception when it tries to use it .

. after looking at the modularity of rsbac,

I was thinking that was really inefficient,

but combined with my idea for adda here,

the expensive decisions have to be made only once,

apon declaring a need for the object,

and often that can occur during compilation .

--. some notes on rsbac:

Rule Set Modeling of a Trusted Computer System,

Generalized Framework for Access Control (GFAC)

. the clear separation between

Access Enforcement Facility (AEF),

Access Decision Facility (ADF)

with

Access Control Rules (ACR)

and Access Control Information (ACI).

The AEF, as part of the system call function calls the ADF,

which uses ACI and the rules

to return a decision and a set of new ACI attribute values.

The decision is then enforced by the AEF,

which also sets the new attribute values and, in case of allowed access,

provides object access to the subject.

The Access Control Enforcement Facility (AEF)

intercepts every security relevant system calls,

compiles them and performs a request to the

Access Control Decision Facility (ADF).

The ADF will ask every Decision Module

for its opinion on this request.

The answer from every module is combined by the ADF

with a restrictive metapolicy,

giving a final answer that is sent back to the AEF.

The object is accessed normally

if access has been granted previously .

If everything went without denial or error,

the AEF sends a notification to the ADF.

The ADF tells the modules to update their attributes

from the data structures.

The ADF sends back an acknowledgement to the AEF.

Control and optional data are returned to the process.

7.7: addm/unifying cap's with permissions:

. great, I found a good description of a capability!

now I can figure out how it's related to file permissions .

. in the simple permissions system,

your acct is associated with either the user or admn role;

and, when you ask for a view of available files,

you are handed virtual cap'keys that depend on your role:

admn's have free access,

and users get what the admn's give them .

. any program your role uses will inherit

the virtual cap'keys due your role .

. in the role-based access control system,

there are special groups that users can belong to:

{ power users, backup tech's, ... various special roles};

so then file access depends on what group

your acct is a member of .

. again, you have to be careful of what role you're playing

because the tools you use will be inheriting your cap'keys .

. in a cap'key system,

a program will not inherit your role,

instead the system will inform you that your new program

is wanting access you haven't given it,

and then provide you with a menu of all the cap's you have:

per-folder permissions, net activities, ... .

7.14:

. I had conceived the cap' problem by this typical situation:

I have an app that should do a job on one object and not other .

. now is it ok if this app calls another app to do something with this obj?

. my assumption was that I can't trust this app anyway,

so I minimize its destructiveness by saying whatever it does

will only happen to the selected obj;

but there must be some limit to this:

if it can call something that can transitively call on-line,

my obj -- with personal info -- just went online .

. this is called the confinement problem,

and it's solved the way you would think:

your app needs permission to reach on-line

and to reach any other app that may transitively reach online .

. revocation:

how can you revoke a cap'key given to an app?

you need to send it a proxy, like a pointer,

but instead of leaving the pointer dangling,

it creates a situation where

the proxy's target has been instructed to

deny any additional services .