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.