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

SELinux policy prevents certmonger_unconfined_t from recieving D-Bus message replies from certmonger_t

    • Icon: Bug Bug
    • Resolution: Won't Do
    • Icon: Undefined Undefined
    • None
    • rhel-8.10
    • selinux-policy
    • No
    • None
    • rhel-sst-security-selinux
    • ssg_security
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None

      What were you trying to do that didn't work?

      I have a certmonger orchestrating the issuing of TLS certificates for network devices.

      A certificate tracking request's pos-save script is invoked to transfer a newly-issued certificate to a network device.

      This script queries certmonger via D-Bus to retrieve details of the tracking request such as the file where the certificate's private key is found.

      The script runs as certmonger_unconfined_t and it looks like it is allowed to send D-Bus messages to certmongner (running as certmonger_t), but then certmonger is not allowed to send the reply back to the script:

      type=USER_AVC msg=audit(08/11/24 19:16:50.189:6984) : pid=836 uid=dbus auid=unset ses=unset subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_return dest=:1.1805 spid=1530 tpid=710522 scontext=system_u:system_r:certmonger_t:s0 tcontext=system_u:system_r:certmonger_unconfined_t:s0 tclass=dbus permissive=0  exe=/usr/bin/dbus-daemon sauid=dbus hostname=? addr=? terminal=?' 
      

      What is the impact of this issue to you?

      Annoying but can be worked around by writing a script that has all the info about the certificate tracking request passed in as command line parameters, and then dealing with the annoyance of having to duplicate the tracking request's private key file path into the command line that invokes the post-save script.

      Or with this allow rule:

      allow certmonger_t certmonger_unconfined_t:dbus send_msg; 

      Please provide the package NVR for which the bug is seen:

      selinux-policy-3.14.3-139.el8_10.noarch

      How reproducible is this bug?:

      Very

      Steps to reproduce

      1.  Configure a certificate tracking request with a post-save script: getcert request -I post-save-test -c SelfSign -k /etc/pki/tls/private/selfsign.key -f /etc/pki/tls/certs/selfsign.crt -C /usr/local/bin/post-save.py
      2. Set file context of the script: chcon -t certmonger_unconfined_exec_t /usr/local/bin/post-save.py
      3. Set script executable: chmod 0755 /usr/local/bin/post-save.py
      4. Renew the tracking request: getcert resubmit -i post-save-test
      5. View script output: journalctl -u certmonger

      Here's a minimal script:

      #!/usr/bin/python3
      import dbus
      bus = dbus.SystemBus()
      certmonger = bus.get_object("org.fedorahosted.certmonger", "/org/fedorahosted/certmonger")
      certmonger.get_requests(dbus_interface="org.fedorahosted.certmonger")
      

      Expected results

      Post-save script should not fail

      Actual results

      Script fails:

      Traceback (most recent call last):
        File "/usr/local/sbin/aruba-vc-cert-transfer.py", line 232, in <module>
          sys.exit(main(sys.argv))
        File "/usr/local/sbin/aruba-vc-cert-transfer.py", line 57, in main
          request_obj = find_request(bus, crt_file)
        File "/usr/local/sbin/aruba-vc-cert-transfer.py", line 202, in find_request
          for request_obj in certmonger.get_requests(dbus_interface="org.fedorahosted.certmonger"):
        File "/usr/lib64/python3.6/site-packages/dbus/proxies.py", line 70, in __call__
          return self._proxy_method(*args, **keywords)
        File "/usr/lib64/python3.6/site-packages/dbus/proxies.py", line 145, in __call__
          **keywords)
        File "/usr/lib64/python3.6/site-packages/dbus/connection.py", line 651, in call_blocking
          message, timeout)
      dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
      

              rhn-support-zpytela Zdenek Pytela
              staticyrro7 Sam Morris
              Zdenek Pytela Zdenek Pytela
              SSG Security QE SSG Security QE
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: