Troubleshooting and frequently asked questions

Troubleshooting

In general, when anything goes wrong, review the /dev/secpolgenerate/errors file.

secpolgenerate generates new subranges each time it's run
In some cases, especially with abilities that are subranged by virtual address, each time you run a system, secpolgenerate generates new rules that define new subranges for the abilities. To avoid this problem, you can remove the subranges for the affected abilities from the policy entirely and grant the ability in an unrestricted manner.
System failures that secpolgenerate doesn't detect
There are ways in which a system can fail that are invisible to secpolgenerate and thus won’t show up in its errors file. For example, if permissions are wrong on files or devices, a resource manager that runs successfully as root might fail when run as non-root. One possible solution to this problem is to identify the paths that it fails to open and grant the resource manager access to them by adding ACLs.

Frequently asked questions

If I boot a system using a newly generated policy, why are some rules unused?

Because the rules generated by secpolgenerate represent all the capabilities needed, if you run the system with the policy it generates, you should see no unused rules. Why isn't this always the case?

There shouldn't be many unused rules, but actions used during rule generation, such as preloading libsecpol-preload.so.1, can result in channel connections that would otherwise not occur.

Why are errors reported when nothing fails?

In some cases, secpolgenerate reports errors in /dev/secpolgenerate/errors that don't correspond to any failure on the system. These are an artifact of how procnto uses the setuid, setgid, prot_exec, and priority abilities. Some of these might be partially resolved by secpolgenerate, others might require procnto changes.

There shouldn't be many unused rules, but actions used during rule generation, such as preloading libsecpol-preload.so.1, can result in channel connections that would otherwise not occur.

  • setuid: A process can change its effective user ID to its real user ID, saved set user ID, or any user ID granted by the setuid ability. However, if the change is made using the setuid() function, a check is made for the setuid ability even if the call will succeed without it. This behavior can lead to erroneous error reports and possibly the inclusion of a rule to allow setuid during rule generation. As of QNX Neutrino 7.0.1, this no longer occurs if setreuid() is used instead of setuid(). It's not possible to fix setuid() as the behavior is required to allow for proper POSIX behavior.
  • setgid: The setgid ability has an issue that is similar to setuid.
  • prot_exec: A process that lacks the prot_exec ability shows a failed ability check if it creates another thread. However, the failed check is harmless.