The domain_trans macro expands to access vector rules that grant a parent domain the ability to transition to a child domain via a program type. In addition to defining the minimal set of access vector rules required to authorize the domain transition, this macro defines several rules that are not strictly required but are usually desired. For example, the macro grants the parent domain permissions to reap the child domain when it exits. It also grants the child domain permissions to inherit and use open file descriptions from the parent domain. It might be useful to add a minimal domain transition macro that only contains the rules required to authorize the transition. The domain_auto_trans macro adds a type transition rule to the domain_trans macro so that the domain transition occurs automatically when the program type is executed by the parent domain.
The file_type_trans and file_type_auto_trans macros provide similar functionality for transitioning to a new file type when a file is created. The first macro expands to access vector rules that grant a domain the ability to create a file type in a directory type. This macro also defines more than the minimal set of access vector rules. For example, it also grants the domain the ability to remove names from the directory type and to unlink the file type. The macro also defines access vector rules to allow creation of any file class except for device special files. It might be useful to add a minimal variant of this macro that only contains the rules required to authorize the file creation and that requires the desired file classes to be explicitly specified. The file_type_auto_trans macro adds a type transition rule to this macro so that the file type transition occurs automatically when the domain creates a file in the directory type.
The uses_shlib macro expands to access vector rules that grant a domain the ability to execute the system dynamic loaders and to execute code from the system shared libraries. The can_exec macro grants a domain the ability to execute a program type without transitioning into a new domain. The can_exec_any macro grants a domain the ability to execute any system program.
The can_network macro expands to access vector rules that grant a domain the ability to perform unrestricted network communication via UDP or TCP sockets. This macro grants the domain permissions to the default message types for each network interface so that the domain can communicate with systems that do not provide message labeling. When message labeling is provided, separate access vector rules must be defined for the pair of domains that are communicating. The can_tcp_connect and can_udp_send macros expand to access vector rules that authorize specific pairs of domains to communicate. Since Flask does not yet provide message labeling across the network, these macros are only necessary for communication across the loopback interface.
For UNIX domain IPC, the can_unix_connect and can_unix_send macros expand to access vector rules that authorize specific pairs of domains to communicate. These macros do not authorize the transfer of open file descriptions between domains, so additional rules must be defined in the configuration if that is desired.
The can_sysctl macro expands to access vector rules that grant a domain the ability to modify any sysctl parameters. It might be useful to separate permissions for the modprobe path from the other sysctl parameters, since this path is especially security-critical. The can_create_pty macro expands to a set of rules that allow a user or administrator domain to create and access pseudo terminals with a corresponding derived type. The can_create_other_pty macro expands to a set of rules that allow a domain to create and access pseudo terminals on behalf of another domain, as in the case of gnome-pty-helper.