Version 1.3.0-rcN release testing/observations/notes.

[tparchambault]

Starting the V1.3.0-rc1 testing with the rpms available under GitHub releases page.

[tparchambault]

Testing V1.3.0-rc1-1 over FC39, focusing on the following runtime updates:

• Add validate config button by @jw3 in Add validate config button #979
• Reload rules while profiling by @jw3 in Reload rules while profiling #990
• Add lang for config by @jw3 in Add lang for config #991

Many of this release's other changes are related to CI, builds, and dependencies. General use should validate most of these changes.

[tparchambault]

During V1.3 testing, I noticed that some incorrect string values were passing the config validation test. Verified w/ @jw3 and in the src that only the first round of syslog and watch_fs validation has been realized: Pls see #997 (comment)

[tparchambault]

Continuing w/FC39:

1. General testing

• Installation went fine. No observed issues.
• FC39 update occurred post install, resulting in the known inconsistencies between the rpm and fapd Trust databases. Could we alert the user about the need to have fapd rebuild its dbase (via timestamps?) if using the fapolicy-analyzer with an inactive daemon? Yep, another enhancement request.

2. Config Editor testing.

• Config Differences pop-up is a nice feature. Suggest high-lighting specific deltas, if that's not already on the enhancement list.

3. Profiler testing

• Copied the trusted /usr/bin/ls to the untrusted /tmp/my-ls. The post profiling analysis view doesn't provide an obvious (to me) indication that its execution would be denied with the current rule default rule set, i.e. /tmp/my-ls has the green background high-lighting, although it is untrusted (or should be.)

[jw3]

Copied the trusted /usr/bin/ls to the untrusted /tmp/my-ls. The post profiling analysis view doesn't provide an obvious (to me) indication that its execution would be denied with the current rule default rule set, i.e. /tmp/my-ls has the green background high-lighting, although it is untrusted (or should be.)

Was it denied? Post the fapolicyd log output.

[tparchambault]

It was denied when running fapolicyd –debug-deny from the CL. It ran within the profiler, but that’s OK isn’t it, because the profiler run is ‘permissive’ iirc. Maybe we want ‘permissive’ to be optional? In any event, the analysis view showed my the files that /tmp/my-ls accessed. I’ll do some image captures tomorrow AM. I was trying to test the dynamic rules reload but didn’t get to the point of modifying them yet. I thought something should make obvious that /tmp/my-ls is untrusted. And then I saw the current rules should deny its execution; That’s when I ran fapd from the CL w/--debug-deny which did deny /tmp/my-ls’s execution.

[jw3]

I thought something should make obvious that /tmp/my-ls is untrusted.

The analyzer view should behave as it always has, where if denied it should mark red and indicate the trust status.

See the user guide

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

If it appears broken please share the logs from the profiler run.

[tparchambault]

Logs look good. It's a UX thing IMHO. We don't clearly emphasize subject execution denials in the fapa. I'll post images below.
UntrustedDenyProfilerLogs.zip

[tparchambault]

Two CL sessions on an FC39 TestBed. The smaller pane copied /usr/bin/ls to /tmp/my-ls; Executed /tmp/my-ls from the cmdline w/o fapolicyd executing, w/fapolicyd executing via systemctl, and lastly w/fapolicyd executing directly from the cmdline with the --debug-deny option. The larger pane was this last my-ls execution scenario using $ fapolicyd --debug-deny showing the daemon's CL output.

[jw3]

I'm interested in seeing

1. The profiler configuration
2. The profiler log output at the my-ls decision
3. The analyzer view of the logs

I want to see (3) related to your above comment

• "I thought something should make obvious that /tmp/my-ls is untrusted."

edit: I see what we are comparing, the above is what I want to see. Post the images and we can chat on the phone if needed.

[tparchambault]

The equivalent operation from within the fapolicy-analyzer doesn't emphasize that an execution denial has/or would have occurred. This is not a bug wrt V1.3 but as I wanted to test certain rules wrt Trusted executables, and was trying to determine how that reloaded rule would be presented within the fapa.

The profiling tool with input and scrolled results:

Navigating to the analysis of that execution run. Note the green high-lighting with allowed access of the /tmp/my-ls Subject:

Ok then... How about from the perspective of Python? While /tmp/my-ls is noted as untrusted, access is still granted according to the Object listing, which is probably OK.

So, this is a lot of words and pictures; maybe this can be addressed by addressing the Subjects background high-lighting when they are the subject of a denial?

I'll play around with the analysis view some more. Maybe flipping the columns will give me the obvious UX I'm looking for.

[jw3]

The log says rule 14 allowed the execution, and the trust is showing that it is Untrusted

[tparchambault]

Another image of the above analysis view with no object selected:

[jw3]

Thanks, Ill add an issue for this and link it back

[tparchambault]

@jw3 Thx for the help.

[tparchambault]

Over FC39, when attempting to modify and deploy the rules to deny access to a back up copy of .bashrc , the deployment failed. Tailing the audit.log showed that SELinux was denying the removal and/or write of fapolicyd.pid

type=AVC msg=audit(1706912901.383:345): avc:  denied  { unlink } for  pid=3707 comm="fapolicyd" name="fapolicyd.pid" dev="tmpfs" ino=1736 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=0
type=AVC msg=audit(1706912901.386:346): avc:  denied  { write } for  pid=3709 comm="fapolicyd" name="fapolicyd.pid" dev="tmpfs" ino=1736 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=0
type=AVC msg=audit(1706912948.068:347): avc:  denied  { unlink } for  pid=3709 comm="fapolicyd" name="fapolicyd.pid" dev="tmpfs" ino=1736 scontext=system_u:system_r:fapolicyd_t:s0 tcontext=unconfined_u:object_r:var_run_t:s0 tclass=file permissive=0

This doesn't currently make too much sense to me, given that earlier profiler runs today ran fine. Maybe the deployment execution environment's pid file location warrants the SELinux denial, but not the Profiler's pid file location. Or user error, with toggling back and forth between Profiler and Rule editor views. Will investigate further, but there is the implication that we may need to ship and/or update an SELinux policy config file. I don't know how we currently address SELinux policy from the fapolicy-analyzer perspective.

[jw3]

I don't know how we currently address SELinux policy from the fapolicy-analyzer perspective.

Yes this needs defined and documented, added #1000

[jw3]

I dont see any issues at this point that cant be addressed next development cycle. Going to tag a release.

[tparchambault]

Testing over RHEL9. Had an issue w/installation of the el9 rpm:

[toma@localhost Development]$ sudo dnf install ./fapolicy-analyzer-1.3.0.rc1-1.el9.x86_64.rpm 
[sudo] password for toma: 
Updating Subscription Management repositories.
Last metadata expiration check: 2:26:41 ago on Wed 07 Feb 2024 11:10:09 AM EST.
Error: 
 Problem: conflicting requests
  - nothing provides gnome-icon-theme needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
  - nothing provides gtksourceview3 needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
  - nothing provides python3-configargparse needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
  - nothing provides python3-events needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
  - nothing provides python3-importlib-metadata needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
  - nothing provides python3-more-itertools needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
  - nothing provides python3-rx needed by fapolicy-analyzer-1.3.0~rc1-1.el9.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[toma@localhost Development]$

Attempted with both --nobest and --skip-broken w/o success.

[tparchambault]

Come to think of it, probably should add epel repo... That was the issue.

On RHEL9, to add the EPEL repo:

$ sudo subscription-manager repos --enable codeready-builder-for-rhel-9-x86_64-rpms
$ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm

[tparchambault]

On RHEL9, observed no new issues.