Thanks you guys for your help. I realized that I wasn't precise enough
to capture the core of my problem so, here is a more detailed version.
I agree that the "core" bundle with ALL core services acts as a single
block and must have all permissions and none of the core services can
be shut down. In a J2SE environment I would use the following syntax
to grant those rights when signed with a specific signature:
grant signedBy "OSGiFW" {
permission java.security.AllPermission;
};
With that, I can allow the framework to do what ever it wants. So far
so good. Now, my FW is running and I am going to deploy two bundles,
because with out them the FW is pointless of course :-) Bundle A and B
are bundles using the CPA Service of the core FW to set the security
policies of the whole environment. Bundle A is signed by a "trusted"
organization (f.i. "ACME", Bundle B is a fake bundle some intruder
tries to sneak in (for instance with a fishing like attempt during
downloading from a website - just a silly example, don't nail me with
that one, please).
Now, we come to my problem what happens next? I would have assumed
that a policy file entry like:
grant signedBy "ACME" {
// not very restrictive, but it is just an example
permission org.osgi.framework.AdminPermission
"org.osgi.service","lifecycle";
permission org.osgi.framework.PackagePermission "org.osgi.*", "import";
permission org.osgi.framework.ServicePermission "org.osgi.*", "get";
};
should do the trick. Unfortunately this has to be implemented by the
OSGi FW to work. Responsible for loading classes, the OSGi FW also
handles the management of the custom ProtectionDomain(PD) of each
bundle. In this PD, information about the location and certificates
(as well as Principles actually) are stored. How this is done... up to
FW according to the spec. The only limitation is that for security
checks, the standard AccessController(AC) is used for backwards
compatibility (what ever that means - backwards to what?). However,
plain Java has a mechanism (based on location and certificates) to
automatically provide the permission defined in the policy file to
classes matching the CodeSource (grant statement in the policy file).
In the spec, I wasn't able to find anything stating that permissions
provided by plain Java have to be taken into account for bundles by
the CPA or PA. So the above mentioned example won't necessarily work
in all OSGi Frameworks to provide the FW with permissions it might
consider useful to decide what to allow and what to deny.
So, which permissions do our bundles actually need in order to set
permissions for other bundles? As already defined in the sample above
only OSGi specific permissions, so plain Java doesn't care, the OSGi
FW has to manage that. Now the tricky part. How does the FW know that
Bundle A is good and Bundle B is evil? There is no way (defined in the
spec) to define that bundle A is good and B is evil. After the start,
the FW has to allow at least the privileges to use any of the two
permission management services (CPA or PA). I think this is some sort
of a hen - egg problem. If the framework is running, I won't allow
anyone without the correct Permissions to manage permissions. If the
framework is not running (yet), I can't do so with services. Of
course, this is a more theoretical problem, because usually you don't
start with an empty framework and ask the user to install...
something. Usually you have a fixed set of bundles and a nicely
defined start order for those, in order to work around these issues,
but there is more about it.
If you don't take into account permissions provided to distinct
CodeSources, you'll run into problems in mixed environments like J2EE.
Of course in such an environment, you can grant the OSGi FW all
permissions, but you usually don't want to allow these to all webApps
you have deployed in your container and you certainly don't want the
(C)PA to manage permissions for non OSGi web applications as well. If
you ask, where the problem is, if the OSGi FW has all permissions, the
problem is the AC. If we assume we have a JEE container with a couple
of regular ears and a single osgi based web app with x number of
bundles. The OSGi FW is granted AllPermissions, but the bundles are
loaded with a new ClassLoader and a new custom PD, which potentially
doesn't provide a mechanism to apply permissions granted via policy
files. As a result, Java applies internally (in the AC) all
permissions for the default PD, which are almost no permissions. Now,
what ever policies you define in the (C)PA, it only works for OSGi or
other custom permissions. All native Java permissions like
SocketPermission will fail due to a call to the AC. Of course, like
always, there is a work around. One can just define the following
permission:
grant {
permission java.security.AllPermission;
};
The evil drawback now is, that ALL Java code (outside of OSGi) is
granted to do anything. This is surely not desired. That's why I am
asking how Java policies (f.i. provided by policy files) are handled
in OSGi - is that totally up to the implementer or does compatible to
Java 2 Security implies that this should be taken into account? There
is nothing mentioned in the spec with respect to policies and I wasn't
sure what behavior to expect.
Best regards and many thanks,
Mirko
Btw., I like the idea with BundlePermission.START. This would help to
create a more secure environment. Especially when you look into the
problems with resource management in Java in general. This might
prevent quite some potential security risks (especially when we are
looking into highly dynamic and updateable environments).
On Jan 29, 2008 9:19 AM, Peter Kriens <[EMAIL PROTECTED]> wrote:
> I think the key thing you missed is that Conditional Permission Admin
> is a framework service. It is tightly integrated with the framework.
>
> Normally the framework starts up with security when you set the
> security manager from the command line and specify the policy file for
> the framework. This is always AllPermission, I do not see it can be
> anything else because the framework must set the permissions of
> others. Because CPA is a framework service, it runs with AllPermission.
>
> Once the framework runs in a secure environment, the permissions for
> other bundles can be setup with Conditional Permission Admin.
> Normally, newly installed bundles will run in a very limited sandbox
> until they are granted more permissions.
>
> How this works in a J2EE environment, I do not know. I assume you must
> grant the framework application AllPermission because it does class
> loading and sets protection domains. However, I never tried this out.
>
> I think you read too much in section 9.2. These are deployment
> examples. The must is out of place there. The reason we stated that
> bundles with unrecognized certificates should not be allowed to run is
> that it is easy with CPA to setup a catchall condition for specific
> signers. The absence of this catchall seems to indicate something.
> Unsigned bundles are a special case and the permissions can be set to
> empty.
>
> I do agree that it sounds interesting to deny a bundle from running at
> all depending on the signature/no signature case. Maybe we need a
> BundlePermission.START to prevent bundles from even being started.
> This use case has not been raised so far. Normally, these issues are
> taking care of at the management agent level. Notice that the
> management agent can be restricted to only allow the starting of
> bundles that are signed by a specific signer. It is also quite easy to
> detect if a JAR contains a signature because the manifest sign files
> must be at the start of the JAR stream.
>
> Hope this helps, kind regards,
>
> Peter Kriens
>
>
>
>
>
>
>
>
> On 28 jan 2008, at 14:13, Mirko Jahn wrote:
>
> > Hi everyone,
> >
> > after starting to examine the OSGi spec with respect to security, I
> > came across a few questions, I'd like to address here. I have to
> > apologize for the length of the mail, but I wasn't able to capture it
> > accurately in a shorter version.
> >
> > The specification states: "If security checks are performed, they must
> > be done according to Java 2 Security Architecture. "[p.21] and "The
> > conditional permissions provide a very general model that is related
> > to, but different from the Java 2 Policy model."[p.235]. Does this
> > mean; conditions are an add-on mechanism or a replacement for Java
> > Policies? I actually would expect it to be an add-on in order to be
> > "according to the Java 2 Security Architecture", but there is space to
> > argue. Of course I thought about this question…
> >
> > One can argue that conditional based security provides everything you
> > need. You can use standard Java 2 permissions to define rules and you
> > can use custom as well as OSGi permissions. Conditions can capture
> > CodeSource equivalent filter mechanisms like location information or
> > provided certificates - so far so good.
> >
> > Unfortunately, in my point of view there is one major drawback. The
> > OSGi spec lacks a static or better initial configuration file
> > determine what are the startup permissions. In a simple scenario f.i.,
> > I only have a framework deployed with Security enabled. Who is now
> > allowed to grant right to new bundles? Of course, I can deploy a
> > bundle, which is using the ConditionalPermissionAdmin Service and sets
> > up everything. But who grants this bundle all the rights it needs. If
> > you run the framework, first allowing everyone to do everything is
> > obviously against Java Policies in terms of the least privilege idiom/
> > principle even though you can set the start order of bundles. So I
> > would actually expect Java policies to be used and mapped to OSGi
> > Conditions in the Permission Class.
> >
> > Ok, till now this is all pretty much theoretical and conceptual
> > discussion about taste, but what about Security and Application
> > Servers? You can't just run a J2EE server with "allow everything", if
> > you want to deploy a single OSGi FW based WebApplication among a dozen
> > others. Eventually you will need to provide a valid ProtectionDomain
> > object, which can handle Java policies provided to your server. Thus,
> > the ClassLoaders each OSGi FW uses to load its bundles need to provide
> > a PD where plain Java policies can be applied. Otherwise the default
> > policies take place with no CodeSource information, which would mean
> > applying permissions to everyone if you define Java permissions
> > without a destinct source or certificate. (I am excluding the problem
> > of Principal or the (most likely) not settable SecurityManager in this
> > environment, but that has to be taken into account as well.)
> >
> > Well, what I am trying to say here is that there is no description at
> > all in the spec, how the policy model in plain Java and the
> > conditional model in OSGi should work together. I think this should be
> > pointed out to some extend, no matter what the advice will be. For me
> > it would be interesting to see, what others think about that. Maybe I
> > am missing something. Not sure.
> >
> > Another point, which I found strange, is the handling of signatures.
> > On the one hand the spec states: "A Framework therefore must refuse to
> > run a bundle when a signature does not match the contents or it does
> > not recognize the signer." [p.230 section: 9.2.2], but it doesn't care
> > at all, if it is not signed. So if I sign my bundle with a random or
> > even verified signature, as long as it is not in my Keystore, the
> > framework will reject it, but if I don't sign it at all, it can be
> > run. I think there should be a flag or some sort of management API
> > allowing only signed bundles to be installed in order to offer an
> > advantage of this rejection mechanism. In Java, there is unfortunately
> > no standard way of rejecting any code from installation in general.
> > Only the permissions granted to this code are limited. Even if this
> > protects the environment from most attack scenarios, denial of service
> > attacks are still very simple to implement. Just create an infinite
> > loop and allocate memory. Eventually your JVM will crash. If you
> > managed to exploit other things first, you might even be able to
> > prevent the ConditionalPermissionAdmin configuration bundle from
> > starting, which eventually shuts down your entire security mechanisms.
> > So I guess in OSGi such a more strict mechanism might be a good idea.
> >
> > As a last point, "Figure 9.39 System, Local and Security permissions"
> > [p. 224] headline talks about "Security permissions", but I don't
> > actually know what these should be in distinction to System and Local
> > ones (they both are derived from java.security.Permission). In the
> > according chapter "Security permissions" are never mentioned at all. I
> > assume, "Security permissions" can just be left away, because it
> > doesn't provide any additional information.
> >
> > I am not a security expert, so if I got something wrong, please feel
> > free to correct me. As always, feedback is greatly appreciated.
> >
> > Thanks,
> > Mirko
> >
>
> > _______________________________________________
> > OSGi Developer Mail List
> > [email protected]
> > http://www2.osgi.org/mailman/listinfo/osgi-dev
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> http://www2.osgi.org/mailman/listinfo/osgi-dev
>
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
