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

/usr/share/audit/sample-rules/*.rules are not architecture-independent

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • rhel-9.0.0
    • audit
    • None
    • None
    • rhel-sst-security-special-projects
    • ssg_security
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • If docs needed, set a value
    • None

      Description of problem:

      The content of /usr/share/audit/sample-rules/ was made architecture-dependent, to address bug 1985630.

      However, that means the content that the audit package puts to /usr/share breks the Filesystem Hierarchy Standard (FHS) expectation that /usr/share should have architecture-independent (shared) data.

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

      audit-3.0.7-101.el9_0.2

      How reproducible:

      Deterministic.

      Steps to Reproduce:
      1. Check /usr/share/audit/sample-rules/ on different architectures with sha256sum.

      Actual results:

      5fc54d4981a480e15bc6e1f7e703eeca446cc5b95cc424459c24c40013020d1d /usr/share/audit/sample-rules/71-networking.rules on x86_64 and aarch64,
      a74a05c373c26270bafb0569ed86e5f4574c343fbdf8aab0007560450213d4ba /usr/share/audit/sample-rules/71-networking.rules on s390x.

      a365d53d473232db15518cb163ef2828b13637aac9ffb00a6ea636677fc5f758 /usr/share/audit/sample-rules/30-nispom.rules
      7bc05cbcfde0664abc759bad2fa8577681007d1db77b0bf5a562b1d52f8b0c79 /usr/share/audit/sample-rules/30-ospp-v42-1-create-failed.rules
      c97448ae2dcdbedb4c50464bfcec2a56886314d1ba8ee002f6bf63ec093b1b6b /usr/share/audit/sample-rules/30-ospp-v42-1-create-success.rules
      dc6f182ce7a0195e63f1ce60e0812c601e38de022fb8baf03ad6560e78fd73ca /usr/share/audit/sample-rules/30-ospp-v42-2-modify-failed.rules
      caeb9a7f4bb77ab89027f11789e02eb6e9b4f2fc4346eeaea25efe1730d83fe6 /usr/share/audit/sample-rules/30-ospp-v42-2-modify-success.rules
      74aa84e36882dd5f1bc4f1953b938fc6425a00d28d0c36232b16a5aeadc7b413 /usr/share/audit/sample-rules/30-ospp-v42-3-access-failed.rules
      24bb7aca08d354ddffd8d0addbbd4444a1a86a9766d89abceef22e753171eacd /usr/share/audit/sample-rules/30-ospp-v42-3-access-success.rules
      1eb6a682e840cb04f611ab5f768b65d1f41c898e11ad3c6d0545d03562c03ad0 /usr/share/audit/sample-rules/30-ospp-v42-4-delete-failed.rules
      2c4e9dbd58405bc275e7e187d6ec2eb9436aa54073f557b83ef6e4a06a55fc53 /usr/share/audit/sample-rules/30-ospp-v42-4-delete-success.rules
      on x86_64 and s390x

      293f22a6f9babf77aea552d69ced14ca82cf94984de10c9fafcca6674c99d499 /usr/share/audit/sample-rules/30-nispom.rules
      f816faee268ae1c0f25d547f903182b1f6ed0bbb005bb77091617bc9d9e8e02f /usr/share/audit/sample-rules/30-ospp-v42-1-create-failed.rules
      58e45a5de54a58b4fb640a38643990523f815954fe30634184d388f7dc14e1ce /usr/share/audit/sample-rules/30-ospp-v42-1-create-success.rules
      00ddbe6c8bf04b5a4d334f66f71a64ba556ce0811f36f5382e89d4ad58c64530 /usr/share/audit/sample-rules/30-ospp-v42-2-modify-failed.rules
      2628f73a77fa71ad0aba5cdd01fef63ba9b7cb08f4799bf017627cf84115cc4f /usr/share/audit/sample-rules/30-ospp-v42-2-modify-success.rules
      36685ba35d5402c40633de08f7445134419be60875e68b1d869cb7f3f4153d21 /usr/share/audit/sample-rules/30-ospp-v42-3-access-failed.rules
      22d01156457138c1a4d1e57d3e167109a7e410ba4ae1a7a6633a02a94f1c37e8 /usr/share/audit/sample-rules/30-ospp-v42-3-access-success.rules
      52b9839c59728a644541cf2a09265e4e094fe6df2cac550fddd6c99085e75fbe /usr/share/audit/sample-rules/30-ospp-v42-4-delete-failed.rules
      846c5dcc432d839cdc58e2ec5eb2553967d5b1cc464533f4f1aafad80c2c337a /usr/share/audit/sample-rules/30-ospp-v42-4-delete-success.rules
      on aarch64

      Expected results:

      The files should not differ ... so if the rules have to differ, they likely need to live somewhere else.

      Additional info:

      The /usr/share/audit/sample-rules location should likely be preserved, possibly as symlink, because many tools and processes expect it by now.

              scorreia@redhat.com Sergio Correia
              rhn-engineering-jpazdziora Jan Pazdziora
              Sergio Correia Sergio Correia
              SSG Security QE SSG Security QE
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: