Spurious dec=deny_syslog due to "deny_syslog perm=any pattern=ld_so : all" rule

[pabchin]

Hello,

I have an embedded system where applications sometimes issue "system(some shell command)" or "system(some shell script)".

Occasionally, I see entries like this on the /var/log/messages

fapolicyd[1584]: rule=3 dec=deny_syslog perm=execute pid=6753 exe=/bin/busybox : path=/lib/ld-2.32.so ftype=application/x-sharedlib trust=1

OR

fapolicyd[1641]: rule=3 dec=deny_syslog perm=execute pid=31533 exe=/usr/local/bin/some_app : path=/lib/ld-2.32.so ftype=application/x-sharedlib trust=1

The commands executed (busybox or some_app) should not be denied. If this were an issue with rule 3, I would expect it to always happen.

I'm going to disable rule 3 and see if this still happens. But since it is intermittent and the first 'deny' rule is rule 3, I'm concerned it will just then hit rule 4.

Does any of the parameters in fapolicyd.conf need to be changed to avoid this?

Here are my rules list:

fapolicyd-cli -l

1. allow perm=any uid=0 : dir=/var/tmp/
2. allow perm=any uid=0 trust=1 : all
3. deny_syslog perm=any pattern=ld_so : all
4. deny_syslog perm=any all : ftype=application/x-bad-elf
5. allow perm=open all : ftype=application/x-sharedlib trust=1
6. deny_syslog perm=open all : ftype=application/x-sharedlib
7. allow perm=execute all : ftype=application/x-executable trust=1
8. deny_syslog perm=execute all : ftype=application/x-executable
9. allow perm=execute all : path=/lib/ld-linux.so.3 trust=1
10. allow perm=execute all : path=/lib/ld-2.32.so trust=1
11. allow perm=any all : ftype=text/x-python trust=1
12. allow perm=open all : ftype=application/x-bytecode.python trust=1
13. deny_syslog perm=any all : ftype=text/x-python
14. deny_syslog perm=any all : ftype=application/x-bytecode.python
15. allow perm=any all : ftype=text/x-shellscript
16. allow perm=any all : ftype=text/x-perl trust=1
17. deny_syslog perm=any all : ftype=text/x-perl
18. allow perm=any all : ftype=application/x-bytecode.ocaml trust=1
19. deny_syslog perm=any all : ftype=application/x-bytecode.ocaml
20. allow perm=any all : ftype=text/x-php trust=1
21. deny_syslog perm=any all : ftype=text/x-php
22. allow perm=any all : ftype=text/x-lua
23. allow perm=any all : ftype=application/octet-stream
24. deny_syslog perm=execute trust=0 : trust=0
25. allow perm=open all : all

Here are current fapolicyd.conf:

permissive = 0
nice_val = 14
q_size = 800
uid = root
gid = root
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 = size
syslog_format = rule,dec,perm,pid,exe,:,path,ftype,trust
allow_filesystem_mark = 0
~

Thanks

[stevegrubb]

There are some program that, for whatever reason, start up wrong. You can use strace to reproduce the problem. If it starts up in a way that looks like the linker ran first, you will trigger this pattern. Sometimes this is associated with containers. Fapolicyd has limited visibility to containers because the fanotify API is not namespace aware.

So, the first question is, are containers running on the system? Are there any sandboxing frameworks using namespaces? Is there anything in common such as they are services started by systemd using it's security options (namespaces)?