module permissions

adda/cstr/module/permits:
12.8: intro:
. just as corporations are composed of
people with various levels of trustability
and access to classified resources,
a program is composed of modules
that are trusted with various sensitive resources
by being being granted a permit to gain access .
. obvious things in need of permissions
include access to the file system, internet,
or the user's contact list .
. recently under consideration
is the idea that modules need to get permits
before they can access any other modules .

10.4: user-oriented compiler-generated:
. if the specification doesn't request permits,
it's the compilers job to
translate the current implementation
into a set of user-centric permits
(capabilities that the user can relate to,
such as, what privacy is at risk,
how the user's system can be modified
and how that could affect the user).

10.4: mis: requiring permits for each module used:
. if we were to require a permit for
each module that was used by a module,
any components of that module
should inherit those permits
(a module can come in several pieces
because it can have nested subprograms
that are separately compiled stubs).

10.6: user-centric and client-specific:

. a module will import other modules
and I assumed that would implicitly become
part of the module's specification,
but that would mean that
any change in the implementation
could too easily entail
a change in the specification .
[12.8: well:
. most modules are not sensitive resources
and there is no reason to declare their use .
]
. should access to other modules require a permit?
. that can involve a variety of capabilities
which then require permissions from
any account owners who could be affected .

characteristics of a permit:

# user-oriented:
. the capabilities of module
should be phrased in a way that is
relevant to casual users of computers .

# object-oriented:
. the permit is phrased in a way
that describes which files are leaking info,
and which are being modified .

# client-specific:
. client refers to callers;
when one module calls another,
the caller is a client of the called,
and the called is a server of the caller .
. permits should consider transitive access; [12.8:
for instance, if a module doesn't have
a permit to access the contacts list,
then either it can't use any module
that does have access to the contacts list,
or the server inherits the client's restrictions .]

[10.4: specification/expected permits:
. a tool could have certain permits
and then request that it be called only by
those units having the same or greater permits .
10.6:
. that would be a dimension of the specification:
callers not only have inputs of a certain type,
they also have certain permits .]

. in order to support client-specific permits,
whenever a tool has contacts access,
it is honoring all permit denials,
by knowing for each of its clients,
which permits they have .

. on the other hand, consider compilation;
we may deny a module the ability to
generate executable scripts or binaries,
but we may still give them access to the compiler,
because executables from the compiler
are known to undergo safety checks .
. the compiler needs to know
what permits its client has;
if the client's input to the compiler
is a subprogram that asks for
greater permits than the client has,
then the client is denied compiler service
because the client is trying to modify itself
in a way that escalates its own privileges . [12.8:
. if such a self-modifying program
is prevented from continuing,
then the run-time system can ask the account owner
if the new permissions should be granted,
in order allow the client to operate .]

. the compiler is an example of
supervised access vs direct access
to a sensitive resource such as
a subprogram's self-modification .
-- this is the typical reason for
untrusted code calling privileged code .