Bug 1359878 - Non-error audit messages in Logwatch
Summary: Non-error audit messages in Logwatch
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: logwatch
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jan Synacek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-25 15:26 UTC by John Griffiths
Modified: 2019-01-04 11:22 UTC (History)
27 users (show)

Fixed In Version: logwatch-7.5.0-1.fc30
Clone Of: 1231364
Environment:
Last Closed: 2019-01-04 11:22:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description John Griffiths 2016-07-25 15:26:10 UTC
+++ This bug was initially created as a clone of Bug #1231364 +++

Description of problem:
I'm getting a ton of useless stuff in logwatch every morning in the "kernel audit" section. I know how to disable audit reporting entirely, but there are times when audit messages are useful. Is this just a case of the logwatch scripts not up to date with the messages in F22?  


Sample logwatch output:

https://gist.github.com/sterndata/8b0f7474bfa2536a7870:

--- Additional comment from Jan Synacek on 2015-06-15 02:08:28 EDT ---

AFAIK systemd writes the audit messages to the journal (or /var/log/messages if you don't use the journal), and they seem to be slightly differently formatted. I believe that logwatch already parses the audit messages from /var/log/audit/. I think that #1227379 has to be solved first.

--- Additional comment from Steven Stern on 2015-06-16 14:02:28 EDT ---

Adding 

  Service = "-audit"

to /etc/logwatch/conf/logwatch.conf has removed the stuff from logwatch, but that's just the equivalent of putting a piece of black tape over the warning light.

--- Additional comment from Jan Synacek on 2015-06-17 02:26:46 EDT ---



--- Additional comment from Jan Synacek on 2015-07-01 03:00:32 EDT ---



--- Additional comment from Derek Atkins on 2015-09-16 09:16:53 EDT ---

This seems to be something new in F22; I just upgraded a system yesterday from an older F22 to current and it started doing this.  Unfortunately while I could try to extract the new packages, I'm not sure whether I can find the older packages I upgraded from.

--- Additional comment from Dominik 'Rathann' Mierzejewski on 2015-09-25 03:34:45 EDT ---

I only get lines like this one in **Unmatched Entries**:

audit: <audit-1131> pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat-collect comm="systemd" e
xe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

On a very quiet server (just two services running) I get 300-400 hundred of these every day.

logwatch-7.4.1-5.20150731svn293.fc22.noarch

The patch from bug 1232565 seems to work fine.

--- Additional comment from Erik P. Olsen on 2015-10-14 06:32:44 EDT ---

The patch from bug 1232565 only reduced the number of lines by approx 50% in my case. So I removed the patch.

--- Additional comment from Gerald Cox on 2015-11-01 07:57:17 EST ---

I've noticed this also. Jan do you know if this has reported upstream?   It's not critical but definitely causes one to tend to completely ignore the entire section due to all the false positives.

--- Additional comment from Jan Synacek on 2015-11-02 02:16:58 EST ---

I don't know but I guess it's not, as this is caused by systemd logging into the common log. It's not really a problem in logwatch and as I mentioned in comment #1, the systemd report should be resolved first. As a workaround, you can always put custom ignore expressions to /etc/logwatch/conf/ignore.conf.

--- Additional comment from Gerald Cox on 2015-11-02 06:38:02 EST ---

Great thanks.

--- Additional comment from Rand Kmiec on 2015-11-04 21:14:27 EST ---

Just in case it helps anybody else, I fixed this on my server by doing the following, which removes the successful results and leaves everything else (and thus cuts down most of the clutter):

======================
cp /usr/share/logwatch/default.conf/services/audit.conf /etc/logwatch/conf/services

echo '*Remove = "<audit-[0-9]+> pid=[0-9]+ uid=[0-9]+ auid=[0-9]+ ses=[0-9]+ subj=.*res=success"' >> /etc/logwatch/conf/services/audit.conf
======================

And then you can test it with:

logwatch --service audit --range today

  Seemed a little bit easier to me than trying to change the files that get installed by the package directly, and so far it's working very well for my needs.

--- Additional comment from Rand Kmiec on 2015-11-17 06:07:32 EST ---

Or for Fedora 23 (for the same supression as my last post in Comment 11):

======================
cp /usr/share/logwatch/default.conf/services/audit.conf /etc/logwatch/conf/services

echo '*Remove = "audit: \S+ pid=[0-9]+ uid=[0-9]+ auid=[0-9]+ ses=[0-9]+ subj=.*res=success"' >> /etc/logwatch/conf/services/audit.conf
======================

  I like this better than adding it to the ignore.conf file because it seems to affect what is actually matched, rather than just suppressing the output (in which case you'll only be ignoring the printed lines if there are more than 100, so you might miss actual important messages).

--- Additional comment from Edward Kuns on 2016-01-06 12:06:04 EST ---

If I apply this workaround, it gets rid of some of the noise I see in logwatch.  The remaining lines all look like this:

audit: PROCTITLE proctitle=73656E646D61696C3A207365727665722036342E3235332E33302E3231302E64796E2D652D706F6F6C33392E706F6F6C2E686172677261792E6E6574205B36342E3235332E33302E3231305D2073746172747570

This is on a system upgraded from Fedora 21 to 23, in case that makes a difference.  I haven't done anything regarding kernel auditing.  I have whatever the default behaviour is.  I see that adding this to the workaround in comment 12 (this is the F23 flavor)

echo '*Remove = "audit: PROCTITLE proctitle=[0-9A-F]+"' >> /etc/logwatch/conf/services/audit.conf

suppresses those lines as well.  Is there a reason why I shouldn't suppress PROCTITLE lines in the audit?  Should I not be seeing those, and this is a misconfiguration that these are audited at all?  Is there a more appropriate fix for the PROCTITLE lines than suppressing LogWatch reporting of them?

--- Additional comment from Fedora End Of Life on 2016-07-19 10:47:36 EDT ---

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 1 John Griffiths 2016-11-27 19:07:11 UTC
This was reopened in July 2016. Anyone actually working on it?

Comment 2 Fedora End Of Life 2017-07-25 22:02:09 UTC
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 3 Dominik 'Rathann' Mierzejewski 2017-07-30 12:40:52 UTC
Still not fixed in rawhide.

Comment 4 Jan Kurik 2017-08-15 08:08:35 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 5 Ben Cotton 2018-11-27 18:25:04 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Ben Cotton 2018-11-30 17:58:16 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.