Another analytical investigation that can be carried out on SELinux policies is information flow analysis. Unlike domain transitions, which look at how one domain can gain a certain set of permissions through transitions to another domain, information flow analysis looks at how a domain could leak (purposefully or not) information to another domain.
Information flow analysis is performed by looking at all operations that occur between two types. A source type can be read by a domain, which subsequently can write information to another type that can then be accessed by another domain. While this can still be analyzed in a step-wise fashion, it quickly becomes very challenging because we cannot limit ourselves to the read and write operations.
Information can be leaked through filenames, file descriptors, and more. Information flow analysis must take all these methods into account.
Using apol for information flow analysis
- The Minimum permission weight option allows users to only look at permissions or actions that have a particular weight. Each action is given a weight in the tool, from a low priority (such as the
lockoperation, which has weight
1) to a high priority one (such as the
writeoperation, which has weight
10). The purpose of these weights is to define which actions are plausible for information flow and which ones are much harder (but not impossible) to use for deliberate information exchange.
- With Excluded Permissions, we can selectively enable or disable certain permissions from the analysis.
The other options are similar to those in domain transition analysis.
The most important area for information flow analysis is the permission map, which we can fine-tune partially while enabling or disabling permissions in the analysis. However, we might not be happy with the weights that the current permission map uses.
Within this editor, we can fine-tune the weights of the permissions to our liking, as well as the directionality of the action:
None(no information flow)
Write(information flows to the resource)
Read(information is retrieved from the resource)
Both(information can both flow to and from the resource)
Using seinfoflow for information flow analysis
sedta application for domain transition analysis, there is also a command-line application that offers information flow analysis capabilities similar to
apol, that is,
seinfoflow. Every invocation of the
seinfoflow command requires the permission map to be passed on for its analysis. If you don’t have a permission map created and saved yourself, you can use the default one available at
Let’s analyze the information flow possibilities between the
guest_t domains, using the default permission map, and only considering the permissions of weight
$ seinfoflow -S -m /var/lib/sepolgen/perm_map \ -s staff_t -t guest_t -w 10
The more elaborate a permission map is, the more time it takes for the analysis to complete.
Using sepolicy communicate for simple information flow analysis
$ sepolicy communicate -s postgresql_t -t staff_t krb5_host_rcache_t cluster_conf_t security_t postgresql_t postgresql_tmp_t hugetlbfs_t