Thanks for the response! I used the “[DRAFT] DISA STIG for Red Hat Enterprise Linux 9” profile, which is one of the stricter ones and I feel like it’s probably what’s relevant here. I did check audit.log and though it sees me try to execute perl scripts, it doesn’t seem to mind. However the security profile is more than just SELinux so there could be other elements of it. I’m going to try to look at that today.
One note is that the fsmonitor-watchman.sample script isn’t really the issue, it’s just apparently the first perl script I tried to access as a user on the system, by initializing a git repo. Generally, perl works fine on the system, even as a user:
elliott-a@corp:~$ echo 'print("Hello\n");' > test.pl
elliott-a@corp:~$ cat test.pl
print("Hello\n");
elliott-a@corp:~$ perl test.pl
Hello
… no problem. BUT:
elliott-a@corp:~$ (echo '#!/usr/bin/perl' ; echo 'print("Hello\n");') > test2.pl
elliott-a@corp:~$ cat test2.pl
cat: test2.pl: Operation not permitted
elliott-a@corp:~$ perl test2.pl
Can't open perl script "test2.pl": Operation not permitted
elliott-a@corp:~$ chmod +x test2.pl
elliott-a@corp:~$ ./test2.pl
-bash: ./test2.pl: Operation not permitted
elliott-a@corp:~$ cp test2.pl test3.pl
cp: cannot open 'test2.pl' for reading: Operation not permitted
elliott-a@corp:~$ rm test2.pl
elliott-a@corp:~$
So basically, having the shebang in the file (specifically perl - if it’s /usr/bin/bash, or /bin/sh, there’s no problem) prevents non-root users from reading the file. I poked at /etc/fapolicyd/rules.d a bit this morning and there are several rules that could be relevant, but none of seem to do what I’m seeing. E.g. there’s a 70-trusted-lang.rules file:
# Allow any program to open trusted language files
allow perm=open all : ftype=%languages trust=1
deny_audit perm=any all : ftype=%languages
… looks good to me? A few others like that. text/x-perl is a member of %languages.
I might try to set up a test system with a different security profile and see if the behavior changes. I’ve always used the DISA STIG profiles in the past, but they’re probably overkill for my actual use case. I’m probably going to poke more at fapolicy first, because I’d rather not go through re-installing if I don’t have to!
Thanks