In systems where security is important, applications should run with the fewest privileges possible. Doing this helps reduce the impact of possible compromises and can also help lower the privilege escalation attack surface of the device.
The more difficult it is for attackers to elevate an application's privileges, the better; forcing attackers to chain multiple attacks against various applications that each have minimal sets of permissions is ideal.
Currently, services and other system processes, such as those started at boot by the startup.sh script, aren't installed as a BAR and therefore aren't assigned user IDs (UIDs) and group IDs (GIDs) by the Launcher service. Such services and processes are expected to support a -U command-line option that specifies the user and group IDs to run as.
This option takes one of these forms:
For example, -U99:98 specifies that the process is to run as user ID 99 and group ID 98. An integration team can assign the appropriate permissions for each user and group.
After the process starts up and carries out any privileged functionality it requires, and possibly obtains capabilities to retain some privileged permissions, it's expected to lower its permission to those specified by the -U command-line option.
You should lower application privileges as soon as possible, in stages if necessary. For instance, a resource manager typically needs to register a name in the path space by calling resmgr_attach() ; in order to do this, it requires the PROCMGR_AID_PATHSPACE ability. The service should obtain this ability and immediately drop to the privileges provided by the -U command-line parameter. After registering the name in the path space, the process should drop the ability if it doesn't need to register any more names.