Resources | developer.brewmp.com Resources | developer.brewmp.com

Developer

resources

Privileges

Privileges specify rights or restrictions for access to resources and objects. Brew MP uses privileges to protect the services and data associated with interfaces.

Privileges are generally used at the object level, indicating the ability to obtain an object. A caller must possess the required privileges to access a privileged class. For example, a privilege can denote the ability to create sockets, or the ability to obtain GPS position information. Both in-process classes and service classes can be privileged.

A privilege is represented by a 32-bit unique IDs (e.g. AEEPRIVID_XXX) that is specified in the CIF of the module. The kernel maintains the privileges list for each object in the system to ensure processes or applications can only access the objects to which they are given access.

Privilege IDs

A 32-bit unique ID, or set of IDs, is associated with each module. Each unique ID represents a privilege. These unique IDs are obtained from the BREW ClassID Generator on the http://developer.brewmp.com/tools/class-id-generator, which ensures that each ID is globally unique. Privilege IDs have a unique meaning across all modules, allowing the system to enforce the principle of least-privileged execution.

How privileges work in Brew MP

  • Each module is bound by its digital signature to a set of privileges. A digital signature indicates that the code has met certain standards and is authorized to run on the device. For more information on digital signatures, see Code Authorization on Brew MP through Digital Signing in http://developer.brewmp.com/resources on the Brew MP website.
  • Each applet runs in its own context and is granted a privilege set when it is started. If the applet uses any in-process classes, which run in the applet context, the in-process classes have the same privileges as the applet. If an in-process class requires specific privileges to access data or services, the calling applet must have those privileges. The in-process can also be declared to be privileged or protected (in the CIF), in which case, the caller must possess the ClassID of the in-process class as one of its privileges to access the class.
  • When an applet uses a service class, Brew MP will check its privilege and see if it has sufficient privilege required by the service class. Access to the service will be denied if the calling applet does not have the required privilege(s).

    After an applet is granted access to a service, the service can use IPrivSet to inspect the set of privileges passed from the caller to determine whether the caller has the appropriate privileges to perform the requested action (such as reading a file). For more information on IPrivSet, see IPrivSet and Example - using IPrivSet to verify caller privileges.

For more information on privileges, see the following:

Protecting application resources with privileges

When creating an application, the developer needs to determine whether the class provides access to a service or data that requires protection. Do not use a privilege if there is not sensitive data or a service that requires protection. Privileges are needed if there is something of value to a phisher or other attacker. Conceptually, privileges protect data and services, not APIs. For example, the address book is data that needs privilege protection because phishers (attackers after personal data) are interested in it. The network is a service that should be protected because it is a relatively scarce resource that costs money to use.

If the application has data that needs to be protected, but no services to protect, ACLs can be used instead of privileges. If the application also needs to control how the data is accessed, privileges for the classes or methods that access the data can be used. However, only remoted services can be privilege protected. If a class needs to be protected it must be turned into a remoted service, which can be protected with privileges. The caller must have the privilege to invoke the service.

In some case you can write code to protect an individual method offered by a service rather than the invocation of the service itself. Perhaps the service does many things and only one aspect of is sensitive.

In some cases privileges might not be associated with the service or a method, but rather a data item. For example a database could record the privilege required for each record in the record.