avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nader Aeinehchi" <na...@aeinehchi.com>
Subject Re: Merlin Security
Date Wed, 12 May 2004 21:37:28 GMT
Hello Farr

Last time I was writing about security, I accidently pressed the "send"
button of the email program.  The result was a disappointing incomplete
email.

Please allow me to make some hints/suggestions:

1.  Be careful with this line:
-Djava.security.policy=$MERLIN_HOME/bin/security.policy

There are many hidden features in Java.  The above line still uses the
security definitions in JRE directory etc etc.....

You should rather use the following way which ensures only your policy file
is in control
-Djava.security.policy==$MERLIN_HOME/bin/security.policy


2. Keep yourself to standard policy file as long as you can.
Most of the time, the standard policy file from Sun provides the desired
functionality and probably more.

3. If you decide to develop your own policy file (and a policy parser), be
very careful.  Your policy parser could easily contain security holes.

4. Consider to start your kernel in security mode:

If Merlin is an embedded container in another container that has aleady
started in security mode, you have a problem.
As always, there is a solution, but I am not going into details now.

5. If you decide to let Merlin be the top-most container, and thus the one
that starts security manager, consider the following:

a. define an authorization provider which in the most simple way is the
standard policy file.
The following command line argument gets you there:
-Djava.security.policy==$MERLIN_HOME/bin/security.policy

You could consider to develop an authorization provider using a database, an
LDAP server etc.  Regardless of implementation, you will end up creating a
Policy object.

Having created a Policy object, you may call:
    Policy.setPolicy(youPolicyObject)

Of course, the above approach is very simplistic.  You may play with the
concept of policy object and develop a system that uses different policy
objects for different protection areas, (say a realm, a Merlin component or
a Merlin container).


b. consider developing your custom SecurityManager (YourSecurityManager
extends SecurityManager)
This gives you the flexibility to add custom functionality.  Note that the
standard security manager is pretty solid, and in most of the time, it
provides all the functionality you need.  In many occastions, you do not to
develop a security manager but rather create custom permission classes.

d. consider running the rest of the application in privileged mode, either
for a given codebase, or for a given Subject.
The buttom line is that a protection area (say a Merlin container) wants to
have certain privileges.  Within a given container, you want the users to
have privileges that do not exceed the privileges of the container itself.






Best Regards

--
Nader Aeinehchi
Aasenhagen 66 E
2020 Skedsmokorset
NORWAY
Direct and Mobile +47 41 44 29 57
Tel (private): +47 64 83 09 08
Fax +47 64 83 08 07
www.aeinehchi.com

----- Original Message -----
From: "Farr, Aaron" <Aaron.Farr@am.sony.com>
To: "avalon-dev" <dev@avalon.apache.org>
Sent: Wednesday, May 12, 2004 8:09 PM
Subject: Merlin Security


> Hello.
>
> Another "I didn't pay attention enough the first time" Merlin question. :)
>
> Okay, so now the kernel.xml file has a bunch of security parameters in it.
> Tracing through the code it looks like this sets the System
SecurityManager
> and a series of permissions.  A couple of questions:
>
> - It looks like this is off by default.  Is this correct?  Even if there
are
>   entries in the kernel.xml?
>
> - How does this interact with a security policy given via the command
line?
>   (ie -Djava.security.policy=$MERLIN_HOME/bin/security.policy)
>
> - Why?  Why not just use a normal policy file?  What does this security
give
>   us?  Sorry, I'm not a java security expert (my bad).
>
> Thanks.
>
> J. Aaron Farr
> SONY ELECTRONICS
> DDP-CIM
> (724) 696-7653
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message