Hi Florian,
Thank you for confirming me what
I thought, it is not secure at all to allow unsigned bundles to be installed,
with signed bundles from any Certification Authority all together. I was using
Bouncy Castle Libraries in order to Encrypt data with Web Services, there are a
lot of solutions either to check digital signatures, but the problema it is the
integration with Equinox. I do not really not how It is possible to integrate
these solutions with Equinox.I could look for some solution when I finished my
work testing Bundles. I will inform you with any advance.
Thank you again
David
De:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] En
nombre de Pepping, Florian
Enviado el: miércoles, 13 de mayo de 2009 15:50
Para: Equinox development mailing list
Asunto: RE: [equinox-dev] Security Doubts
Hi David,
for your last question, I can give you a short answer:
No, there is no possibility to forbid the installation of unsigned
bundles.
In the current version of OSGi/Equinox there seems to be only a
verification of signed bundles. Only if a signature of a signed bundle cannot
be verified, this bundle is not beeing installed. If no signature is present at
all, this bundle is installed without further investigation.
As I remember, this mechanism was introduced to determine if a
bundle is not corrupted during network distribution and check the
CRC-checksum. It currently is not designed to provide attacks against modified
bundles or against exchange of bundles.
Perhaps you can read my thread for a similar topic on equinox-dev a
few days ago:
It would be great, if you could provide a mechanism to forbid
unsigned bundles of being installed or to make sure a framework-hook is
mandatory for a framework start. In such a framework hook, all other tasks
could be performed than.
I look forward to your further investigations. Perhaps we can both
benefit from our experiences.
From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of David Conde
Sent: Wednesday, May 13, 2009 2:51 PM
To: 'Equinox development mailing list'
Subject: RE: [equinox-dev] Security Doubts
Hi Florian,
Thank you very much for your
answers.
The problem was solved, I was writing wrong the Bundle name which was
controlled by BundleLocationCondition, if I wrote the name which appears when I
typed “bundle ID_BUndle” in console, no permission was activated,
but instead of that, if I write the Bundle Simbolyc name, I got good results.
Let’s say if my
BundleConsumer has:
Symbolic name:
ServiceConditionalConsumer_1.0.0
And when I type bundle command
my_bundle_ID I got: C:\myfolder\ServiceConditionalConsumer_1.0.0.jar If I wrote
this one in the ConditionInfo no result appeared.
By the way, Is there any way to
forbid the unsigned Bundles installation? I tried with the next command, but no
results were got.
java -Djava.security.manager=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager
-Djava.security.policy=policy.policy
-Dosgi.framework.keystore=autoridadcertificadora.keystore
-Dosgi.signedcontent.support=authority -Dosgi.signature.support.verify=true
-jar org.eclipse.osgi_3.4.3.R34x_v20081215-1030.jar -console
And whatever bundle can be
installed, either unsigned or bundles signed by other Certification Authority?
I do not understand why
installation to unsigned bundles is allowed at the same time that Bundles
modified are forbidden, because in this way, any bundle could be
installed.
Is there any example about
signatures which has been tested?
Thank you in advance
David
De:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] En
nombre de Pepping, Florian
Enviado el: viernes, 08 de mayo de 2009 16:34
Para: Equinox development mailing list
Asunto: RE: [equinox-dev] Security Doubts
Hi David,
I will try to answer some of your questions concerning the handling
of Permissions in Equinox.
First of all, activate security with the following properties:
-Declipse.security=org.eclipse.osgi.framework.internal.core.FrameworkSecurityManager
-Djava.security.policy==../path/to/security/policy/FrameworkSecurity.policy
And use this property for debugging the security problems:
-Djava.security.debug=access:failure
The FrameworkSecurity.policy should contain
java.security.AllPermission, so that the Framework is free
to operate. There may be a possibilty to constrict the
Framework-Permissions to a smaller set, but it's
very difficult to start with.
Afterwards, activate the ConditionalPermissionAdmin with code
looking like this:
ServiceReference
cpaService = context.getServiceReference(ConditionalPermissionAdmin.class.getName());
if (cpaService != null)
{
ConditionalPermissionAdmin
cpa = (ConditionalPermissionAdmin) context.getService(cpaService);
ConditionInfo ci = new ConditionInfo("[org.osgi.service.condpermadmin.BundleLocationCondition
"*"]");
PermissionInfo pi = new PermissionInfo("( java.util.PropertyPermission
\"*com.test.onetwothree.*\" \"read,write\" )");
cpa.setConditionalPermissionInfo(oid, new ConditionInfo[] { ci }, new
PermissionInfo[] { pi } );
}
With this piece of code, all Bundles with Symbolic-Name
"com.test.onetwothree.*" have just one permission: read and write all
properties.
These permissions have to be configured in your java code.
Currently there is no official way to configure these permissions by file. An
example on how to do this anyway can be found in the OSGi Spec
Version 4.1 April 2007 on page 237.
Last but not least, a permissions.perm file can (but must not)
be created in the subdir OSGI-INF in each bundle. In this permissions.perm file
the bundle developer can outline all permissions, that his bundle
needs to operate. The framework guarantees, that this bundle never gets
more
permissions, than defined in the permissions.perm, also more global
permissions are available for this bundle. So, the actual permissions
for a bundle is the intersection of the global permissions and the
permissions in the permissions.perm file. If no permissions.perm file is
defined,
the bundle gets AllPermission (to be said: all global
permissions defined plus all permissions defined for this bundle via
condition.)
Having all these things configured, the Security-Framework of
equinox should work.
Good luck.
Florian
From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of David Conde
Sent: Friday, May 08, 2009 2:30 PM
To: 'Equinox development mailing list'
Subject: [equinox-dev] Security Doubts
Hi everyone,
These previous days I have been trying and reading a lot
about securiy in OSGI. I tried Local Permissions in Equinox and they were ok,
and I either tried with some examples using Conditional Permissions and I did
not got any result at all.
I have tried with this example : http://dz.prosyst.com/pdoc/mbs_ext_6.1/um/meg/developer/osgi/mobile_conditions/mobile_conditions.html
Changing it to include both BundleLocationCondition
and BundleSignerCondition but no result at all. I would like to know if
somebody has done some example with Conditional Permission in Equinox and he
got any result. Could people who got the expected results with Conditional Permission
tell me this scenario where Conditional Permission Works?Either if I need some
special permissions or some special way of launching Equinox Framework by
console using special options.
I have tried with several versions of Equinox, 3.3, 3.4,
3.5. In Equinox 3.5 when I launch with Security options, typing
security.manager parameter equal to “osgi”, I do not get anything,
I do not get neither Exception nor anything, just it is like no command was
launched.
With Equinox 3.4 I achieved to run Local Permissions, but
when I tried with Equinox 3.5 in order to check Conditional Permissions but
I haven’t get any result. It is like nothing is taking into account
what I write in PermissionManager (see the link written above). What do I need
in my PermissionManager Bundle to grant permissions? I put ALLPermission in
this bundle, but Do I need any permission else?
The last question, why Don’t Equinox verify my bundles
signature when I install them handly by console using install command? I use a
keystore different on the keystore which signed the bundles and I do not get
any Exception.
It is strange because whatever keystorename that I write
in -Dosgi.framework.keystore=cakeystore.keystore is valid, even If I put
a keystore_name invented which does not exit, I do not get any Exception and
“OSGI>” environment appears.
So I am sorry for so many questions but I think that I
can’t continue without some piece of advice.
Thank you very much in advance
David
WINCOR
NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen
Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr.
DE44477193
Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie
bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This e-mail may contain confidential information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.
WINCOR
NIXDORF International GmbH
Sitz der Gesellschaft: Paderborn
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen
Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr.
DE44477193
Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige
Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie
bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte
Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.
This e-mail may contain confidential information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender
immediately and destroy this e-mail. Any unauthorised copying, disclosure or
distribution of the material in this e-mail is strictly forbidden.