Version 1.1.0 review

[jw3]

Final review of v1.1

[tparchambault]

Over RHEL 9.2, the following was entered on the update page:

Cursory testing to check basic functionality over RHEL9,2 using the rpm downloaded from the github project's releases.

• Installation w/EPEL repo enabled: No issues observed. I missed the required fapolicyd.conf output format mod again, i.e. s/auid/uid,gid/. I believe that we already have a ticket to provide notification to the user that the config needs to be modified.
• Profiler exercised with untrusted utilities residing in $HOME and /tmp/, with a specified env var: PATH=$PATH:$HOME:., w/a non-root user, in the working dir: /tmp/ No issues observed.
• Switching to the Analysis tool directly from the Profiler tool's execution run performed as expected.

Two UI thoughts wrt the Analysis tool view, (and this may already have been discussed in the earliest wireframing phase):

• Convert ST / AT / U to the single word representation, System or Ancillary or Untrusted. The field looks like it's wide enough to hold the whole word.
• Ditto the Access field.
• Colors can remain the same.
• Maybe less processing would be required if there's a rendering step to add the bold and color emphasis to a substring with that widget, but that's not my primary rationale. The single word provides full info w/o translation of the acronyms. If it's a project to do the mod, then it's OK if things remain the same. Just wanted the team's thoughts.

[tparchambault]

Wrt testing over the FC39/rawhide out-of-the-box iso, I have not been seeing any writes to /var/log/audit/audit.log when fapolicyd is denying an operation. All deny rules are deny_audit.
Unfortunately, libaudit.so doesn't appear to be linked into the fapolicyd binary:

[toma@fedora ~]$ sudo ldd /usr/sbin/fapolicyd | grep audit
[toma@fedora ~]$

fapolicyd was installed via the default rawhide repo using dnf install fapolicyd; So unliess there's some late binding cleverness occurring via dlopen, it might be the FC39 fapolicyd variant will still only output to syslog.

Edited rules and deployed w/o any observed issues. Changed deny_audit to deny_syslog. Denied operation of executing an untrusted binary now results in a real-time log entry visible w/journalctl -f

Other than the lack of connectivity to a log to analyze, fapolicy-analyzer works as expected so far, wrt installation and rule modification and deployment.

[jw3]

@tparchambault it is most likely your auditd configuration, share that and ill take a look.

fapolicyd was installed via the default rawhide repo using dnf install fapolicyd; So unliess there's some late binding cleverness occurring via dlopen, it might be the FC39 fapolicyd variant will still only output to syslog.

The audit support has been around for quite a while, and is on all platforms. The recent change that has limited support is only for the inclusion of the rule id in the audit metadata.

fc39 has worked out of the box in my testing. It is possible to compile fapolicyd without audit, but the default distribution does include it.

[tparchambault]

[toma@fedora ~]$ sudo more /etc/audit/audit.rules
## This file is automatically generated from /etc/audit/rules.d
-D


-a task,never

[toma@fedora ~]$ 

How about this?

[jw3]

Yep, thats the problem, look here

https://github.com/ctc-oss/fapolicy-analyzer/wiki/User-Guide#auditd-configuration

[tparchambault]

Thank you sir. I had a cached copy of the User Guide so missed this key info. Appreciate the help.

[jw3]

There was a typo in those instructions, so refresh that wiki page. It had it cat'ing the dir rather than the compiled rules file.

Otherwise I think those should be good. See what you get with that, post your rules again if it doesnt work.

[jw3]

cp /usr/share/audit/sample-rules/43-module-load.rules /etc/audit/rules.d/audit.rules

User guide should be correct as-is now.

[tparchambault]

So unliess there's some late binding cleverness occurring via dlopen, it might be the FC39 fapolicyd variant will still only output to syslog.

I take it back. Could and should be statically linked.

[tparchambault]

Recreated a new FC39/rawhide guest because I'm currently away from the original system.
This iteration worked as expected out-of-the-box wrt intallation, trust, and audit.log analysis.

A comment about the audit log analysis (although I don't think this observation is specific to the analysis source): The untrusted executable I created via $ cp /usr/bin/ls ~/my-ls is displayed with the text No such file or directory. Since we know the file exists is this optimal phrasing to describe this situation? If this is the OS's perror string discription associated w/stat then we can live with it.

[tparchambault]

And the original execution that generated the audit entry:

[tparchambault]

Profiler tested with the same ~/my-ls untrusted executable using the $PATH and $HOME variables. No observed issues.
Daemon control was exercised w/o any observed issues.

Something to consider IMO. I think a relative time-sorting option in each analysis sub-pane might be beneficial wrt UX. I don't think we should give the FA event time a field because we don't have the UI area but I think it would help the user organize the pane contents with an idea of the relationship between the events.
OTOH, if the FA event timestamps are not readily available, then as always, nevermind