Re: Newbee to Joe-E

Unfortunately, there is not currently a UI for generating a skeleton 
safej file for a specific class.  While there is actually some code to 
do this in the verifier source code, there is not currently a UI for 
invoking this functionality.  (I just temporarily compiled in a call to 
it, as I only needed to do so once for each package I generated safej 
files for.)

What the "build policy class" option does is to generate the runtime 
version of the taming database, i.e. it generates source code for the 
class org.joe_e.Policy based on the contents of the safej files.  This 
is orthogonal to generating the safej files in the first place.

-Adrian

samriti katoch wrote:
> 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
>>
> 
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang