Re: Newbee to Joe-E

Hi,

How can I modify the taming database for java libraries and custom classes.
What I tried doing was this e.g. to create a .safej file for
org.apache.log4j.Logger class:
created a Logger.safej in taming/org/apache/log4j folder.
I have the "Automatically build policy class " set for the project option.
I still see that the JoeE verifier generates warnings as "No policy
specified for class".

Another observation is that the org.joe_e.taming-20100421.jar  file
does not change at all, which it should if JoeE verifier was
rebuilding it.

What am i doing wrong?

Regards,
Samriti.

On Thu, Nov 18, 2010 at 2:40 AM, David Wagner <[email protected]> wrote:
> 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
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>