You identified an issue where you are unable to execute a certain binary any longer which ControlMinder was obviously preventing?
You know that a PROGRAM rule was defined for this binary, here /usr/bin/notes
This document describes how to determine that indeed ControlMinder is preventing the binary’s execution, what is the reason for this denial and how to overcome the issue.
First thing to do is to see if we have a 'D' (denial) by ControlMinder in the first place when accessing this resource. So, we use the seaudit utility and grep for the process being blocked:
# seaudit -a | grep /usr/bin/notes
25 Mar 2015 14:22:40 D PROGRAM x020397 Exec 250 2 /usr/bin/notes /usr/bin/ksh IP_ADDRESS_HERE (OS user) root
Next it is of interest why ControlMinder denied execution
# seaudit -t | grep 250
250 Executing an untrusted program
# selang -c "sr program /usr/bin/notes | grep Untrust"
Untrust : Yes
# selang -c "sr program /usr/bin/notes | grep Why"
Why : Mtime
Since we know the reason of the binary’s change we want to trust it again hence allow ControlMinder to execute it again. For this we use the seretrust utility which generates the selang commands required to retrust all programs and secure files defined in the ControlMinder database.
# ./seretrust -a
This will output the relevant selang command adding the trust flag onto the according policy.
In selang while connected to the seosdb submit the commands issued by the seretrust command, e.g
chres PROGRAM ("/usr/bin/notes") trust
For further details about the seretrust utility and a specific example how to use it please see:
Also see these other Documents on how to protect programs: