You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Mauro Talevi <ma...@aquilonia.org> on 2002/09/26 00:23:37 UTC
Security policy
Hi,
a couple of questions on how phoenix handles the security policy files:
1. security policy is set in <policy> element in environment.xml,
and - as stated in docs - if not set then it is equivalent to
AllPermissions.
Is that regardless of the $JAVA_HOME/jre/lib/security and
~/.java.policy?
2. being set in environment.xml one can assume that the settings are
per-application and that one can set two completely independent
policies for two apps running simultaneously in phoenix container.
BTW, do separate apps run in separate JVMs?
Thanks,
Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security policy
Posted by Peter Donald <pe...@apache.org>.
On Fri, 27 Sep 2002 09:01, Mauro Talevi wrote:
> >However note. That because of the way Java security policys work the
> >permissions of an application can never exceed the permissions assigned to
> >the kernel as the permissions checked against are effectively an
> > intersection of the two sets. That make sense?
>
> yep. One further question on setting policies in environment.xml.
> How can one grant a permission, say to a default domain, ie without
> specifying the codebase?
> The most obvious way would be to omit the code-base attribute in <grant>
> but phoenix complains
> upon initialisation that code-base is null.
> I did look in the code and it does allow for the null code-base case.
I updated the code to allow this. Could you check that it works for you ?
--
Cheers,
Peter Donald
-----------------------------------------------
| If you turn on the light quickly enough, |
| you can see what the dark looks like. |
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security policy
Posted by Mauro Talevi <ma...@aquilonia.org>.
Peter Donald wrote:
>The security permissions for the JVM are only used for the common classes (ie
>$PHOENIX_HOME/lib/*.jar) and the container classes ($PHOENIX_HOME/bin/lib)
>
>However we actually specify the security policy as the one stored in the
>phoenix-launcher.jar. Have a look in that for the Kernel/common classes
>policy file.
>
yes - I had noticed it.
>However note. That because of the way Java security policys work the
>permissions of an application can never exceed the permissions assigned to
>the kernel as the permissions checked against are effectively an intersection
>of the two sets. That make sense?
>
yep. One further question on setting policies in environment.xml.
How can one grant a permission, say to a default domain, ie without
specifying the codebase?
The most obvious way would be to omit the code-base attribute in <grant>
but phoenix complains
upon initialisation that code-base is null.
I did look in the code and it does allow for the null code-base case.
Thanks,
Mauro
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security policy -> Question!
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Thu, 26 Sep 2002 14:02, Mircea Toma wrote:
> I'm picking up on this discussion to find answer to a question that has
> buged me lately. A while ago we had a discussion about making available
> kernel services to blocks. We all know the benefits of that. The problem is
> how to protect the kernel from malicious/unknown code. The solution would
> be to create a few Phoenix specific Permission classes (such as
> DeployPermission, ApplicationPermission) and use the AccessController to
> check if the calling code has been granted access (configured in the
> general policy file).
thats a pretty neat idea.
> So my question is why this solution was not chosen?
Partially because it also requires exposing the classloader containing all the
interfaces for kernel and we have not had the infrastructure to do that. I am
currently working on that ;)
> Because right now Phoenix is moving away from its original definition of
> "micro-kernel" by integrating more and more functionality into the kernel
> space (aka SystemManager, DeploymentMonitor ..).
yep. Those should definetly become hosted applications.
--
Cheers,
Peter Donald
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security policy -> Question!
Posted by Mircea Toma <mi...@apache.org>.
On Wednesday 25 September 2002 16:37, Peter Donald wrote:
> Hiya,
>
> On Thu, 26 Sep 2002 08:23, Mauro Talevi wrote:
> > 1. security policy is set in <policy> element in environment.xml,
> > and - as stated in docs - if not set then it is equivalent to
> > AllPermissions.
>
> yep.
>
> > Is that regardless of the $JAVA_HOME/jre/lib/security and
> > ~/.java.policy?
>
> The security permissions for the JVM are only used for the common classes
> (ie $PHOENIX_HOME/lib/*.jar) and the container classes
> ($PHOENIX_HOME/bin/lib)
>
> However we actually specify the security policy as the one stored in the
> phoenix-launcher.jar. Have a look in that for the Kernel/common classes
> policy file.
Hi,
I'm picking up on this discussion to find answer to a question that has buged
me lately. A while ago we had a discussion about making available kernel
services to blocks. We all know the benefits of that. The problem is how to
protect the kernel from malicious/unknown code. The solution would be to
create a few Phoenix specific Permission classes (such as DeployPermission,
ApplicationPermission) and use the AccessController to check if the calling
code has been granted access (configured in the general policy file). So my
question is why this solution was not chosen?
Because right now Phoenix is moving away from its original definition of
"micro-kernel" by integrating more and more functionality into the kernel
space (aka SystemManager, DeploymentMonitor ..).
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Security policy
Posted by Peter Donald <pe...@apache.org>.
Hiya,
On Thu, 26 Sep 2002 08:23, Mauro Talevi wrote:
> 1. security policy is set in <policy> element in environment.xml,
> and - as stated in docs - if not set then it is equivalent to
> AllPermissions.
yep.
> Is that regardless of the $JAVA_HOME/jre/lib/security and
> ~/.java.policy?
The security permissions for the JVM are only used for the common classes (ie
$PHOENIX_HOME/lib/*.jar) and the container classes ($PHOENIX_HOME/bin/lib)
However we actually specify the security policy as the one stored in the
phoenix-launcher.jar. Have a look in that for the Kernel/common classes
policy file.
However note. That because of the way Java security policys work the
permissions of an application can never exceed the permissions assigned to
the kernel as the permissions checked against are effectively an intersection
of the two sets. That make sense?
> 2. being set in environment.xml one can assume that the settings are
> per-application and that one can set two completely independent
> policies for two apps running simultaneously in phoenix container.
Correct. However if Apps share classes (ie some of the classes are loaded out
of $PHOENIX_HOME/lib) then the policies for these will be according to the
JVM.
> BTW, do separate apps run in separate JVMs?
nope.
--
Cheers,
Peter Donald
------------------------------------
The two secrets to success:
1- Don't tell anyone everything.
------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>