6

My system has a very complex SELinux policy. Is there a tool which can explain why a particular access was granted? Often when I search for a particular rule using text search I don't find it because the rule has been created via macros or via attribute rules.

For example I know there is an equivalent rule in my system somewhere which allowed this:

allow app_a app_b:fifo_file write;

Text searching for that specific rule turns up nothing because of the heavy use of macros and type attribute associations.

satur9nine
  • 661

2 Answers2

2

Yes, you're looking for sesearch from the setools package.

For your specific example, you could use sesearch -A -s app_a -t app_b -c fifo_file -p write. The results will include not only explicit allow rules between the two types, but also rules resulting from attributes and conditional rules depending on a particular Boolean.

-A/--allow makes it search for allow rules, there are other options for dontaudits, transitions, and so on.

You don't have to specify all of the source/target types, class, and permission. For example, using sesearch -A -t app_b -c fifo_file will list all permissions that any source has to fifo_files of the app_b type.

By default, sesearch uses the currently active policy, but you can also specify a path to a policy that you want to search.

TooTea
  • 2,388
  • 11
  • 15
1

Not that I am aware of, no. Generally you "expand" macros and query rules associated with type attributes to find their meaning, the names of macros and attributes are usually pretty descriptive. You can also query the git-log to see if the git commit message has some more information.

There is a script that helps expand macros called "macro-expander", and there is the setools policy analysis suite that helps to find rules associated with attributes.

The rule in your example seems to be unnamed pipe usage. This is usually part of domain transition macros to allow for piping into the input stream of the target since this is pretty common for processing of stdin/stdout/stderr, for example: (app_b | app_a)

https://github.com/SELinuxProject/refpolicy/blob/master/policy/support/misc_patterns.spt#L58

So assuming app_b runs app_a with a domain transition, app_a is allowed to read/write the pipe inherited from app_b. So its about processing of stdin, stdout, stderr. E.g. the target of a domain transition is automatically allowed to use inherited pipes of the source of a domain transition.

But, yes, parsing of complex policy written by others can be a challenge. setools and scripts like macro expander make it a little less painful, and self-documenting policy with strict style rules also help. A lot of these things are common patterns.

dac.override
  • 11