Protected URIs in DMT events

[bjhargrave]

Original bug ID: BZ#284 From: Gabor Pecsy <gabor.pecsy@nokia.com> Reported version: R4

[bjhargrave]

Comment author: Gabor Pecsy <gabor.pecsy@nokia.com>

Last year we had a discussion about a possible security hole when using Event Admin to dispatch DMT Events. According to operators, sometimes the structure of the tree itself can contain sensitive information, so URIs shouldn't be exposed to unauthorized components. On the other hand, we considered the ability to filter incoming events based on URIs an important feature.

During the discussion we came up with an idea of creating a ProtectedUri class - similar to GuardedObject - which would encapsulate URIs:

public final class ProtectedUri implements Comparable {

// This constructor is meant to be used by DMT Admin when creating // an event. public ProtectedUri(String uri, DmtPermission guard) {..}

// This constructur is used by Filter implementation when evaluating // expressions containing ProtectedURIs public ProtectedUri(String uri) {..}

// to retrieve the protected URI public String getUri() throws SecurityException {...} ... }

URI attributes of DMTEvents would have to be changed to ProtectedURIs. Implementing Comparable interface ensures that they could be reasonably used in filters, however the actual URI they contain wouldn't be exposed without the proper permission.

This class could be added to the info.dmtree.security package as it would be OSGi specific (used with Evet Admin events only). And its usage should be explained in the spec.

[bjhargrave]

Comment author: Gabor Pecsy <gabor.pecsy@nokia.com>

During the implementation we realized that the proposed solution doesn't really serve the original use case. The assumption is that the primary way of using filters would be using it to filter events concerning a certain subtree, therefore, what we would need is pattern matching on the URIs (e.g. uri=./foo/*). Unfortunately, this cannot be implemented using the Comparable interface without breaking its contract, and the current Filter implementation prevents this too.

So this issue is now redirected as a feature wish for R5 to CPEG, because we think that either Filter or Event Admin could solve this problem the best. For the time being, we put a note into the specification pointing out that TopicPermission should be granted to trusted application only, because currently we have no means to further limit which events are delivered to the listeners.

Please note that the original goal was to ensure that only authorized listeners (which have GET permission to the corresponding node) will receive the DMT change events, while preserving the ability to filter based on the URIs.

[bjhargrave]

Comment author: @pkriens

Added comment to the event section in the spec

[bjhargrave]

Comment author: @bjhargrave

Peter, can you add some more detail as to what it required here?

[bjhargrave]

Comment author: @bjhargrave

CPEG call: We decided to close this bug. If the requirement resurfaces with a broader set of use cases, we can reconsider.