We've already covered the files user_macros.te and admin_macros.te. The two other files in the macros directory are core_macros.te and global_macros.te.
The core_macros.te file contains macros that are not changed very often, and it is recommended that you don't change them :) This is because core related policy should be the same if you want to share policy. Changing something in this file might render your policy incompatible with what everyone else is doing. Of course, if you don't care about anyone else, go ahead and change it. If you've changed your core_macros.te file, this may result in you having a system that works differently from everyone else, which may not be in your best interests.
Some of the macros contained in this file are macros for groupings of classes and permissions:
define(`dir_file_class_set', `{ dir file lnk_file sock_file fifo_file chr_file blk_file }')
This line defines the macro dir_file_class_set which contains the classes dir (for directories), file (for files), lnk_file (for symbolic links), sock_file (for Unix domain sockets), fifo_file (for named pipes), chr_file (for character block devices) and blk_file (for block devices).
define(`rw_file_perms', `{ ioctl read getattr lock write append }')
This line defines the macros rw_file_perms which contains the permissions ioctl (for ioctl's), read (read file), getattr (get attributes) and then lock, write and append.
The global_macros.te file contains macros that are system wide, meaning they are not tied to particular policy files. You can edit this file if you want to, but it probably won't happen often.
define(`can_setexec',`
allow $1 self:process setexec;
allow $1 proc_t:dir search;
allow $1 proc_t:{ file lnk_file } read;
allow $1 self:dir search;
allow $1 self:file { read write };
')
Defines the macro can_setexec. $1 is able to set the execute context, so it can set the context of a child process. $1 can search
/proc and can read files and symlinks in that directory.
The program subdirectory contains additional macros for programs that need per-user role policy. Programs such as ssh require a per-user role policy as the derived domains are based on the calling user domain. If you look at the file ssh_macros.te you'll see
define(`ssh_domain',`
# Derived domain based on the calling user domain and the program.
type $1_ssh_t, domain, privlog;
So if user_t was the calling user domain, the derived domain will be user_ssh_t. Likewise, if staff_t was the calling user domain, staff_ssh_t will be the derived domain. The line
domain_auto_trans($1_t, ssh_exec_t, $1_ssh_t)
allows the transition from the calling domain to the derived domain.
