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

Inform users about installed third-party python modules and consequences

Linking RHIVOS CVEs to...Migration: Automation ...RHELPRIO AssignedTeam ...SWIFT: POC ConversionSync from "Extern...XMLWordPrintable

    • leapp-repository-0.23.0-2.el8_10
    • Important
    • rhel-upgrades
    • 12
    • 0
    • False
    • False
    • Hide

      None

      Show
      None
    • None
    • Red Hat Enterprise Linux
    • None
    • None

      The leapp upgrade command can fail during the reboot phase when having 3rd party Python modules installed in /usr/local/lib/python3.6.

      This can be hardened by making leapp only executes with "safe paths", through adding this below in the shebang:

      #! /usr/libexec/platform-python -EsI
      

      Additionally, it would be great to have a High Risk actor when leapp finds out /usr/local/lib/python3.6 exists for RHEL7 to RHEL8 upgrades or /usr/local/lib/python3.9 for RHEL8 to RHEL9 upgrade.

      Indeed, currently there is no protection, which may lead to getting a non-operational system upon upgrade, such as in the example below (RHEL7 to RHEL8 upgrade):

      1. Install python3
        # yum install python3
      2. Install "initparse" through pip3.6 using a deprecated module
        # pip3.6 install iniparse==0.4
        # ll /usr/local/lib/python3.6/site-packages/
        total 0
        drwxr-xr-x. 3 root root 108 Dec 19 15:11 iniparse
        drwxr-xr-x. 2 root root 117 Dec 19 15:11 iniparse-0.4-py3.6.egg-info
        
      3. Upgrade
        # leapp upgrade; reboot

      Upon upgrade, once rebooted on RHEL8, subscription-manager will not be functional:

      # subscription-manager status
      Unable to find Subscription Manager module.
      Error: No module named 'ini'
      

      This is because /usr/local/lib/python3.6 messes up with system modules.

        1. Update
          The hardening does not work as the problem is that RHSM and other tools are not hardened, hence the hardening on the leapp level does not make any change. At this point the only possible solution is to report to user third-party python modules with high risk severity, informing them that any third-party python module conflicting with system modules could affect the upgrade and functionality of the target system negatively. The report should focus only on python modules that are relevant specifically to the target python version at this point (if any present). The plytform python on the source level is already affected if any third-party modules are present and usually it breaks things before we could create the report, so it does not make sense to check python modules for the source platform python.

              rh-ee-tfratrik Tomas Fratrik
              rhn-support-rmetrich Renaud Métrich
              leapp-notifications leapp-notifications
              RHEL Upgrades QE Team RHEL Upgrades QE Team
              Miriam Portman Miriam Portman
              Votes:
              0 Vote for this issue
              Watchers:
              15 Start watching this issue

                Created:
                Updated: