Checking custom permissions when no policy is used

Although shipped systems should always use a security policy, the code still needs to account for what happens with permission checking when no policy is used. In most cases, checks for custom permissions are additional checks—they are made in addition to the usual read/write checks a resource manager performs on a request. The system assumes that additional checks protect operations that require additional permissions.

When no security policy is in use, permission checking is performed using the secpol_get_permission() parameters that specify a class and permission name. The secpol_get_permission() function indicates the permission to check with secpol_check_permission().

If you call secpol_check_permission() with a permission that was looked up with class and permission name strings, it looks to see if the following environment variables are set (for the server), in the following order:

1. SECPOL_class_permission_GID
2. SECPOL_class_GID
3. SECPOL_GID

where class and permission are the parameter values passed. If one is found, the process must have the group ID specified by the environment variable for the permission to be allowed. If none of the environment variables are defined, a check is made that the client is root. You can change this behavior by passing appropriate flags.

If you pass the SECPOL_PERM_STRICT flag to secpol_get_permission(), the function fails when no policy is in use or the policy does not contain the required class or permissions.