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".
