Dr. Daniel Julius Bernstein

7.25: web.cs/sec/Dr. Daniel Julius Bernstein:
. Dr. Daniel Julius Bernstein
is an authority on computer security;
he's a big fan of extreme sandboxing
(where the app is cooperative)
and safe programming languages.
djb's main page, his papers
(and who they are cited by).

extending the const-var architecture

3.31: addm/extending the const-var architecture:
. what I'm calling the constant-var architecture
makes use of hardware isolation mechanisms
by safely dividing the system into
constant code, and variable data .
. there is another segment to consider:
# write-once-read-many:
. what's variable across process instances
can be constant during execution .
# special permissions:
. the implied permission is that the
data in the process belongs to that process .
. the activation record's resource display
is an example of special permissions:
the process has permission only to
read the resource display, not write to it;
but the supervisor can modify it .

combined hardware-virtual isolation

addm/security/combined hardware-virtual isolation:
2.9: 3.31: intro:

. certain attributes of data are essential to security;
eg, by retagging arbitrary data so that it is
usable as a pointer to code,
we can treat malware data as instructions to follow .
. generally all data can be tagged
just as it is done by xml .

. there are 2 possible ways to enforce
process isolation and ROM attributes:
# HW (hardware) mem'mgt,
# VM (virtual machine) mem'mgt .
. hardware mem'mgt can enforce VM mem'mgt:
the VM's run-time exec never needs to change;
so, HW mem'mgt can see that code as const;
also, any file that the VM is trying to interpret
can be treated by the HW mem'mgt as
something that only the VM process can modify .
. finally, the VM has its own process space
and this should keep other processes
from corrupting its work space .

Mac gets some optional Sandboxing

6.2: news.cyb/dev.mac/sandboxes
Apple brings sandboxing to the desktop:

. most PCs have not been into sandboxing
[because backward compatability was an issue;
smartphone platforms are more recent inventions,
so sandboxing is an obvious good .]
. to access resources within a sandbox,
apps must request “entitlements” [aka, capabilities.]
Android apps must ask the user for permissions
and then the OS constrains the app
to the allowed permissions .
[ but Android apps may be all-or-nothing:
either the user accepts all the requests,
or else the app fails to be usable at all .]
Apple’s iOS sandboxing doesn’t involve the user,
as all permissions are handled by
Apple's App Store evaluators .

[7.25:. in order to be accepted into the app store,
developers must divide their app into modules
so as to more easily explain why each part
needs a particular set of entitlements .][7.20:
Apple decides for the user,
what entitlements are appropriate,
not only for the whole app,
but more smartly, for each of its modules .]

. iOS users can still control certain entitlements:
(eg, opening a list of recent files
or saving documents elsewhere in the file system).

Concerns from Developers:

# no more AppleScript:

[7.20:
AppleScript is a programming language
meant to allow the user to reuse apps
by having scripts make calls to apps .
. if an app wants to reuse other apps,
then it too can use AppleScript
to make calls to other apps;
however, in sandboxing this can't be done,
because,
when an app is entitled to AppleScript
it's entitled to anything AppleScript can do
-- which is basically anything!
. if apps are instead designed to be
reused directly by other apps
then sandboxed apps can still be
entitled to use particular other apps
without having to give them access to
the wide world of AppleScript .]

# no more file system management: [7.20:

. Apple sandboxing asks the user
for each and every file access;
so, apps that need access to many files
or that need to work in the background
are not considered sandboxable;

nevertheless, sandboxing of the file system
could work like vmware's shared folders:
. vmware lets you run an OS in a sandbox
as a virtual machine (vm);
and then gives the vm {read, write} access
to just the folders the user requests
(Virtualbox has a similar feature).
. you can divide your file system by sensitivity levels;
eg, if the sandboxed app has access to the web,
then give it entitlements should be
read-only access to non-sensitives,
and write access to a downloads folder .
. letting sandboxes share folders
is important to generativity .]

. see Jonathan Zittrain's Chapter 7 of
The Future of the Internet and How to Stop It .

can a scripting engine really be safe?

6.1: addx/can a scripting engine really be safe?:

. I just heard that Apple will no longer allow apps to
communicate by sending each other AppleScripts;
instead they need to use each other's API .
. this I found confusing because I had a different understanding
of applescript connectivity:
. apps exported an API that applescript could understand,
and then applescripts could use all such apps .
. I guess what they were saying is that, counterintuitively,
only AppleScript had been able to use such API's:
you couldn't do so from the native lang (objective C).
. anyway, this got me to asking the question:
can a scripting engine really be safe?
here's my yes:

