running fapolicyd in ubuntu gets slow until it freezes the system

[cduelo]

I have built fapolicyd for Ubuntu 20.04 with the debian definition found here.

I build the debian package in a lxd container. Host 22.04 and container 20.04. I am not sure if this could affect.

I think that fapolicyd is getting slow until it completely freezes and freezing the whole system.

I would like to debug to find the problem, can you give me hand or a recommendation?

I am running in a KVM an ubuntu 20.04 with the following kernel:

uname -a
Linux fapolicy 5.15.0-107-generic #117~20.04.1-Ubuntu SMP Tue Apr 30 10:35:57 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

I always run in fapolicyd --permissive --debug

All the logs are normal, there are no errors.

I run watch -n 60 fapolicyd-cli --chec-status to check if there is something with Inter-thread max queue depth but it is always in close to zero.

This is the configuration:

permissive = 1
nice_val = 14
q_size = 800
uid = fapolicyd
gid = fapolicyd
do_stat_report = 1
detailed_report = 1
db_max_size = 50
subj_cache_size = 1549
obj_cache_size = 8191
watch_fs = ext2,ext3,ext4,tmpfs,xfs,vfat,iso9660,btrfs
trust = file
integrity = none
syslog_format = rule,dec,perm,auid,pid,exe,:,path,ftype,trust
rpm_sha256_only = 0
allow_filesystem_mark = 0
report_interval = 30

My rules

allow perm=execute all : trust=1
allow perm=any all : ftype=text/x-shellscript
deny_syslog perm=execute all : all

I not sure if the rules are affecting since I always run in permissive mode.

Do you have any ideas, what I could be doing wrong ?

[stevegrubb]

The max queue depth issue was found last week and is fixed by commit 59e2f10. What that means is that it's only accurate when the program ends. If you are in permissive mode, fapolicyd should not cause the system to freeze since it's not depending on any access decision.

If you can run the code currently in git, that might be better for debugging. Just clone the repo, do the build, and run it where it is. You do not need to install it. Another idea might be to run it with valgrind or address sanitizer. Maybe the debian package code is leaking memory?