[e-lang] Joe-E 2.0 Release
tyler.close at gmail.com
Sat Mar 8 10:45:40 EST 2008
Also, rather than have separate safej files, I recommend there just be
a Policy.java file in the Joe-E distribution that contains all the
Java taming decisions. If people want to add more taming decisions,
they edit the Policy.java file.
On Sat, Mar 8, 2008 at 7:35 AM, Tyler Close <tyler.close at gmail.com> wrote:
> I've got an alternate proposal for marking Joe-E code.
> Java supports package annotations that are available at both compile
> time and runtime. I suggest Joe-E define an annotation
> org.joe_e.verified. To enable Joe-E verification of a package, the
> programmer adds the standard package-info.java file with content:
> @org.joe_e.verified package org.example.stuff;
> The Policy class can then check that a reflected member is either
> defined in a Joe-E verified package, or is enabled in the safej
> database. The safej database then doesn't need to contain any
> information about Joe-E verified code, only tamed Java code.
> On Fri, Mar 7, 2008 at 8:08 PM, Adrian Mettler <amettler at cs.berkeley.edu> wrote:
> > Thanks for the feedback. In the current design, things are a pain when
> > there are multiple projects with Joe-E code, as the verifier is not
> > aware that the other projects are Joe-E verified. I'm interested in
> > improving this, both in the long term and implementing some workarounds
> > for the short term -- it should be easier than your experience. (I
> > recently grabbed the waterken release to work on implementing the needed
> > taming policy and encountered the same problems, and started
> > implementing prefs in the verifier to make things work more smoothly, as
> > it seemed to be even more of a problem then missing stuff in the safej
> > decisions.)
> > At the moment, the verifer autogenerates .safej and Policy files, but
> > this is not always necessary. The safej files may be useful if the
> > project will be used as a library (particularly a binary library). The
> > Policy file can be helpful if the project will be run as a stand-alone
> > application and uses reflection on classes defined in the project.
> > Neither are necessary if one is using a Policy file based on
> > distinguishing trusted/verified code (for which all methods are enabled)
> > by its classloader. Ideally, there would be some way to tell when these
> > files are needed or useful, but in the short term I can make a pref to
> > toggle each of these on a per-project basis. I can also have an option
> > to generate a Policy file that implements the prior classloader-checking
> > behavior to avoid the need for explicit taming info for non-library classes.
> > Another goal is to make the verifier aware of Joe-E code in other
> > projects, making it easier to handle multiple-project applications.
> > Previous versions had a hack of assuming that all source code in the
> > workspace was safe to call, whereas all JARs had to be tamed, but this
> > isn't a reliable distinction. One could have legacy classes open as a
> > source project, or Joe-E code included from a JAR. The simplest
> > approach to unify this was to require safej for everything (except, by
> > technical necessity, verified source in the same project); but in the
> > current implementation, I see that this is a real pain. There are a
> > number of ways I see to improve this:
> > (1) add a pref to restore the previous behavior of trusting all source.
> > this is not a full solution, as not all source is trusted. It also
> > may make compile-time taming policy differ from runtime taming
> > policy. But it might be the easiest to implement temporarily
> > (2) recognize Joe-E code in other projects, the same way as Joe-E code
> > in the same project, and allow it to be used. This can potentially
> > cause runtime and compile-time policy to differ, unless all Joe-E
> > code from such projects is used in creating Policy.java. Either
> > way, I think that this is preferable to (1), as non-Joe-E stuff
> > won't ever get treated as safe for no good reason. Unfortunately,
> > it still makes it a pain to use non-Joe-E code (which must still be
> > added to the taming database).
> > (3) read the taming directory of other projects and use their safej in
> > addition to the common safej configured in the preferences.
> > The taming folder for a project would contain both autogenerated
> > safej for Joe-E classes and manual or partially-automated safej
> > for non-Joe-E classes in the project. The safejs in a project would
> > then be used for static taming enforcement and added to the Policy
> > file in other projects that depend on that project. This has the
> > advantage compared to (2) of allowing use of source marked as
> > non-Joe-E without requiring its classes to be added to the global
> > taming database. The disadvantage is that it means that the safej
> > files must be generated even if otherwise not needed, unless
> > combined with option (2) in some way.
> > I'll see if I can implement (2) soon so you don't have to be dealing
> > with safej for the multiple Joe-E projects in Waterken.
> > -Adrian
> > Tyler Close wrote:
> > > If I have multiple Eclipse projects that should be Joe-E verified and
> > > where some are dependencies of others; how do I set up the new taming
> > > infrastructure so that the Joe-E verifier does not complain about
> > > types in one Joe-E verified project being used in a separate Joe-E
> > > verified project? For example, currently I am getting Joe-E errors for
> > > the web_send project, which depends on the ref_send project of the
> > > Waterken server. How do I make these go away? When the Joe-E verifier
> > > runs on the ref_send project, it spits safej files into
> > > ref_send/taming; as well as dropping a Policy.java at
> > > ref_send/src/org/joe_e/taming/Policy.java. My Joe-E preferences page
> > > points at joe_e/taming where the safej files from the Joe-E
> > > distribution reside. The Joe-E verifier does similarly for the
> > > web_send project, spewing files into the web_send project directory.
> > >
> > > Getting up and running with the new taming infrastructure in the Joe-E
> > > verifier has been a trial for me. This business of generating taming
> > > files for Joe-E verified code seems like a poor design to me.
> > >
> > > --Tyler
> > >
> > _______________________________________________
> > e-lang mailing list
> > e-lang at mail.eros-os.org
> > http://www.eros-os.org/mailman/listinfo/e-lang
> Use web-keys for RESTful access-control:
> Name your trusted sites to distinguish them from phishing sites.
Use web-keys for RESTful access-control:
Name your trusted sites to distinguish them from phishing sites.
More information about the e-lang