revocability and transivity of capabilities

5.15: adda/cap'based/revocable capabilities:
. I'm seeing how to do revocable capabilities
-- the same way as concurrency:
the client is given the server's mail box,
the client sends a link of who they are
and which client mail box the result is wanted in;
then the client id is ok'd with security
-- asking: (does client x have access to service y ?).
web:
Grand Unified Capabilities/Advantages:

embodies OrthogonalSecurity, FineGrainedHistory,
BidirectionalCapabilities .
. One achieves orthogonal security
in precisely the same way as TransparentPersistence:
by building it in at such a low level
that programmers never see it .
It entails pervasive use of the FacetPattern
(Restrict an interface to obtain a smaller interface
that provides less authority)
and the PrincipleOfLeastPrivilege.
. see security patterns:
FacetPattern
CaretakerPattern
ProtectionProxy
UserPassword
PermissionFlags
TwoKindsOfCapabilities
RevokableCapabilities

5.15: adda/cap'based/transivity of capabilities:
. if you give A access to B, and B access to C,
you are implicitly giving A access to C;
so, if you wanted to deny A access to C,
you have to check the capabilities of
everything A is allowed to call .

evlan.org describes many #addx features

10.31: news.adda/lang"evlan/
evlan.org describes many addx features:

. Kenton Varda's Evlan has many addx features;
but, it "(currently has no type system);
and, it died in 2007.10.1, when the author "(got a real job)!

. what first caught my was cap-based security:

Most of today's computer platforms operate under
a fundamental assumption that has proven utterly false:
that if a user executes a program,
the user completely trusts the program.
This assumption has been made by just about
every operating system since Unix
and is made by all popular operating systems used today.
This one assumption is arguably responsible for
the majority of end-user security problems.
It is the reason malware -- adware, spyware, and viruses --
are even possible to write,
and it is the reason even big-name software
like certain web browsers
are so hard to keep secure.
Under the classical security model,
when a user runs a piece of software,
the user is granting that software the capability
to do anything that the user can do.
Under capability-based security,
when a user runs a piece of software,
the software starts out with no capabilities whatsoever.
The user may then grant specific capabilities to the program.
For example, the user might grant the program
permission to read its data files.
The user could also control whether or not
the program may access the network, play sounds, etc.
Most importantly,
all of these abilities can be controlled
independently on a per-program basis.

. the other main idea like addx
is its being a virtual operating system
which runs on top of any other operating system;
via a virtual machine that is the sole access
to the underlying platform's OS .
. by a complete platform,
he means it is not specialized to be
efficiently accessing all of bloated unix,
but to define what it needs,
and then have the vm access what it needs
for impl'ing the Evlan virtual platform .

adda's secure by language idea:

Even better than implementing security in an operating system,
is implementing it in a programming language:
developers are able to control the capabilities available
to each piece of code independently.
Good practice, then, would be to only give each component
the bare minimum capabilities that it needs to
perform its desired operation.
And, in fact, it is easier to give fewer capabilities,
so this is what programmers will usually do.
The result is that if a security hole exists in some part of your program,
the worst an attacker can do is
gain access to the capabilities that were given to that component.

