Re: Newbee to Joe-E

samriti katoch  wrote:
> I am trying to convert an existing Java based web application into
> Joe-E compatible constructs.

This is not the scenario that Joe-E was designed for, so be
prepared: you may be in for some serious frustration [1].

Joe-E is designed for folks who want to build new applications
following object-capability design patterns, not for migrating
existing Java applications into Joe-E.  The security benefit of
writing in Joe-E comes primarily from following object-capability
principles, not merely from being written in Joe-E.

It's rare to find an existing Java application that was designed
with object-capability design patterns in mind.  If you take an
existing application that was not designed following object-capability
principles, I suspect you'll find that it's not easy to translate it
into object-capability form and then into Joe-E.

Someone once said that you can write spaghetti code in any language.
The same goes for Joe-E; the Joe-E programming language is not a
magic bullet that magically ensures your code will have good security.
Moreover, object capabilities are not something you can sprinkle on after
the fact.  Object-capability design principles tend to have a pervasive
effect on the architecture and structure of the entire application,
so this needs to happen at design time: you can't easily add it after
the fact.


With all those caveats, let me try to answer some of your specific
questions:

Yes, in some cases there are alternative wrappers that can be used
to replace these classes.  See the Joe-E library, which lives in the
org.joe_e.* namespace.  For instance, org.joe_e.file.Filesystem provides
methods that can be used as replacements for the denied/suppressed
members of File.  org.joe_e.file.Filesystem was designed to respect
capability design principles.

java.net.URI is a possible replacement for java.net.URL.  java.net.URL has
all sorts of crazy aspects that seem poorly considered.  For instance, did
you know that calling equals() on a java.net.URL triggers a DNS query?
(It's nuts.)  Also, given a String representing a url, java.net.URL
provides a way to make a network connection to the resource at that
url, which violates object capability requirements (it is a case of
ambient authority).  So java.net.URL is typically poorly suited for
objcap programming, and java.net.URI is likely to be a better fit.

However, full disclosure, there's one issue with my advice to just use
URI: if you look in the Joe-E taming database, you'll find that both URL
and URI are suppressed with a "default deny" annotation.  The reason is
that our taming database is highly incomplete.  Here you are running
into the limitations of a research tool; we didn't have the software
engineering resources to build an extensive taming database.  Moreover,
for security, we adopted a default-deny policy for taming: all Java
library APIs are tamed away by default, and no API is enabled in the
taming database until we have verified that the API is capability-safe.
As a result, most Java APIs are disabled in the taming database.  I expect
that if you plan to do any serious programming, you'll find this to be
a serious nuisance, and you'll probably have to do some taming of your
own (i.e., analysis of APIs to find which ones are capability-safe, and
then modify the taming database to allow those APIs).  This, in turn,
will require knowledge of capability principles as well as willingness
to dive into the Java libraries and how they operate.  I apologize for
this aspect of Joe-E, but that's how it is.

Hope this helps.  If you have other questions, don't hesitate to ask
here.


Footnote 1: See, e.g., Section 2.1 of the Joe-E paper:
  http://www.cs.berkeley.edu/~daw/papers/joe-e-ndss10.pdf