Description of problem: This is kind of continuation of BZ #1903548. When fapolicyd is active with default rules, it's not possible for users to perform a basic "git init" command. This is due to hitting the following rule when git tries to copy a hook sample implemented using Perl: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- $ git init fatal: cannot copy '/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample' to '/home/rmetrich/FOO/.git/hooks/fsmonitor-watchman.sample': Operation not permitted $ echo $? 128 -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- Rule being hit: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- deny_audit perm=any all : ftype=%languages -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- fapolicyd log in --debug-deny mode: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- rule=12 dec=deny_audit perm=open auid=0 pid=11058 exe=/usr/bin/git : path=/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample ftype=text/x-perl -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- I think that everything that is shipped as a RPM package should be allowed (if we don't trust our own code, then there is a problem ...). Version-Release number of selected component (if applicable): fapolicyd-1.0-3.el8_3.4.x86_64 How reproducible: Always Steps to Reproduce: 1. Start fapolicyd 2. Create a directory as a user and try to "git init" $ mkdir FOO && cd FOO $ git init Actual results: fatal: cannot copy '/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample' to '/home/rmetrich/FOO/.git/hooks/fsmonitor-watchman.sample': Operation not permitted Expected results: Initialized empty Git repository in /home/rmetrich/FOO/.git/
I think this is closely related to the linked upstream issue.
Software development generally means playing with code that is not trusted. Anyone doing software development should probably add a developer supplemental group to their account and then a rule can be created so that developer accounts can run things in the home dir. This is documented in github README.md. allow perm=any gid=developer : ftype=%languages dir=/home
Hi Steve, This doesn't work, I added your proposed rule as first rule and still get the deny: $ id uid=1000(myuser) gid=1000(myuser) groups=1000(myuser),1001(developer) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 $ git init fatal: cannot copy '/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample' to '/home/myuser/.git/hooks/fsmonitor-watchman.sample': Operation not permitted This is because /usr/share/git-core/templates/hooks/fsmonitor-watchman.sample cannot be opened at all, as shown by strace: -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< -------- 6623 07:33:12.049381 openat(AT_FDCWD, "/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample", O_RDONLY) = -1 EPERM (Operation not permitted) <0.000623> -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
Fapolicyd needs very careful tweaking if it's used in a build server or developer's system. This is because by their very nature are creating software which sometimes involves running newly created programs which are certainly not in the trust database. Fapolicyd is better suited to a less volatile environment where applications that run are in the trust database. This can be solved by modifying the configuration. The rule in comment #2 works. The retest failure reported in comment #3 was not in /home. Regarding git files in /usr/share/git-core/templates, these files are language files that do not follow language specific naming conventions. $fapolicyd-cli --ftype /usr/share/git-core/templates/hooks/fsmonitor-watchman.sample text/x-perl This causes them to get missed during rpm installation and they do not windup in the trust database. $ fapolicyd-cli --dump | grep fsmonitor-watchman.sample $ There are two approaches, add them to the file trust db manually: $ fapolicyd-cli --file add /usr/share/git-core/templates The only drawback is the file trust db will need to be refreshed whenever git is updated. $ fapolicyd-cli --file update /usr/share/git-core/templates The second approach is to add another rule allowing developer gid to access /usr/share/git-core/templates. In almost any situation, problems like this can be worked around by configuration changes. There are troubleshooting steps that need to be done to find a solution. 1) run in debug mode and see what the objection is. Which rule number made the decision? 2) run faplicyd-cli --list to see what that rule number is. 3) Is there a rule above it that should have allowed access? If so, did the trust not match? Verify the file's mime type. 4) Is the file in the trust database? If not add it or a directory in the path that contains it. 5) If you need a big loophole for a kind of user, make rules for their access. Go the trust route first. Only add rules if the trust situation is volatile and unweildy.
Git can be enabled with a filter file. On 9.3/8.9: /etc/fapolicyd/fapolicyd-filter.conf can be set so git files won't be excluded from trust DB. On 9.2/8.8 it's /etc/fapolicyd/rpm-filter.conf.
I just added "+ git-core" there: [root@Axis fapolicyd]# cat fapolicyd-filter.conf # default filter file for fedora + / - usr/include/ - usr/share/ + git-core/ # Python byte code + *.py? # Python text files + *.py # Some apps have a private libexec + */libexec/* # Ruby + *.rb # Perl + *.pl # System tap + *.stp # Javascript + *.js # Java archive + *.jar # M4 + *.m4 # PHP + *.php # Perl Modules + *.pm # Lua + *.lua # Java + *.class # Typescript + *.ts # Typescript JSX + *.tsx # Lisp + *.el # Compiled Lisp + *.elc - usr/src/kernel*/ + */scripts/* + */tools/objtool/*