Hi Ben,
you made some good points. I realized that I indeed have to be a bit
more specific on the scope I am looking at the spec right now.
Let's assume you are creating a device, which is running J2SE, so you
can deploy anything you want there. In fact, it is not anything, but
an OSGi framework. So further more there is an application A running
inside of the container. This is the state you deliver it to your
customers. However, time doesn't stand still and you want to provide
let's say add-on features your customers should be able to buy/get
after your device is delivered. So far no problem with OSGi, actually
it is extremely nice. The problem occurs when you include external
requirements, such as the Application A has to be certified against
very specific and strong security requirements. You have to provide a
separation on application level, which is static (in order to be
evaluated) and can't be tampered with. So if the customer has the box,
there mustn't be a chance to circumvent the defined security policies
for this device, no matter what happens.
Java Policies, although not that expressive as CPA are a good way to
at least provide the the first bundle with a Permission to set
conditions for the environment I thought. The OSGi spec, as far as I
can tell, pretty much focuses on running the framework and here I
don't see any problems from my perspective. The Problems I see are
only related to the description on how to set up the first initial
(really) safe environment.
Java defines initial policies, which provide a basis set of
permissions, which define the initial Sandbox. Starting from here you
can gradually add permissions on an as needed basis until you reach
your satisfying permission set. Despite the default permission
everyone has, only permissions you explicitly added are granted to
CodeSources/ProtectionDomains. Now, considering all the replies, in
OSGi this is different and important to know about. Here the initial
state is "open" unless a custom bundle is deployed, which sets the
Permissions as needed. This setting of permissions is a little tricky,
I think. Plain Java doesn't provide a deny statement, but this is
actually something you need here. In my opinion not intuitively, but
you can work around this by applying <null> for the condition(s) and
(not sure) <null> for the permission(s) (or your own custom
NoPermission permission) in CPA, but I think this should be mentioned
in order to show the parallels to plain Java. Actually an
AllBundleCondition together with a NoPermission permission would be
nice to indicate the scope directly.
Well, I understand that in theory everything is possible, but I was
just hoping OSGi being more Security enforcing. After having thought
about the issues, I could imagine a scenario, where OSGi first only
allows the access to the CPA and as soon as a bundle uses the CPA,
these management rights are bound to only this bundle. Now, this
bundle can do what ever it wants in contrast to the others. The only
plus here is, that unless something unsafe is defined, the FW is safe
by default. Well, this is just a sample, one doesn't need anything
like that to provide security of course, but reading the spec right
now, without having this conversation makes it hard (at least for me)
to fully understand the implications derived from the deviations of
the Java default behavior. That's all.
So this was my view with my Architect hat on, with security evaluator
hat, it becomes more complicated. Java is a well recognized standard
and so the effort to evaluate its security architecture is relatively
simple, because many things can be taken as granted. OSGi however with
its own Permission handling and the dynamism provides an additional
layer, which introduces new (potential) threats and weaknesses. Here
every lack in detail have to be evaluated for every implementation,
which makes swapping of frameworks hard and more important expensive.
As a typical sample of a implementation issue... A implementor can
decide to cache/safe installed bundles together with other stuff in
its "proprietary" way in order to safe state and other information. If
someone now tries to manipulate these information, the framework has
to have a mechanism to detect those manipulations, I think, but I
never read it anywhere...
Anyway, now I have a way better understanding of the OSGi way, so you
guys already helped me a lot! Thanks for that. I added some comments
on the last replies, some repeat what I already said in different
words, sorry for the length.
Best Regards,
Mirko
<quote>
I think you might be confusing the security architecture with the
Policy model and Default Policy. We use the Java 2 Security
Architecture to implement ConditionalPermissionAdmin. (We have to,
Java 2 Security is a rather intrinsic part of the JVM.) The Java 2
Default Policy is implemented with a static file that encodes a
specific policy. It is certainly not the only way of encoding
Policy, it's the default. It's not even the best way. Especially
the absence of scoping introduced in OSGi makes it hard to use
signatures and still get least privilege unless you explode the
number of signatures and you do a lot of manual policy tweaking.
For CPA we needed a dynamic policy, we aren't going to restart
things when the policy changes, and we needed to be flexible with
are assignment criteria.
</quote>
Well, as part of the initial provisioning, I would consider policies
important in the Security Architecture. Of course the Sun-way of
defining policies is an implementation detail and surely not the best
in every scenario - I know, but the internal handling/ representation
is located in java.security.Policy class so, I think this is a good
indicator to consider it a part of the Javas Security Architecture.
And again, yes the file is static, but the Policy class itself has the
capabilities to update its policies. Don't get me wrong on this one, I
prefer the flexibility offered by OSGi, I was just trying to say that
the Policies are the "natural" way in Java to provide some initial
security provisioning and that this part (no matter how it is handled
in OSGi) is left out completely in the spec. For me, coming from plain
Java Security., it wasn't easy to figure out what "compatible with the
Java 2 Security Architecture" actually involves. Currently, I am not
interested in the dynamic capabilities of the OSGi Security
Architecture, because we just can't use it in our scenario. What we
need is a way to define a secure environment from startup, which can't
be tempered with.
<quote>
No, the principle of least privilege says you only get the
privileges you need. The initial bundle is going to setup the
permissions to all other bundles, so it must have, in effect,
AllPermission.
Perhaps you just want a standard way of specifying the initial
config file. Is that it? As you point out, CPA has a superset of
the functionality of the Default Policy file, we just don't say
where it is stored.
(I'm sure you realize that once you use CPA to change the
permissions it is persistently stored, so this whole discussion is
just about the what happens when you start the framework for the
first time with no policy set. The general idea is the next bundle
you install would be the bundle to setup the permissions at which
point the discussion is over.)
</quote>
Correct. I am just looking on the very first startup.
<quote>
You can assign permissions to bundles based on something other than
signatures, so we don't require bundles to be signed. If a bundle
is signed, but the contents don't match the signature, it has
obviously been tampered with, so it seems obvious that it should
not be used: the packager purposely signed it and it was changed
after packaging. I think a case can be made for using a bundle that
is signed by an unknown signer, but we erred on the side of safety.
</quote>
You are right and I really like this behavior, but I think, this alone
is not enough - it gives a false idea of security - if someone tampers
with the bundle and knows about this behavior, the easy workaround is
just removing the signature. Of course, this will most likely change
the conditions under which the previous rights were granted, I know.
The problem I see here is that if you are not aware of the fact that
bundles without a signature are allowed by default (and if no special
conditions are applied) are granted AllPermission can create a serious
security hole. For a holistic view on security I would at least
mention that in this particular context.
<quote>
No, CPA is a framework service. It is always active. It hooks right
into class loading. It does not get started or shutdown. The
service is just a view into the framework.
</quote>
Well, I thought so, but for some strange reasons, I first manged to
set up the server in a wrong way (I guess). As a result I got this
message: org.osgi.framework.BundleException:
ConditionalPermissionAdminService not available. Stop.
This is fixed now, so don't worry about this, but maybe you understand
now, how my questions were motivated. A service (no matter how thin)
is another abstraction, which can be miss configured, miss used, etc..
I was/am just trying to find a way to set my initial environment as
secure as possible in a standardized way.
<quote>
It would be relatively easy to write an initial bundle that reads the
default java policy file and populates the CPA that way, but I would
think in general you want a policy that depends on the specific
deployment or application rather than the Java install. (This is
especially true when you are running multiple OSGi instances on the
same machine.)
</quote>
If you are talking about multiple JVMs you can just provide your
custom policy file, extending the default one. If you are talking
about one JVM it becomes nasty, here you really have only one Scope,
where potentially mutliple policy files contribute to, so it is a mess
to seperate the different issues (although possible).
<quote>
I'm not sure why you are talking about the StartLevelService. Is it
because you didn't realize that the changes to policy done through the
CPA are made persistent by the framework?
</quote>
Well, who defines, which is the first bundle to load on a box you
don't have access to (except for the initial configuration)? I don't
run it even once (or at least I don't want to be forced to!). SLS also
doesn't have a specification for a config file (again, everything is
runtime focused and service based), but all vendors implement their
own way of defining it - not nice, if you ask me, but I can life with
it.
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
