Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-622

fapolicyd still allows execution of a program after "untrusting" it

    • fapolicyd-1.3.2-100.el9
    • Normal
    • sst_security_special_projects
    • 20
    • False
    • Hide

      None

      Show
      None
    • Yes
    • Bug Fix
    • Hide
      .`fapolicyd` service no longer runs programs that are removed from the trusted database

      Previously, the `fapolicyd` service incorrectly handled a program as trusted even after it was removed from the trusted database. As a result, entering the `fapolicyd-cli --update` command had no effect, and the program could be executed even after being removed. With this update, the `fapolicyd-cli --update` command correctly updates the trusted programs database, and removed programs can no longer be executed.
      Show
      .`fapolicyd` service no longer runs programs that are removed from the trusted database Previously, the `fapolicyd` service incorrectly handled a program as trusted even after it was removed from the trusted database. As a result, entering the `fapolicyd-cli --update` command had no effect, and the program could be executed even after being removed. With this update, the `fapolicyd-cli --update` command correctly updates the trusted programs database, and removed programs can no longer be executed.
    • Done

      +++ This bug was initially created as a clone of Bug #2181472 +++

      Description of problem:

      Removing a program from trust database, then reloading fapolicyd, has no effect. The program can still execute, until fapolicyd is restarted, as shown in the example below:

      Sample program:
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
      [user@vm-fapolicy8 ~]$ cat > hello.c << EOF
      #include <stdio.h>
      int main(int argc, char *argv[])
      {
      printf("Hello!\n");
      return 0;
      }
      EOF

      [user@vm-fapolicy8 ~]$ gcc -o hello hello.c
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

      Program initially untrusted:
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
      [user@vm-fapolicy8 ~]$ ./hello
      -bash: ./hello: Operation not permitted
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

      Trusting the program:
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
      [root@vm-fapolicy8 ~]# fapolicyd-cli -f add /home/user/hello
      [root@vm-fapolicy8 ~]# fapolicyd-cli -u
      Fapolicyd was notified
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

      Program now trusted:
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
      [user@vm-fapolicy8 ~]$ ./hello
      Hello!
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

      Untrusting the program:
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
      [root@vm-fapolicy8 ~]# fapolicyd-cli -f delete /home/user/hello
      [root@vm-fapolicy8 ~]# fapolicyd-cli -u
      Fapolicyd was notified
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

      Program untrusted again: (STILL EXECUTES!)
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
      [user@vm-fapolicy8 ~]$ ./hello
      Hello!
      -------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

      Looks like a cache issue.

      Version-Release number of selected component (if applicable):

      fapolicyd-1.1.3-8.el8_7.1.x86_64

      How reproducible:

      Always, see above.

      — Additional comment from Renaud Métrich on 2023-03-24 13:56:50 UTC —

      I checked with "integrity = sha256", this doesn't help (just in case this was related to BZ #2181544).

      — Additional comment from Radovan Sroka on 2023-03-24 14:08:38 UTC —

      (In reply to Renaud Métrich from comment #1)
      > I checked with "integrity = sha256", this doesn't help (just in case this
      > was related to BZ #2181544).

      This is basically duplicate of BZ #2179701. Different symptoms but the same source. I want to keep both bugzillas open for now.

      Acceptance Criteria:

      • removing a file from the trustdb has immediate effect without the service restart

            dapospis@redhat.com Dalibor Pospíšil
            rsroka@redhat.com Radovan Sroka
            Radovan Sroka Radovan Sroka
            Dalibor Pospíšil Dalibor Pospíšil
            Parth Shah Parth Shah
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: