RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1497279 - [RFE] Add option to interpret fields in auditd's syslog plugin
Summary: [RFE] Add option to interpret fields in auditd's syslog plugin
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: audit
Version: 8.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: 8.2
Assignee: Steve Grubb
QA Contact: Ondrej Moriš
Mirek Jahoda
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-29 15:53 UTC by Dylan Gross
Modified: 2023-12-15 15:58 UTC (History)
9 users (show)

Fixed In Version: audit-3.0-0.14.20191104git1c2f876
Doc Type: No Doc Update
Doc Text:
See https://bugzilla.redhat.com/show_bug.cgi?id=1757986
Clone Of:
Environment:
Last Closed: 2020-04-28 16:46:58 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-29015 0 None None None 2023-09-07 19:02:00 UTC
Red Hat Product Errata RHBA-2020:1812 0 None None None 2020-04-28 16:47:05 UTC

Description Dylan Gross 2017-09-29 15:53:26 UTC 
1. Proposed title of this feature request

Add an option to allow auditd to write plaintext data to logs in addition to the current method of writing data=<hex> value.


3. What is the nature and description of the request?

Customer forwards their logs using rsyslog to a third party tool which cannot read the hex data that is forwarded.   They would like data that is decoded (similar to the "aureport --tty" format) to be able to be writted to the logs as well, so that when forwarded to their third party tool, it can be read.


4. Why does the customer need this? (List the business requirements here)

This assists in integration with a 3rd party log aggregator tool (ArcSight)
 

5. How would the customer like to achieve this? (List the functional requirements here)

It was suggested that either a potential flag to pam_tty_audit or and auditd flag be used to additionally write the plaintext output in addition to the hex output.
 

6. For each functional requirement listed in question 5, specify how Red Hat

and the customer can test to confirm the requirement is successfully implemented.

   The output similar to "aureport --tty" can be made to appear in /var/log/messages (or whichever other log is chosen by syslog for writing the data)
 

7. Is there already an existing RFE upstream or in Red Hat bugzilla?

I do not believe so.
 

8. Does the customer have any specific timeline dependencies?

No 


9. Is the sales team involved in this request and do they have any additional input?

 Yes


10. List any affected packages or components.

 pam, auditd

11. Would the customer be able to assist in testing this functionality if implemented?

Yes.
Comment 4 Steve Grubb 2017-09-29 16:20:08 UTC 
The problem with this is that it opens you to parsing, TTY, and UTF based text attacks. It is designed this way for a reason. The logs must be translated by ausearch or something else to render them inert and present them safely.

CVE-2015-5186 Audit: log terminal emulator escape sequences handling
Comment 5 Reid Wahl 2017-10-27 00:56:18 UTC 
Steve,

Understood, at least at a basic level. One suggestion that we mentioned in the RH support case is to create the flag for the audisp syslog plugin, rather than for audit or pam_tty_audit itself. Would this still create a vulnerability? I'm unsure. The end result that our SIEM team is seeking is essentially a different presentation format in /var/log/messages. However, to get there it has to pass through rsyslogd, rather than just printing to the console as it seems aureport and ausearch do.
Comment 6 Reid Wahl 2017-10-27 01:02:36 UTC 
To get to their ArcSight server, I mean.
Comment 7 Steve Grubb 2017-10-27 14:07:01 UTC 
I'll think about that. Maybe if its limited to a plugin that would be acceptable.
Comment 17 Steve Grubb 2019-11-02 21:40:56 UTC 
Upstream commit 4669f76 should address this issue. There is now the possibility to "interpret" as a third argument in the audisp-syslog.conf file.
Comment 18 Ondrej Moriš 2019-11-04 11:25:43 UTC 
Granting qa_ack+ for RHEL-8.2.0.

Acceptance Criteria:

 * [gating] audit message sent via audisp-syslog plugin to syslog is interpreted when plugin is configured with interpret keyword
Comment 19 Steve Grubb 2019-11-04 20:53:07 UTC 
audit-3.0-0.14.20191104git1c2f876 has been built to address this issue.
Comment 21 Ondrej Moriš 2019-11-11 10:57:40 UTC 
Steve, I noticed that when interpretation is enabled, second msg field is missing.

With 'interpret' keyword in syslog audisp plugin:

Nov 11 05:45:19 ci-vm-10-0-137-114 audispd[21334]: type=USER msg=audit(11/11/19 05:45:19) : pid=21374 uid=root auid=root ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe=/usr/sbin/auditctl hostname=ci-vm-10-0-137-114.hosted.upshift.rdu2.redhat.com addr=? terminal=pts/1 res=success

Without 'interpret':

Nov 11 05:50:28 ci-vm-10-0-137-114 audispd[24237]: type=USER msg=audit(1573469428.411:1238): pid=24277 uid=0 auid=0 ses=5 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='interpretation_test exe="/usr/sbin/auditctl" hostname=ci-vm-10-0-137-114.hosted.upshift.rdu2.redhat.com addr=? terminal=pts/1 res=success' UID="root" AUID="root"
Comment 22 Steve Grubb 2019-11-12 08:53:36 UTC 
Unfortunately, the second msg= is stripped by auparse and I'm not 100% sure it can be reliably added back.
Comment 23 Ondrej Moriš 2019-11-12 09:35:28 UTC 
Isn't auparse used in ausearch when '-i' option is used (because in ausearch msg is not stripped). In messages table [1] I see that AUDIT_USER is deprecated. Is it possible that msg stripping is issue in AUDIT_USER only? 

[1] https://github.com/linux-audit/audit-documentation/blob/master/specs/messages/message-dictionary.csv
Comment 24 Steve Grubb 2019-11-12 10:34:21 UTC 
I think that the answer is that we need to do something like text= in USER events.
Comment 25 Ondrej Moriš 2019-11-12 12:26:24 UTC 
OK, thanks, I file a bug for that and I am moving this one back to ON_QA since the issue is caused by interpreting this particular type of event and not by new functionality in syslog audisp plugin.
Comment 26 Steve Grubb 2019-11-13 18:02:07 UTC 
Upstream commit 93c1354solves the missing text reported in comment #21. Will hold this patch for the moment to see if we need any other fixes.
Comment 27 Steve Grubb 2019-11-28 15:01:22 UTC 
Rebuilt with above patch
Comment 31 errata-xmlrpc 2020-04-28 16:46:58 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:1812
Note You need to log in before you can comment on or make changes to this bug.