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
declarationsSomething 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
