[cap-talk] Java coding rules for capability discipline

[Stiegler, Marc D]

> > > Some of the following rules are not exactly requirements.
> > You can have
> > > a language or a style that is nominally "cap-secure"
> > without some of
> > > them. But we're trying here for more than a minimum to pass some
> > > definition. We're trying to get as much security as we 
> can get for 
> > > following a fairly easy set of rules. So here's a first pass:
> > 
> > 
> > 
> > > -- No static mutables (no class variables)
> > 
> > How do you then guaruntee that there is only one
> > user of a single-access resource?  For example, a
> > manager of something like a database resource would
> > often use a static variable to enforce its one-ness.
> > 
> > Do you for example mean no non-private static mutables?
> 
> Ooops. Right. Correction, no public static mutables.

Ooops times two (Ooooooops? :-) I was right the first time: no static
mutables. If you allow private static mutables, then all the objects
instantiated from a single class can still communicate with each other
without explicit authorization, thus blowing your confinement.

To ensure the following gets into the public record, let me also note
that I made the same mistake when writing the Final DarpaBrowser Report:
I said "no public static mutables", when I really needed to say "no
static mutables." Some day I will get this right :-)

Anyway, to answer your question about a single-access resource, i.e., a
singleton object, here is an oddball idea: have a public static "make"
method that creates and returns an object the first time it is
called...but instead of always returning the cached created object each
successive time, as in the typical singleton pattern, make it return a
null every time it is called after the first time. This way you are
guaranteed that the object is created once, and that it is moved around
via explicit reference passing rather than by the unconfined and
surprising (from a security perspective) backchannel of a static
mutable. This strategy would have a vulnerability in that, if the wrong
guy called the make method first, the appropriate people would not get
the object. But this would appear as an easily detected bug, not as a
hard to find security breach (unless you're running untrusted code on
the same jvm, in which case, you are already hosed, as noted in earlier
email).

Could that answer your needs? There are undoubtedly other strategies for
making singletons in Java, but that's the one that popped into my head
(and people with other strategies they like better are more than welcome
to post them :-)

--marcs