Endpoint Administration Guide for UNIX › Improving Performance › Using Global Access Check › GAC Restrictions

GAC Restrictions

GAC implementation has proved to be very efficient, especially in cases where there are hundreds of file accesses in a second, but it has the following restrictions:

• By default, GAC rules are not applicable for the root user (usually ADMIN). To make the rules applicable to root, set the following token in the [SEOS_syscall] section of the seos.ini file:

  GAC_root=1
  

  The default value of the token is 0. To restore the default, set the token to 0, or remove the token.

• You must not include a file rule that is protected conditionally (for example with day or time restrictions, program pathing, and so on) in the table. If you do specify such a file rule in the GAC.init file, the day or time restrictions and other restrictions no longer apply.
• A file rule that has audit(ALL) or audit(success) attributes must not be included in the GAC.init file. If such file rule is specified in the GAC.init file, audits of successful accesses are not recorded.
• The filtering process uses the real (current) UID (that is, the UID that is associated with the process at the time of execution). This provides a loophole to the CA Access Control tracking of the original UID (the one with which the user has originally logged in) and not the current UID. (CA Access Control implements tracking of UID usage to provide the security of more accountability.)

  Let us examine an example of how someone might try to take advantage of this loophole. User Tony is not authorized to access the file Accounts/tmp. So Tony surrogates (through /bin/su) to user Sandra, who is authorized to access Accounts/tmp. If Sandra has already accessed the Accounts/tmp file, the file appears in the do-not‑call‑me table with her UID. Tony, using Sandra's UID, is then permitted to access the file. This is because the kernel code does not maintain the history of UIDs.

  However, if Sandra has not previously accessed the file, the access permissions are checked in the regular manner using seosd, and Tony is denied access to the file. To close this loophole, the ADMIN user must protect the SURROGATE objects in the database. For this example, the ADMIN could add the following rule to the database:

  newres SURROGATE USER.Sandra default(N) owner(nobody)
  

  This command ensures that Tony cannot use the su command to gain Sandra's access privileges.

• The caching system does not have any impact if the accessor is root. The reason is that no access is granted to root without consulting the database.