Essentially what you are saying is that the current JDK permissions
facility is not as flexible as you would like for implementing your
container.
The existing permission facility was used extensively within the JDK
itself. That at least demonstrates that the existing functionality is
sufficient (in function and efficiency) for controlling access to
privileged functions.
I don't have an opinion myself on whether or not your suggested
enhancement would be useful; however, I will pass it on to the JDK
security team.
-- Mark
Alan Greenspan wrote:
>
> I think you missed the point Mark. We're not suggesting that components be
> given more privileges than specified in EJB 1.1 or J2EE. We're suggesting
> that the J2EE subsystems which are called into by the components (JMS, JDBC,
> RMI) be allowed to run with their granted permissions regardless of who
> called them (and without forcing the container to interpose on every bean
> access). Think of it as an implicit doPrivileged block.
>
> Consider it in terms of how privileges are specified in a policy file.
> Here's an example. Suppose a container vendor implements a policy file with
> the normal granting of all permissions to the java extensions. The
> following would appear in the Container's policy file (unless inherited from
> the JDK policy file).
>
> //
> // Grant all permissions to the java extensions
> grant codeBase "file:${java.home}/lib/ext/-" {
> permission java.security.AllPermission;
> };
>
> OK, so this grants all permissions to the Java extensions. But of course,
> if an EJB called into an extension package (let's say into a JNDI service
> provider), the package would run with the minimal EJB privileges, not the
> Java extensions privileges and we would likely blow up in an access control
> check.
>
> An extension to the policy file syntax might go something like this:
>
> //
> // Grant all permissions to the java extensions
> grant codeBase "file:${java.home}/lib/ext/-" doPrivileged {
> permission java.security.AllPermission;
> };
>
> Marking a codeBase as doPrivileged would trigger the access control checks
> to run the codeBase as though it had been coded with doPrivileged blocks.
> In general, this is a much more flexible (and efficient) way to implement
> the desired controls. The way things are now, you either litter the code
> with doPrivileged blocks (which forces code to always run privileged) or you
> have to write wrappers for everything in existence. The third alternative,
> of course, is to write some ugly security manager code which can determine
> when you transit from unprivileged to privileged code.
>
> PS
> Another slight enhancement to my proposal would be to allow the doPrivileged
> option to take a set of codeBases as a parameter and only run with privilege
> if called into by one of those codeBases. This would give finer control
> over the mechanism, though in practice I don't think its that useful.
> Generally, if you've decided to grant a codeBase a set of permissions, you
> probably want it to run with those permissions regardless of who called it.
>
> Alan
>
> > EJB 1.1 and J2EE specs both require that components be restricted to the
> > minimum specified permissions.
> >
> > How it is dealt with in container implementations and in J2EE code
> > provided by Sun (such as JNDI, JavaMail, CosNaming, RMI-IIOP, etc.) is a
> > useful topic to discuss. If there are things container developers would
> > like to see handled in Sun provided code we would like the feedback.
> > Please send it to the appropriate spec comment alias.
> >
> > This requirement has gone through a long and thorough review process as
> > part of J2EE. There are many J2EE implementations in process including
> > the J2EE reference implementation which have effectively handled this
> > requirement.
> >
> > At this point, it is highly unlikely that any change to this requirement
> > will be made.
> >
> > -- Mark
> >
> >
> > Larry Allen wrote:
> > >
> > > Alan Greenspan wrote:
> > > >
> > > > If I follow what you are saying, the EJB Container must interpose on
> EVERY
> > > > Bean access to anything outside of itself and wrap the call with a
> > > > doPrivileged block - this means every JNDI call, every JDBC call, JMS
> call,
> > > > JTA call, ... EVEN every access to any remote object (i.e. another
> EJB).
> > > > The last case is a real killer - I don't see doPrivileged blocks in
> the RMI
> > > > stubs from Sun (JRMP or IIOP). The case we hit was in Sun's ORB on a
> JNDI
> > > > lookup, but could have just as easily been hit on any ordinary remote
> object
> > > > reference.
> > > >
> > > > It seems a bit much to insist that the container interpose on all
> references
> > > > to all enterprise Java APIs just to increase the privilege level. And
> in
> > > > some cases, we may not have the opportunity to interpose (e.g. in the
> case
> > > > of stubs, unless the Container vendor is also the RMI vendor or
> supplies its
> > > > own RMI stub generator).
> > > >
> > > > Someone at Sun should revisit the code base security model and
> consider
> > > > allowing a policy option in which a codebase gets the privileges it
> was
> > > > assigned regardless of who called it. Given that the deployer is in
> control
> > > > of setting the policy, this seems very reasonable, and it would
> obviate the
> > > > need for the container to wrap every EJB external access in a
> doPrivileged
> > > > block.
> > > >
> > > > Alan
> > >
> > > I agree with Alan on this one. We did the same analysis he did, of
> wrapping
> > > all EJB-callable methods with doPrivileged() blocks, and concluded that
> > > it was both prohibitively expensive and impossible -- not least because
> > > many of the EJB-callable methods were on classes implementing (e.g.)
> > > java.sql.Statement provided by 3rd-party JDBC driver manufacturers.
> Note
> > > also that every call to a doPrivileged() block typically involves use of
> > > an inner class, which introduces hundreds or thousands of additional
> > > classes to be loaded and managed. The approach quickly became
> impractical.
> > > I also agree with Alan's proposed solution, although it needs to be
> > > reviewed carefully for security loopholes.
> > > -Larry Allen
> > > SilverStream Software
> > >
> > >
> ===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > > of the message "signoff EJB-INTEREST". For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
> ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
