You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Nader Aeinehchi <na...@aeinehchi.com> on 2004/04/03 11:53:23 UTC
Secure Kernel in Merlin
Hello
I studied the default kernel in Merlin. As far as I can see, security is not build in the kernel.
1. Would it be an idea to build in security in default kernel? Are there any reasons not to build security in default kernel?
2. If the answer in question 1. is no, would it be an idea to develop a SecureKernel?
3. If you were going to build security in kernel (either DefaultKernel or a SecureKernel), would you build it upon Java's security API (AccessController/SecurityManager, Policy, ProtectionDomain, JAAS etc) or would you rather build your own security component?
4. If the answer to questions 1. and 2. is no (i.e. no security in kernel), would you rather develop security in each Container?
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
Re: Secure Kernel in Merlin
Posted by Stephen McConnell <mc...@apache.org>.
Nader Aeinehchi wrote:
> In many systems I have looked at, a kernel typically starts several
> containers which in turn may start other containers/applications. The
> question is whether not to introduce security in kernel, but rather
> introduce it in higher level layers (with kernel as the lowest level layer)?
> If one thinks of a simple kernel (say a micro kernel), the kernel does not
> want to be doing too many things. it simply manages the higher level
> layers, but it is the responsibility of the higher level layers to take care
> of things like error management, security etc. I am not asserting this to
> be a fact, but rather ask you for your opinion?
Nadar:
First off - a preemptive disclaimer - "I'm not a security guy" - but all
the same, here is a picture of what is and some thoughts about where
things could/should/will go in the coming months.
Within Merlin the kernel is used to establish primitive system services
and the root container. Under the current CVS HEAD kernel.xml you can
declare a set of named security permission profiles. The kernel factory
uses this information to build a set of SecurityProfile instances that
are supplied to the SystemContext.
The SystemContext is responsible for the establishment of a ModelFactory
and a Runtime. The ModelFactory is the single point of component model
creation. During model creation the factory assigns a new component
model a security profile based on information in the target overrides
configuration.
I.e.
merlin -kernel kernel.xml -config config.xml block.xml
Where:
kernel.xml - declares a set of named security profiles
block.xml - declares a container namespace, components
models, and activation rules
config.xml - declares the granting of a named profiles
to addressable component models via target
declarations
Something important to note is that this is orthogonal to the notion of
cadesource. Instead - its about the granting of privileges to an
identifiable instance of a component model (i.e. a deployment scenario).
Under the runtime environment - component instantiation, lifecycle
methods, and invocations by a component implementation of external
services are executed as privileged actions relative to the assigned
security profile. What this means is that we have something like the
following in terms of where things are heading:
|-------------------|
| subject | <-- identity and role related
|-------------------|
| context | <-- adaptive permissions
|-------------------|
| component | <-- partly implemented and working
|-------------------|
| codesource | <-- know stuff
|-------------------|
Starting from the bottom and working up:
codesource - This is the classic java security model of assigning
permissions to a codesource. This is what I think of
as immigration level security policy - its the
granting of privileges based on trusted signers. Some
more work is needed in isolating classloader creation
that occurs inside the composition model under the
repository system - following which we can do all of
codesource level management in one location.
component - Component level security deals with permissions that
are granted to one or component instances that share
the same configuration, dependencies, context, etc.
(i.e. a deployment scenario). Two distinctly different
deployment scenarios can exist that share the same
codebase, even the same component type.
context - This is more related to more related to the management
of security policy decisions in a distributed
environment where the permissions are driven by the
state of a common (shared) execution context. The
only reason I'm mentioning it is for completeness with
respect the overall picture.
subject - Establishment of principal identity and credentials,
association with roles and groups, etc. Also in this
group is the question concerning invocation subject
versus execution subject which ties us into security
policy delegation.
Finally - much of the above is loaded terminology resulting from too
much time spent in the bowls of merlin. But hopefully it provides a
useful picture.
Cheers, Steve.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Secure Kernel in Merlin
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 April 2004 19:14, Nader Aeinehchi wrote:
> Not only the authorization model may be different, but also each
> component may want to use a different authenticator. Based on that
> experience, I got the idea that a cascading security model should be
> provided, in which each component has its own security model that cannot
> violate the security constraints imposed by its surrounding container.
What I have in mind is that the Authenticator is pluggable through the
Context, so that the component doesn't know/care about how it is done, and
will just request the service from Merlin. You would then be able to provide
authenticators to each component independently (or collectively).
> Regarding "assign grants to 'components' instead of codebases", I would
> think you can solve it by a special purpose classloader. When a component
> is loaded by the classloader, simply assign the component its own
> codoesource, that is different from its physical codesource. A similar
> approach is taken in Sun's J2EE 1.3 reference application server.
Thanks for the tip. This could be a good way forward. I (nor Stephen) won't be
working on it in the very near future though, since we have some other pieces
to clean up first, but I think it is next on the agenda after the
Excalibur/Fortress/Cornerstone effort.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Secure Kernel in Merlin
Posted by Stephen McConnell <mc...@apache.org>.
Nader Aeinehchi wrote:
> 1. Merlin's Kernel is pretty limited, and not really worth adding any
> security
>
>>features, since the same can basically be done by the java.security.policy
>>file.
>
>
> 2. The interesting parts lies in the possibility to assign grants to
> 'components'
>
>>instead of codebases
>
>
> 3. Next step is to make a facility which provides the JAAS style subject
> level
>
>>security
>
>
> For a customer, I developed a security service that incorporated security in
> kernel (a factory would decide whether to start in security mode or not).
The equivalent "factory" in Merlin is the DefaultSystemContext class
under the composition/impl package. It's basically the single point of
reference for all system related information.
> This secure kernel is build on JAAS, also both codebase and subject as the
> secure kernel at boot reads the policy file (say from a database or a ldap)
> and replaces the policy for the entire JVM.
Sounds good - personal preference is to work closely with the Apache
Directory Project to leverage Eve (an LDAP server) for management of
identifies, credentials, attributes, etc.
> Furthermore, I developed an extended security manager that could provide
> addon features like method permission (similar to EJB declarative method
> permission) etc. One point I learnt from this project is that the
> underlying "components" may have a different security model than the kernel.
Absolutely yes - components have very different concerns relative to the
kernel. Kernel is much more related to environment and system policy,
whereas a component is much closer to application context.
> Not only the authorization model may be different, but also each component
> may want to use a different authenticator.
This sentence worries me a bit. Given the following two possible approaches:
(a) component implementation does authentication
(b) or, component model does authentication prior to delegation
to component implementation
I'm assuming case (b) - which is consistent with everything else in
Merlin - i.e. from a component implementation point of view "if it
happens its ok - if it doesn't happen - there's a good reason". What I
mean is that a component implementation should not need to worry about
authentication - instead it should declaring any specific assumptions
with its type definition. Based on this, together with deployment
directives we should be able to handle authentication inside the
component model and runtime on behalf of the component instance.
> Based on that experience, I got
> the idea that a cascading security model should be provided, in which each
> component has its own security model that cannot violate the security
> constraints imposed by its surrounding container.
This was the initial approach that Nicals and I stated off with but
there is a problem. The cascading container model deals explicitly with
the management of classloaders, class visibility (and isolation). While
its convenient to think about the container hierarchy as a structure
for other things - its basically nailed down relative to the classloader
management model.
Instead - I'm moving away from this toward an different model in which
policies are expressed in a different model that is applied to a
component hierarchy via a map.
> The other thing I learnt was not to differentiate/favourize codesource with
> subject. After all, security is about WWW (Where codesource, Who subject,
> What guarded resource).
>
> Regarding "assign grants to 'components' instead of codebases", I would
> think you can solve it by a special purpose classloader. When a component
> is loaded by the classloader, simply assign the component its own
> codoesource, that is different from its physical codesource. A similar
> approach is taken in Sun's J2EE 1.3 reference application server.
My feeling is that the usage of codesource as a mechanisms to implement
a policy is the wrong approach (but I could easily be wrong).
To me a codesource does not let me distinguish things in terms of the
usage of a component (or more specifically - the functional contribution
of the component in a system) as opposed to attributes of a class. That
functional contribution should be declared independently of the
code-source. At runtime I would need to consolidate component policy
with codesource policy prior to granting a permission.
In the longer term I see this as a general approach - plugable
permission schemes --> scheme aggregation --> access decision.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Secure Kernel in Merlin
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 04 April 2004 06:19, Nader Aeinehchi wrote:
> The way I see it, you need some abstraction of various components in the
> security:
>
> 1. Security Provider(s)
> 2. Security Facade
> 3. Security Brain (AccessController, SecurityManager, SecurityEngine or
> whatever you like to call it)
You are already flying sky high in Subject level security. I agree that is
where most business-logic people will be interested in, but without nailing
down the lower layers, you only have a perceived secured system, instead of a
guaranteed secure system.
> Now the Sun's approach is very nice and powerful, but it is too abstract
> most organizations.
Yes, it is. And it is our job to take the building blocks (standard + JAAS)
provided by Sun and create a useful implementation. I.e. At JAAS level we
will need to 'componentize' the LoginModule and Permission systems, so it can
be tailored and reused more easily to various scenarios.
>From my head, I see it something like this;
In the component, we would then have;
public void contextualize( Context sc )
{
m_SecurityContext = (SecurityContext)
sc.get( "urn:security:context" );
}
public void someEntryPointMethod()
throws SecurityException
{
m_SecurityContext.login();
:
:
}
public void someExitPointMethod()
throws SecurityException
{
m_SecurityContext.logout();
:
:
}
public MyGuardedObject getMyGurardedObject()
{
Permission required = new MyGuardedObjectPermission();
m_SecurityContext.checkPermission( required );
:
}
And in the SecurityContext class, the login() method needs to delegate to
something that can track the Principal across multiple requests (such as a
Web environment), so a 'credential' object may be needed to be passed in the
login() method.
The checkPermission method in the SecurityContext would probably just do
something like;
Acl acl = getTheAclFromAProvider();
Principal p = m_LoginContext.getSubject();
acl.checkPermission( p, required );
Or possibly delegate that particular code snippet to a pluggable provider, so
you can implement your own...
These are my thoughts, and could well be far off the target... :o)
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Secure Kernel in Merlin
Posted by Nader Aeinehchi <na...@aeinehchi.com>.
Hi Alex
> Nadar this is all great stuff. You should be working with us to bring
this
> about. Personally I'm working on an embeddable LDAP server based on
Merlin
> which I'm hoping can be incestuously reused for the security backing store
> of Merlin as well as other containers even EJB servers. Perhaps we can
> discuss this.
Well, the we actually did it in the project was to ask an EJB session bean
as the security provider. Basically, it does not matter whether it is LDAP,
database, backend system, a static policy file....
The way I see it, you need some abstraction of various components in the
security:
1. Security Provider(s)
2. Security Facade
3. Security Brain (AccessController, SecurityManager, SecurityEngine or
whatever you like to call it)
Now what is what?
1. Security Provider is the provider of security. It provides Authenticator
and/or Authroizer and/or Auditor. A valid question is whether Auditor
should be a part of a Security Provider?
I am personally not sure, but usually Audit function is as important as
Authentication and Authorization although many organization never bother to
audit.
Now the system would definitely have more than one security provider, why?
In a multi-application environment (like an EJB container), each application
(call it Merlin-component), has usually its own security model and needs its
own security provider. Say my banking application wants to talk to
mybank.com and ask their CICS server for the security model at the same time
that my telecom application asks the LDAP server in mytelecom.com.
So you end up having one or more Security Providers.
2. Security Facade (or whatever you like to call it) would be responsible to
abstract the communication with various Security Providers.
Usually you do not want your applications to open up an URL or make a
network connection using strange ports through your firewall to speak with
strange security providers.
You would probably want to control who is talking to whom. Furthermore, you
would probably want to configure(declare) what application/component should
ask which security provider.
Another thing is that you would like to expose the same interface, so that
if you change the provider or the providers' implementation, the
application/component be kept almost intact.
3. Now, the last but the most important thing is the authorizer part which
is kept in this Security Brain guy. Frankly, I cannot find a good name for
it because all the good names (Access Controller and Security Manager) are
taken by Java. Maybe Security Engine is good word? Anyway, Java sees at
Access Controller as the guy the check the permission for a given CodeSource
and Subject.
Now the Sun's approach is very nice and powerful, but it is too abstract
most organizations. If you come from a Role driven environment, say
database people , they usually think to guard resources based on Role/Group
privilege. In such environments, you usually make a distinction between the
Guarded Resource (say a table), Access Controller List (RoleA has WRITE
permission, RoleB has WRITE and DELETE permissions etc) and the Guard
itself. Well, these things actually can be achieved with Java, but they are
not directly provided with J2SE. However, J2EE provides to some degree
these things through Method Level Security (you enforce security
declaratively on each method in ejb-jar.xml).
Well, there is a problem with J2EE (at least for a business application).
Firstly, it does not support fine-grained security on object level (like)
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: "Alex Karasulu" <ao...@bellsouth.net>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Saturday, April 03, 2004 4:40 PM
Subject: RE: Secure Kernel in Merlin
>
>
> > -----Original Message-----
> > From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> > 1. Merlin's Kernel is pretty limited, and not really worth adding any
> > security
> > > features, since the same can basically be done by the
> > java.security.policy
> > > file.
> >
> > 2. The interesting parts lies in the possibility to assign grants to
> > 'components'
> > > instead of codebases
>
> Still the same thing except your using the component's set of classes as
the
> code base specifier instead of using a package based specifier. But it is
a
> very convenient feature I agree we should have it.
>
> > 3. Next step is to make a facility which provides the JAAS style subject
> > level
> > > security
>
> Yep we might need to sprinkle a little bit of JAAS and JACC into this.
> Personally I find Java security appalling and it does slow things down. I
> do recommend that the ability to control security be on the level of
service
> methods like EJB in a way so it's not on all the time in places where you
> don't need it to be.
>
> It might just however be better to just use a general security mechanism
> free of all this crap so we don't run into conflicts when the container is
> embedded into a J2EE container.
>
> > For a customer, I developed a security service that incorporated
security
> > in
> > kernel (a factory would decide whether to start in security mode or
not).
> > This secure kernel is build on JAAS, also both codebase and subject as
the
> > secure kernel at boot reads the policy file (say from a database or a
> > ldap)
>
> I like the LDAP idea :-)
>
> > and replaces the policy for the entire JVM.
> > Furthermore, I developed an extended security manager that could provide
> > addon features like method permission (similar to EJB declarative method
> > permission) etc. One point I learnt from this project is that the
> > underlying "components" may have a different security model than the
> > kernel.
> > Not only the authorization model may be different, but also each
component
> > may want to use a different authenticator. Based on that experience, I
> > got
> > the idea that a cascading security model should be provided, in which
each
> > component has its own security model that cannot violate the security
> > constraints imposed by its surrounding container.
> >
> > The other thing I learnt was not to differentiate/favourize codesource
> > with
> > subject. After all, security is about WWW (Where codesource, Who
subject,
> > What guarded resource).
> >
> > Regarding "assign grants to 'components' instead of codebases", I would
> > think you can solve it by a special purpose classloader. When a
component
> > is loaded by the classloader, simply assign the component its own
> > codoesource, that is different from its physical codesource. A similar
> > approach is taken in Sun's J2EE 1.3 reference application server.
> >
>
> Nadar this is all great stuff. You should be working with us to bring
this
> about. Personally I'm working on an embeddable LDAP server based on
Merlin
> which I'm hoping can be incestuously reused for the security backing store
> of Merlin as well as other containers even EJB servers. Perhaps we can
> discuss this.
>
> Alex
>
>
>
>
> ---------------------------------------------------------------------
> 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
RE: Secure Kernel in Merlin
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Nader Aeinehchi [mailto:nader@aeinehchi.com]
> 1. Merlin's Kernel is pretty limited, and not really worth adding any
> security
> > features, since the same can basically be done by the
> java.security.policy
> > file.
>
> 2. The interesting parts lies in the possibility to assign grants to
> 'components'
> > instead of codebases
Still the same thing except your using the component's set of classes as the
code base specifier instead of using a package based specifier. But it is a
very convenient feature I agree we should have it.
> 3. Next step is to make a facility which provides the JAAS style subject
> level
> > security
Yep we might need to sprinkle a little bit of JAAS and JACC into this.
Personally I find Java security appalling and it does slow things down. I
do recommend that the ability to control security be on the level of service
methods like EJB in a way so it's not on all the time in places where you
don't need it to be.
It might just however be better to just use a general security mechanism
free of all this crap so we don't run into conflicts when the container is
embedded into a J2EE container.
> For a customer, I developed a security service that incorporated security
> in
> kernel (a factory would decide whether to start in security mode or not).
> This secure kernel is build on JAAS, also both codebase and subject as the
> secure kernel at boot reads the policy file (say from a database or a
> ldap)
I like the LDAP idea :-)
> and replaces the policy for the entire JVM.
> Furthermore, I developed an extended security manager that could provide
> addon features like method permission (similar to EJB declarative method
> permission) etc. One point I learnt from this project is that the
> underlying "components" may have a different security model than the
> kernel.
> Not only the authorization model may be different, but also each component
> may want to use a different authenticator. Based on that experience, I
> got
> the idea that a cascading security model should be provided, in which each
> component has its own security model that cannot violate the security
> constraints imposed by its surrounding container.
>
> The other thing I learnt was not to differentiate/favourize codesource
> with
> subject. After all, security is about WWW (Where codesource, Who subject,
> What guarded resource).
>
> Regarding "assign grants to 'components' instead of codebases", I would
> think you can solve it by a special purpose classloader. When a component
> is loaded by the classloader, simply assign the component its own
> codoesource, that is different from its physical codesource. A similar
> approach is taken in Sun's J2EE 1.3 reference application server.
>
Nadar this is all great stuff. You should be working with us to bring this
about. Personally I'm working on an embeddable LDAP server based on Merlin
which I'm hoping can be incestuously reused for the security backing store
of Merlin as well as other containers even EJB servers. Perhaps we can
discuss this.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Secure Kernel in Merlin
Posted by Nader Aeinehchi <na...@aeinehchi.com>.
1. Merlin's Kernel is pretty limited, and not really worth adding any
security
> features, since the same can basically be done by the java.security.policy
> file.
2. The interesting parts lies in the possibility to assign grants to
'components'
> instead of codebases
3. Next step is to make a facility which provides the JAAS style subject
level
> security
For a customer, I developed a security service that incorporated security in
kernel (a factory would decide whether to start in security mode or not).
This secure kernel is build on JAAS, also both codebase and subject as the
secure kernel at boot reads the policy file (say from a database or a ldap)
and replaces the policy for the entire JVM.
Furthermore, I developed an extended security manager that could provide
addon features like method permission (similar to EJB declarative method
permission) etc. One point I learnt from this project is that the
underlying "components" may have a different security model than the kernel.
Not only the authorization model may be different, but also each component
may want to use a different authenticator. Based on that experience, I got
the idea that a cascading security model should be provided, in which each
component has its own security model that cannot violate the security
constraints imposed by its surrounding container.
The other thing I learnt was not to differentiate/favourize codesource with
subject. After all, security is about WWW (Where codesource, Who subject,
What guarded resource).
Regarding "assign grants to 'components' instead of codebases", I would
think you can solve it by a special purpose classloader. When a component
is loaded by the classloader, simply assign the component its own
codoesource, that is different from its physical codesource. A similar
approach is taken in Sun's J2EE 1.3 reference application server.
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: "Niclas Hedhman" <ni...@hedhman.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Saturday, April 03, 2004 12:46 PM
Subject: Re: Secure Kernel in Merlin
> On Saturday 03 April 2004 18:22, Nader Aeinehchi wrote:
> > In many systems I have looked at, a kernel typically starts several
> > containers which in turn may start other containers/applications.
>
> Merlin's Kernel is pretty limited, and not really worth adding any
security
> features, since the same can basically be done by the java.security.policy
> file.
>
> The interesting parts lies in the possibility to assign grants to
'components'
> instead of codebases, as they may share the codebase, i.e. permissions for
> the same codebase is given depending how it is 'mounted' in the
application
> hierarchy.
>
> That is what we are trying to solve now.
>
> Next step is to make a facility which provides the JAAS style subject
level
> security.
> I have a rough cut on how that would work in my head, but nothing written
> down.
>
> Niclas
> --
> +---------//-------------------+
> | http://www.bali.ac |
> | http://niclas.hedhman.org |
> +------//----------------------+
>
> ---------------------------------------------------------------------
> 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
Re: Secure Kernel in Merlin
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 April 2004 18:22, Nader Aeinehchi wrote:
> In many systems I have looked at, a kernel typically starts several
> containers which in turn may start other containers/applications.
Merlin's Kernel is pretty limited, and not really worth adding any security
features, since the same can basically be done by the java.security.policy
file.
The interesting parts lies in the possibility to assign grants to 'components'
instead of codebases, as they may share the codebase, i.e. permissions for
the same codebase is given depending how it is 'mounted' in the application
hierarchy.
That is what we are trying to solve now.
Next step is to make a facility which provides the JAAS style subject level
security.
I have a rough cut on how that would work in my head, but nothing written
down.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Secure Kernel in Merlin
Posted by Nader Aeinehchi <na...@aeinehchi.com>.
Thanks for the your answers.
> > 4. If the answer to questions 1. and 2. is no (i.e. no security in
kernel),
> > would you rather develop security in each Container?
>
> Not sure what you mean by "Container" in this context. Typically we talk
about
> Merlin being a Container, but I assume you are thinking of something else.
In many systems I have looked at, a kernel typically starts several
containers which in turn may start other containers/applications. The
question is whether not to introduce security in kernel, but rather
introduce it in higher level layers (with kernel as the lowest level layer)?
If one thinks of a simple kernel (say a micro kernel), the kernel does not
want to be doing too many things. it simply manages the higher level
layers, but it is the responsibility of the higher level layers to take care
of things like error management, security etc. I am not asserting this to
be a fact, but rather ask you for your opinion?
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: "Niclas Hedhman" <ni...@hedhman.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Saturday, April 03, 2004 12:11 PM
Subject: Re: Secure Kernel in Merlin
> On Saturday 03 April 2004 17:53, Nader Aeinehchi wrote:
> > 1. Would it be an idea to build in security in default kernel? Are there
> > any reasons not to build security in default kernel? 2. If the answer in
> > question 1. is no, would it be an idea to develop a SecureKernel?
>
> We have made some various attempts at different security mechanism at
> codelevel, leveraging the standard Java security mechanism, but there are
> "issues" surfacing when we get to it at a detail level.
>
> It is a high-priority matter, since we need to sort this out prior to
moving
> on to Subject level seurity, i.e. leveraging the JAAS.
>
> > 3. If you were going to build security in kernel (either DefaultKernel
or a
> > SecureKernel), would you build it upon Java's security API
> > (AccessController/SecurityManager, Policy, ProtectionDomain, JAAS etc)
or
> > would you rather build your own security component?
>
> As much as possible needs to be leveraged, since we are not in the
position to
> dissect the basic research underlying the security matters. Sun have done
> that, and we can just harness their efforts.
>
> > 4. If the answer to questions 1. and 2. is no (i.e. no security in
kernel),
> > would you rather develop security in each Container?
>
> Not sure what you mean by "Container" in this context. Typically we talk
about
> Merlin being a Container, but I assume you are thinking of something else.
>
> Niclas
> --
> +---------//-------------------+
> | http://www.bali.ac |
> | http://niclas.hedhman.org |
> +------//----------------------+
>
> ---------------------------------------------------------------------
> 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
Re: Secure Kernel in Merlin
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Saturday 03 April 2004 17:53, Nader Aeinehchi wrote:
> 1. Would it be an idea to build in security in default kernel? Are there
> any reasons not to build security in default kernel? 2. If the answer in
> question 1. is no, would it be an idea to develop a SecureKernel?
We have made some various attempts at different security mechanism at
codelevel, leveraging the standard Java security mechanism, but there are
"issues" surfacing when we get to it at a detail level.
It is a high-priority matter, since we need to sort this out prior to moving
on to Subject level seurity, i.e. leveraging the JAAS.
> 3. If you were going to build security in kernel (either DefaultKernel or a
> SecureKernel), would you build it upon Java's security API
> (AccessController/SecurityManager, Policy, ProtectionDomain, JAAS etc) or
> would you rather build your own security component?
As much as possible needs to be leveraged, since we are not in the position to
dissect the basic research underlying the security matters. Sun have done
that, and we can just harness their efforts.
> 4. If the answer to questions 1. and 2. is no (i.e. no security in kernel),
> would you rather develop security in each Container?
Not sure what you mean by "Container" in this context. Typically we talk about
Merlin being a Container, but I assume you are thinking of something else.
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org