--[. keep in mind that this won't work without
also implementing security at the hardware level;
this is the level where modularity can be enforced;
otherwise, malware could just jump to
what ever code there is with the permissions it needs .
(see qubes doc's) .]

It is often possible to restrict all "dangerous" capabilities
to one very small piece of code within your program.
Then, all you have to do is make sure that
that one piece of code is secure.
When you are only dealing with a small amount of code,
it is often possible to prove that this is the case.
It is, in fact, quite possible to prove
that a program written in a capability-based language
is secure.

[. great to know if your os and every other app
-- that means esp'ly your browser --
are all written in this provable language ? ]

see: Capability-based Security is used in the
EROS operating system and the E programming language.
Also, Marc Stiegler et al.

addx's idea that concurrency is the key
to secure speed:

Evlan has strong support for highly concurrent programming
being a purely functional language,
Where automatic parallelization is not possible,
there are very lightweight threads (without stacks).

Most of today's systems use imperative languages
meant for a single CPU; eg, [written in adda:]
processAll(results#t.type).proc:
for(i.int = results`domain):
      results#i`= processItem results#i
).

. in c, it would process each item in order,
from first to last.
It does not give the system any room to
process two items in parallel
or in some arbitrary (most-efficient) order .

adda aspires to be simple:

It is far easier to remember
multiple uses for a single construct
than to remember multiple constructs.

--[. however he has ada-itis and braggs about
having only 19 keywords;
one of which is "(where)
which could have been said with a reused "(:) .]

interoperability done via compatibility layers:
If and when the legacy software is no longer in use,
the compatibility layers can be removed,
leaving only the ultra-efficient Evlan core behind.

functional:
Because Evlan is purely functional,
no function call is allowed to have "side effects".

. see www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=225
(dead link, is this right: queue.acm.org/detail.cfm?id=864034)?
-- ask google where else that link can be found:

Natural programming languages and environments

Communications of the ACM September 2004/Vol. 47, No. 9

by Brad A. Myers, John F. Pane, Andy Ko

This article presents findings on natural programming languages.
(i.e. natural as in intuitive in the UserCentric way)
It advocates features for programming languages,
that are justified by these findings.
Areas include:
    SyntacticSugar, that causes fewer errors
    (it more intuitive/natural).
    Better integrated debugging-support,
    esp. for hypotheses about bug-causes.
which suggests that humans like to write rules of the form
"When condition X is true, do Y".
I am not yet sure to what extent this will
change the current system, however.

natural programming:

By "natural programming" we are aiming for
the language and environment to work the way that
nonprogrammers expect.
We argue that if the computer language were to
enable people to express algorithms and data
more like their natural expressions,
the transformation effort would be reduced.
Thus, the Natural Programming approach
is an application of the standard user-centered design process
to the specific domain of programming languages and environments.

[at that link is a] good short summary of the
Natural Programming project here at CMU.
We're affiliated with the EUSES consortium,
which is a group of universities working on
end-user software engineering.
google's 2007 Update on the Natural Programming Project

Functional Bytecode

Bytecode for the Evlan virtual machine
uses a functional representation of the code.
In contrast, the VMs of Java and .NET
use assembly-like imperative instructions.
. the GNU C Compiler's "Static Single Assignment" phase
is actually very close to being equivalent to
a purely functional language. [no overwrites]
If GCC does this internally just to make optimization easier,
then it doesn't take a huge stretch to imagine a system which
compiles imperative code to functional bytecode .

--[11.30:
. another contrast to assembly-like imperative instructions
is addm's idea for a high-level interpreter:
instead of translating from an abstract syntax tree (AST)
into a sequence of assembly instructions;
addm, the vm, would try to evaluate an AST . ]

The purpose of constraining variables to types
is to get the compiler to check your work for bugs
and optimize code as well .
. if you could specify that an index to an array
must be less than the size of the array
-- and if the compiler could then check for that --
then buffer overruns (one of the most common bugs
leading to security holes in modern software)
would be completely eliminated.
(run-time bounds checking can prevent buffer overruns,
but then users see your app shutting down unexpectedly).

types of access constraints

10.5: todo.adda/types of access constraints:
. {rom, wom, xom, xwm} could be the keywords for the
various types of access constraint for
read-, write-, execute-, and write&execute- only-memory .
. instead of having any combo of rwx,
consider that an execute priv'
implies a read priv' .
. the original unix way had in mind
-- in addition to the self, group, world groups --
a sort of 4th group: executives
those whose activities depended upon
what file they opened .
other ideas:
. when does the system need an exe'able permission?
. if that app is an executive,
then it can execute any type it recognizes as exe'able .
todo:
. review previous ideas of
how an obj's name can include access types;
(just as it includes its datatype);
eg, f.txt mean obj"f is type"txt,
so then how does its name explain
access constraints such as (rom vs rwm)
and (in vs out) param types ?

10.21: adda/types of access constraints/intro:
. the fundamental operation of unix
revolves around this:
a user with privilege status of
{owner, member of owner's group}
is applying an app to a file,
if the app and file permissions permit it .
. a file may be located in
either a private or public space:
a private space is usable by
whoever has the owner's key .
. the key holder claims self belongs to a group;
and other users can belong to the same group .
. files can grant separate permissions for
{ owner (what the keyholder can do)
, in-group (what the owner's group can do)
, in-others (what anyone can do)
}.
. an executive is a special type of app
that uses its input data
as the source of instructions it will follow
including the decision of
what it will affect on the computer;
whereas non-exec's will decide their behavior
only from their constant program code,
along with their memory of their previous behavior,
and changes in the machine's state .
. most of these non-exec's are just editors,
affecting at most the files they are given,
some private mem, and the screen buffer .
. files should be tagged executable {xom, xwm}
only if their data is suitable for
instructing some executive .

. a user can be thought of as being
a sort of executive app .
. the user's actual executive power
is determined by which group of app's
the user is allowed to execute
which in turn is determined by
the executive apps' file permissions
and whether the file considers the user
to be {owner, in-group, others}.

. executives can be calling other executives,
just as the user calls them,
so, suppose a called executive
is considered to have the same priviledge
as the {executive, user} that called it;
then, a human user could run a public app,
and when that app tries to access
the user's private files,
this would be allowed .

. the exe'able permission is saying
that if you are an executive
you can read this even if
your caller doesn't have read permission;
likewise,
having a read permission is saying:
you can read this regardless of
whether you're an executive or not .

. so, all of that was the typical
unix permissions scheme;
an alternative is capability based security:

. an app can only access
the files that are within the folders that are
listed in the app's capability descriptor .
. file's and folders, too,
can have a capability descriptor
that can override any app's capabilities .

roll-your-own heap systems

10.5: news.adda/app'based heaps more vulnerable:

Adobe Reader's Custom Memory Management: a Heap of Trouble
Research and Analysis: Haifei Li
Contributor and Editor: Guillaume Lovet
 a PDF-specific exploitation research
 focusing on the custom heap management on Adobe Reader.
summary:

. I filed this note under adda
because that is my C code generator,
the basis of addx,
whose design includes rolling its own
heap mgt system .
. this paper was pointing out that
the modern OS has a secure heap due to
randomization -- a feature I hadn't planned
to incorporate into the addx mem system .

"(performance sometimes
being the enemy of security,
this custom heap management system
makes it significantly easier
to exploit heap corruption flaws
in a solid and reliable way.
Coupled with the recent developments in
DEP(data execution prevention) protection bypass,
this makes heap corruption exploitation
possible across very many setups )

. if malware can overwrite your heap,
then it helps to have a hardened heap
(like what would typically be provided
by your platform's os).
. questions I had were
how are these happening ?
here's their skeletal answer:

"( Heap corruption flaws are initiated by
(Heap overflow, use after free,
integer overflow, etc...);
the two main ways to exploit these flaws:
# overwrite some app-provided data in the heap;
# corrupting Heap mgt system's internals
(eg: block headers, etc...)
so as to make the system itself
overwrite "interesting" data;
for instance, during blocks unlinking operations,
where several pointers are updated.)

. how is malware there in the first place
waiting for a priv'escalation?
. if you prevented all these:
(Heap overflow, use after free,
integer overflow);
what else is there?
is it that functions don't check inputs?
"(many PDF vulnerabilities out there
are structure-based ones, (i.e. file format))or can malware jump in the middle of your code?
aren't you cooked already?
[11.14:
. their crashing data becomes code
because it's overwriting your code:
the heap pointers you use
for going to your own code .]

NetVM and cap'based security

6.19: addx/security/vmnet and cap'based:
Joanna Rutkowska Jun 17, 2010 at 4:53 AM
qubes-devel@googlegroups.com

"(you might not have VT-d working,
in which case you would not benefit from
additional security provided by sandboxed NetVM, ...)

. how could this NetVM idea
merge with cap-based security?
. with very fast switching
every app could have virtual access to
every other component .
. of these connections, you could
watch or log them, stop them,
or undo them by allowing only
virtual access (not modifying the
original object, but some mirror)
. the reason we need L4 [hypervisor]
is to reuse untrusted wares
and to have cooperation among
the mutually distrusting .
. ok L4 is a great platform because
it can act as a microkernel too .
. need to see how that means the
face changes for app dev's
-- is it just good news for sys' eng's?
. even without having L4 as an os,
the process-isolating architectures
like seL4 and Microsoft's Singularity
can still be useful as part of an
app framework that can give app dev's
more confidence in their own wares .
[6.24: ie, the basic stack has been:
(basic OS providing common lib's,
between hardware, and apps)
and then in addition to the basic OS,
there could be a security layer
provided by an app framework OS .]
[6.30: L4 vs seL4:
seL4 adds cap'based security to L4 .]

6.20: addx/seeing the light:
[6.30: todo: prove this!]
. it can seem rather pointless
trying to develope a secure app
on an insecure OS;
but for personal use, at least,
there can be security if
all the apps use that framework .
. even if you can't find hardware
that is designed for okL4 (open seL4)
it could help to have an app framework
that is based on an seL4 .

addx/security/what's needed on secure platform:
6.21:
. after seeing this googlecode blog
I was thinking about how to include
cap'based security .
6.27:
. chrome os already has good
separation between app's,
but what is that allows a browser
to rifle through your files
after hitting the go-away button?
has chrome browser really fixed that?
[6.30:
I've not had this problem on Chrome yet;
but what is "(sandboxed) mean
if it's so easy to steal my permission? ]
. if the guard is finally here,
then the only needed
cap'based permissions would be
the design of an app like addx
that is a scripting environment .

adde's security

3.23: adde/security:
. how does user data remain private
when that privacy depends on not having net access,
but then it can still access another program
that does have net access ?
3.31:
. app's are not communicating directly;
rather, they message each other and the internet
only through the os, addx,
and this arrangement offers several tools:
. only isolated app's connect with the net .
. app's that contact both the net and the user
can raise an alert to check that app's
trust settings .
2313:
. all user input goes through the user`agent,
which can assist in protecting user privacy .

3.25: adde/security/networking controls:
. after reading about flash being
a complete programming language
I wondered how adde can protect the user
without bugging them ?
. does the current design already take care of this?
the only time it matters that a program
communicates with its home site
is when it also has access to local personal data .
. for an app like an editor that also has
a pane that needs web access,
the program could come as a package of 2 modules:
the edit.module wouldn't have web access,
and the web.module wouldn't have files access .
. the editor pkg would provide suggestions for
how to arrange the panes for each module,
but adde and the user would have final say over that .
3.31:
. adde is checking the module capabilities
so as to enforce trust settings .

3.27: adde/multi-casting:
. from a dev.android thread:

"(I'm pretty sure that's not possible to
generate a broadcast event when the alt key is pressed,
instead of letting the current application consume it.) .

. part of special permissions should include
app's or services explaining that they are sniffing input
from what you would think is going to the app in focus .

cap'based or actors-based

9.26: adda/security/cap'based or actors-based:

. since adda has control of the code,

does it need capabilities?

it's just like checking array bounds

protecting programmer from accidents .

. also when using agents and concurrency,

you need that soa-style id'ing

that let's you find out who's doing what

when things seem wrong .

. without having to know much about cap'-based systems,

it seems there's a clear path if you

stop worrying about efficiency, and model the system after

what you can understand is secure among human interactions:

organizing jobs just as if they were teams of people .

. all these actors keep journals

checked by god (the exec that runs their prgm for them)

. the flip side of logging is contracting:

a module has a req's list

that tells what permissions of what space it needs

and the exec will report any deviation from those

contractual obligations .

. global logging allows selective roll-backs

not just per object but agent-selecting:

undo all work of a faulty agent

then redo the work without that agent's contributions .

. req's should be specifying what operations or tools

it's using on what space

. another way to do this is have the exec generate

a report of the space being used .

. this can be done as a blacbox without needin to know the code:

as long as it was compiled to be exec'd by addm,

it can't make outside contacts without being logged by addm .

. likewise if it had an efficient way to virtualize the native platform,

then it could do the same with native binaries .

[9.29:

. the language that both addm and the binary would talk

is the files in the virtualization that would get the output .

]

10.9: adda/no need to specify current directory with command:

. regarding dev.unix/need to specify current directory with command:

adda will instead rely on cap'based security

to protect authors from each other .

10.26: adda/self-modifying or code-generating code/security:

. how is adda safe letting code modify itself?

it does so only by calling the adda compiler

which can enforce rules to run by .

. it has to declare everything it wants to modify;

and, this is checked against user or client preferences .

[11.3:

. eg, adda asks the user's agent this:

"( this code was generated from .program,

and wants permission for { .access to .resource, ... }

do permit?

do disallow code additions,

do disallow permission change requests? .

) ] .

11.30: adda/lisp/security options:

. along with having a cap'based security system

it can tell the user if a provider uses self-modifying tech

for in case that should be avoided for safety critical applications,

or for when correctness is not easily proven from scanning output .

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 .