Re: how to enable felix verify the contents of a signed bundle

[Karl Pauls]

If I understand you correctly you want to:

a) prevent any bundle to open any socket

b) prevent bundles not signed by your certificate from being installed

In regard to a, can't you just put a DENY java.net.SocketPermission at the
beginning of your policy?

In regard to b, I guess the best I can think of in a hurry is to first
grant  AdminPermission["signer=CN=XZX,O=XYX,C=XX",LIFECYCLE] and then DENY
AdminPermission["*",LIFECYCLE]

Keep in mind that the permission order is important hence, if you e.g. for
b first allow AdminPermission LIFECYCLE for bundles signed by your CA and
then DENY AdminPermission it basically will only allow to install bundles
signed by your CA.

Does this help?

regards,

Karl

On Thu, Sep 15, 2016 at 11:38 AM, sid19039  wrote:
>
> Hello @Karl and @Robert, again thank you so much for your help.
> And I am sorry for this late reply for I got occupied in other priority
> activities.
> Yeah , I tried Robert's point and it worked well.
> We created our security bundle which reads the following policy file to
> bring it into picture via ConditionalPermissionAdmin.
> policy file:
> ALLOW {
>[ org.osgi.service.condpermadmin.BundleSignerCondition "CN=XZX, O=XYX,
> C=XX" ]
>( java.security.AllPermission "*" "*")
> } "Bundles Signed by XZX certificate get AllPermission"
> ALLOW {
>   [org.osgi.service.condpermadmin.BundleLocationCondition
> "file:/D:/dir_A/dir_B/felix-framework 5.4.0/bundle/*"]
>   (java.security.AllPermission "*" "*")
> } "Existing  bundles of felix"
> DENY {
>(java.security.AllPermission "*" "*")
> } "And give denied permissions to all bundles"
>
> In above set of permissions, first ALLOW set of permissions gives all
> permission to all bundles which are signed by our certificate. Second set
of
> permissions assign all permissions to all those bundles which are already
> present in felix framework default bundle directory. And Third set denies
> all permissions to all those bundles which are not signed by our
certificate
> or which are unsigned and which are not present in default bundle
directory
> of felix framework.
>
> Now, signed bundles are successfully installed, become active and run fine
> with all permission granted.
> But we want to restrict all running bundles to not able to access any
> ethernet port on device inside which our felix framework is running. How
can
> we deny this particular permission to a bundle?
>
> Moreover, a bundle which is not signed or signed with any other
certificate,
> also gets installed in the framework without giving any security
exception,
> though an *unresolved exception as shown below*, appears on the console
when
> we try to start this unsigned bundle:
>
> *org.osgi.framework.BundleException: Unable to resolve TCPModBus [14](R
> 14.0): missing requirement [TCPModBus [14](R 14.0)] osgi.wiring.package;
> (&(osg
> i.wiring.package=org.osgi.framework)(version>=1.3.0)) Unresolved
> requirements: [[TCPModBus [14](R 14.0)] osgi.wiring.package;
> (&(osgi.wiring.package=o
> rg.osgi.framework)(version>=1.3.0))]*
>
> Is there any way to prevent these unsigned bundles or bundles signed with
> other certificates from even being installed into the framework?
>
>
> Regards
> Siddharth
>
>
>
>
>
>
>
> --
> View this message in context:
http://apache-felix.18485.x6.nabble.com/how-to-enable-felix-verify-the-contents-of-a-signed-bundle-tp5018089p5018412.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>



--
Karl Pauls
karlpa...@gmail.com

Re: how to enable felix verify the contents of a signed bundle

[Robert Onslow]

Sid
I'm afraid I don't know the answer to this question. Sorry
Robert

On Fri, Oct 21, 2016 at 12:44 PM, sid19039  wrote:
> Hello,
>
> Please provide some inputs/suggestions on the above scenario...
>
> Regards
> Siddharth
>
>
>
> --
> View this message in context: 
> http://apache-felix.18485.x6.nabble.com/how-to-enable-felix-verify-the-contents-of-a-signed-bundle-tp5018089p5018958.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: how to enable felix verify the contents of a signed bundle

[sid19039]

Hello,

Please provide some inputs/suggestions on the above scenario...

Regards
Siddharth



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/how-to-enable-felix-verify-the-contents-of-a-signed-bundle-tp5018089p5018958.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org

Re: OSGi - Reactive Paradigm

[Timothy Ward]

Hi,

I’d suggest that you look at OSGi PushStreams in the latest OSGi specification 
draft (Chapter 706 https://osgi.org/download/osgi.cmpn-7.0.0-earlydraft1.pdf). 
There’s an implementation drop due in Apache Aries this week, and I’ll be 
presenting about them at the OSGi Community Event next week.

Do get back to me if you have any questions.

Regards,

Tim


On 21 Oct 2016, at 10:53, bokie 
> wrote:

An opportunity has come up to include OSGi in a new project I'm involved in.
I'd like to hear some opinions, consideration to take into account and
perhaps some experiences with focus on how the reactive paradigm should fit
in a very dynamic OSGi ecosystem where services can come and go at any time.

With the code below as an example, my concerns are primarily with the
subscribe method where we are essentially passing it a listener,
'/doSomethingUseful/'; a no-no as per the *Whiteboard* pattern.
Another concern worth some thought is the /Subscription/ instance returned
from the same method which can become 'stale' at any time; the client can be
notified of this when /SomeService/ gets unbound but, how should
/SomeService/ handle the (multiple) subscription instances it could be
holding on to when it gets deactivated - cancel them? forcing the client
into a /subscription.isCancelled()/ logic.

I'm very interested to hear from you guys and thanks in advance...

class SomeServiceClient {

 @Reference
 private SomeService someService;

 private Subscription subscription;

 @Activate
 public void activate() {
   Parameters params = createParamStructure(config);
   // long living subscription?
   subscription = someService.subscribe(params, this::doSomethingUseful);
 }

 private void doSomethingUseful(MessageOfInterest msg) {
   // doing something interesting with msg
   // possibly called every second
 }

 @Deactivate
 public void deactivate() {
   subscription.cancel();
 }
}



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/OSGi-Reactive-Paradigm-tp5018956.html
Sent from the Apache Felix - Users mailing list archive at 
Nabble.com.

-
To unsubscribe, e-mail: 
users-unsubscr...@felix.apache.org
For additional commands, e-mail: 
users-h...@felix.apache.org

OSGi - Reactive Paradigm

[bokie]

An opportunity has come up to include OSGi in a new project I'm involved in.
I'd like to hear some opinions, consideration to take into account and
perhaps some experiences with focus on how the reactive paradigm should fit
in a very dynamic OSGi ecosystem where services can come and go at any time.

With the code below as an example, my concerns are primarily with the
subscribe method where we are essentially passing it a listener,
'/doSomethingUseful/'; a no-no as per the *Whiteboard* pattern.
Another concern worth some thought is the /Subscription/ instance returned
from the same method which can become 'stale' at any time; the client can be
notified of this when /SomeService/ gets unbound but, how should
/SomeService/ handle the (multiple) subscription instances it could be
holding on to when it gets deactivated - cancel them? forcing the client
into a /subscription.isCancelled()/ logic.

I'm very interested to hear from you guys and thanks in advance...

class SomeServiceClient {

  @Reference
  private SomeService someService;

  private Subscription subscription;
  
  @Activate
  public void activate() {
Parameters params = createParamStructure(config);
// long living subscription?
subscription = someService.subscribe(params, this::doSomethingUseful);
  }
  
  private void doSomethingUseful(MessageOfInterest msg) {
// doing something interesting with msg
// possibly called every second
  }
  
  @Deactivate
  public void deactivate() {
subscription.cancel();
  }
}



--
View this message in context: 
http://apache-felix.18485.x6.nabble.com/OSGi-Reactive-Paradigm-tp5018956.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org