Issues with ECS / Docker, and items in /usr/lib64 (ppid not being obeyed)

[michaelsmoody]

We're leveraging fapolicy on ECS nodes, and we've attempted this on fapolicyd-1.0.4 through fapolicyd-1.1.3

Using Amazon Linux 2 running the 5.10 Linux Kernel (as it has all of the necessary plumbing), we find that ECS doesn't want to run with fapolicyd enabled.

(Also, iptables was broken until VERY recently, but I believe that was solved with an upstream fix to selinux policy, systemd, and all of it turned out to have been likely caused by CVE CVE-2022-1117 and RedHat BZ 2068171....oddly enough? But a full round of yum update allows iptables to start now without having to whitelist ld-2.26.so in various respects... or rip out parts of the rule for shared libraries....)

Back to ECS...

We're having to write rules that look roughly like this:

allow perm=open auid=4294967295 exe=/ : path=/usr/lib64/libpthread-2.26.so ftype=application/x-sharedlib trust=1
allow perm=open auid=4294967295 exe=/ : path=/usr/lib64/libseccomp.so.2.4.1 ftype=application/x-sharedlib trust=1
allow perm=open auid=4294967295 exe=/ : path=/usr/lib64/libc-2.26.so ftype=application/x-sharedlib trust=1

Unfortunately, ECS throws this:

rule=11 dec=deny_audit perm=open auid=-1 pid=11451 exe=/ : path=/usr/lib64/libseccomp.so.2.4.1 ftype=application/x-sharedlib trust=1

rule=9 dec=deny_audit perm=open auid=-1 pid=10851 exe=/ : path=/usr/lib64/libpthread-2.26.so ftype=application/x-sharedlib trust=1

rule=12 dec=deny_audit perm=open auid=-1 pid=13364 exe=/ : path=/usr/lib64/libc-2.26.so ftype=application/x-sharedlib trust=1

(the only reason the rules aren't all the same number is just because the need to create a different allow rule to get to the NEXT deny....)

Attempting to use a ppid=1 or ppid=2 even with perm=any or perm=open unfortunately fails. I've attempting many ways of getting it to work, and looking at the process tree, ECS is definitely opening it, as it is the kworker that is performing this, but no such luck. We've attempted full access to anything in /usr/lib64 to any ppid=1 or ppid=2, and various combinations, but no matter what, whether explicit or implicit rules fail.

I'm certainly open to suggestions at this point if it instead a failure of my understanding of the documentation, but I've formatted the rule in every conceivable way.

allow perm=any ppid=1 : path=/usr/lib64/ld-2.26.so ftype=application/x-sharedlib trust=1 As an example

When iptables was also failing (prior to a recent update), it too was unable to succeed with similar deny failures about the same, and various shared libraries, which we had to whitelist, one by one...

Thanks in advance!

[stevegrubb]

ppid=1 is init. That would be the wrong process. ppid=2 is kernel worker threads. This can be verified by ps -ef & cat /proc//status | grep Ppid. I would not expect exe=/ to ever work. It's not a valid executable. It may fail some length sanity checks somewhere in the code.

By any chance, are you getting any AVC's? We recently switched to mmap'ing the file to sha256sum it and selinux policy may need adjusting. Also, is fapolicyd.service unmodified? Do you have any third party security kernel modules that could also be doing things?