This application consists of several GUI tools that support configuration and management of fapolicyd.
System trust is sourced from the RPM database on the host machine. The file locations are checked for size and sha256 hash to check for trust status as fapolicyd would. The GUI highlights the untrusted files in red while trusted are in green.
The intent here is to indicate in the GUI what the status of the file on disk is vs what fapolicyd has in the trust database. The trust database for system trust was derived from the rpm db, so a mismatch here indicates that the file on disk has changed from the originally installed file from the source rpm.
After adding trust entries the deployment options on the toolbar become active. See the Deployment section for more details.
Known issue: large RPM databases can take some time to load on single core machines. The system trust code does utilize additional cores so there will be a linear drop in loading time as more cores are available.
From this view you are able to resolve trust issues by adding files with discrepancies to the ancillary trust.
In addition to the RPM database, fapolicyd can source trust from a text file or collection of text files. In the GUI we call this trust Ancillary trust.
From this view you are able to add additional files or directories of files that will add to system trust when the files are not know, or override it if the file was already in the rpm db.
A mismatch highlighted here indicates that the file that was originally trusted has changed in some way.
Ancillary trust currently only supports the single file configuration. Near term improvements are planned to add support for the trust.d backend.
The GUI contains a text based rule editor that provides text highlighting and rules.d flattening to improve the rule editing experience.
The tree view of rules bridges some gaps in rendering of rules within the text editor. The ability to provide the flattened rule id and perform mouse operations on specific rules is currently limited to this view.
This view is currently read-only.
Within the rules.d directory there is a structure of one or more files that each may contain multiple rules. Determining the overall order of rules, as fapolicyd will interpret them, while editing can be tedious within the limited context of a single file. To ease this, the editor implements a flattening approach that displays all .d files within a single editor view. Transient delimiter annotations are inserted into the text view that identify file breaks. These annotations are editable which enables the user to rename, split, and merge file content by changing annotation content and location.
The file delimeters in the editor are referred to as file markers. These annotate the content of the editor to inform it where to break files when writing to disk.
File markers consist of the file name wrapped in square braces
[01-my.rules]
File markers are inserted automatically when loading rules.d. While editing, markers may be added or removed to split or merge rules into the corresponding rules files.
A rule set that contains three rules, originally sourced from a single file
[single-file.rules]
r1
r2
r3
Can be split into multiple rule files
[00-my-rules.rules]
r1
[01-my-rules.rules]
r2
[02-my-rules.rules]
r3
An then rules can merge into a single file by removing a marker
[00-my-rules.rules]
r1
[01-my-rules.rules]
r2
r3
A root marker is required, if not specified it will be inserted by the application using a default file name.
The profile execution is configured similarly to a launch profile in an IDE. Provide the target, args, working directory, and environment variables. Additionally we support the ability to run as a different user.
Future: Allow specification of gid(s) for the target execution, #664.
Known issue: there is no feedback to indicate the status of the running application during profiling. This will be addressed in the future by displaying the log output of the target application.
The analyzer can be accessed in two ways
The analyzer tool displays a three column faceted view that allows for graphical browsing of a fapolicyd log. The three column configuration represents data from a log entry per line, with the columns representing the user/group, subject, object.
The first two columns are reversible, allowing the user to use a starting perspective of either user/group or subject. The double arrow button within the first column header flips the perspective.
Each column contains a search field to perform filtering of entries. There are also right click options available for entries that provide trust reconciliation.
Entrypoint to the analyzer using the Tool > Analyze from Debug log menu item will allow the user to pick a fapolicyd debug log that was generated by using the --debug option on the daemon.
Entrypoint to the analyzer Using the Tool > Analyze from Syslog menu item will load the systems current syslog journal into the analyzer.
The required format for syslog entries must be added to the fapolicyd configuration.
syslog_format = rule,dec,perm,uid,gid,pid,exe,:,path,ftype,trust
Future: Analyzing kernel audit log entries will be added to a future release, tracked in issue #294
When the analyzer shows that a file access was denied due to trust issue, the user can use a right click operation to reconcile the trust issue by updating the trust database with the content that matches the on-disk file.
Deployment involves applying the current state held within the GUI to disk and having fapolicyd apply it to its state.
To accomplish this we do the following
After deployment is completed the user will be presented with a dialog asking if they want to keep the applied settings. There is a 30 second count down during which time you may test the system for functionality. If the dialog does not confirm that the changes should be kept in place the changes made to the hist will rollback to the previous state.
This is intended to be a fail safe in the case where a misconfiguration disables interaction with the host.
Because fapolicyd has the ability to reject any disk accesses we must be very careful when considering the resiliency of control the application provides. If we were to rely on controlling the fapolicyd service using the systemctl utility there is a chance that deploying a stringent rule such as deny perm=any all : all we could lose the ability to control the daemon.
To ensure resiliency we control fapolicyd using DBUS messages to signal system operations. This ensures we can start / stop the fapolicyd service even given stringent rules. This is used for both deployments and manual control (via the System menu), and gives the application resiliency that is hard to accomplish using existing command line tools.