Bug 163223 - auditd initscript reports errors in default /etc/audit.rules
auditd initscript reports errors in default /etc/audit.rules
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: audit (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Grubb
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-07-14 03:53 EDT by Paul Howarth
Modified: 2007-11-30 17:11 EST (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-08-10 09:05:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace of auditctl (5.50 KB, text/plain)
2005-07-16 13:08 EDT, Robert Hinson
no flags Details
strace auditctl -D 2> trace.txt (audit-0.9.19-1.FC4) (4.63 KB, text/plain)
2005-07-16 13:23 EDT, Paul Howarth
no flags Details
strace of running "auditcl -D" (5.42 KB, text/plain)
2005-09-05 09:12 EDT, Tomek
no flags Details

  None (edit)
Description Paul Howarth 2005-07-14 03:53:30 EDT
Updated to audit-0.9.15-1.FC4 and now a restart of auditd results in:

# service auditd restart
Stopping auditd:                                           [  OK  ]
Error receiving watch list (Unknown error 4294967274)
Starting auditd:                                           [  OK  ]
Error receiving watch list (Unknown error 4294967274)
There was an error in line 5 of /etc/audit.rules

/etc/audit.rules unchanged from the default:
------------------------------------------------------------
# This file contains the auditctl rules that are loaded
# whenever the audit daemon is started via the initscripts.

# First rule - delete all
-D

# Feel free to add below this line. See auditctl man page

# Increase the buffers to survive stress events
-b 256
------------------------------------------------------------

The "error" does not appear to stop auditd from starting.


Version-Release number of selected component (if applicable):
audit-0.9.15-1.FC4

How reproducible:
I have three systems exhbiting this issue, and was alerted to it by another user
on fedora-list. Same thing happens every time I try restarting auditd.
Comment 1 Steve Grubb 2005-07-14 09:15:05 EDT
This is a duplicate of #160318 & #161322.
Comment 2 Steve Grubb 2005-07-15 12:58:04 EDT
audit-0.9.19 was put into FC4 testing & rawhide. Please give it a try and let me
know if this works for you. Thanks.
Comment 3 Paul Howarth 2005-07-15 13:08:53 EDT
Did "yum --enablerepo=updates-testing update audit" and this updated audit and
audit-libs to 0.9.19-1.FC4. Still get the error message though:

# rpm -q audit
audit-0.9.19-1.FC4
# service auditd restart
Stopping auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
Starting auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
There was an error in line 5 of /etc/audit.rules
Comment 4 Steve Grubb 2005-07-15 13:16:48 EDT
This looks like the old libs is still installed. I was thinking that updating
audit should update audit-libs as well. Did it miss that? Thanks.
Comment 5 Paul Howarth 2005-07-15 13:22:01 EDT
No, as I mentioned, audit-libs got updated too:

# rpm -q audit audit-libs
audit-0.9.19-1.FC4
audit-libs-0.9.19-1.FC4
Comment 6 Robert Hinson 2005-07-15 19:33:19 EDT
The problem is the -D switch in the /etc/audit.rules.
If you look at the man page for auditctl and auditd, there is now -D switch.
Comment 7 Robert Hinson 2005-07-15 19:41:45 EDT
And if you type auditctl -D you get the same error.
Comment 8 Steve Grubb 2005-07-16 05:19:53 EDT
Could you attach an strace output to this bug report?

strace auditctl -D 2> trace.txt

Thanks
Comment 9 Robert Hinson 2005-07-16 13:08:26 EDT
Created attachment 116842 [details]
strace of auditctl
Comment 10 Paul Howarth 2005-07-16 13:23:30 EDT
Created attachment 116843 [details]
strace auditctl -D 2> trace.txt (audit-0.9.19-1.FC4)

strace output from FC4 box with audit/audit-libs 0.9.19-1.FC4
Comment 11 Andre Ruiz 2005-07-16 19:00:44 EDT
If you run auditctl --help, there's a -D switch, but it's not in the man page,
and it triggers that error. Which is really odd (one would expect the opposite).
Comment 12 Steve Grubb 2005-07-17 12:13:26 EDT
Thanks for the straces. They show that the kernel is not liking the rules
request. This has been in kernels since 2.6.0. What kernels are you using and do
you have audit syscall support compiled in? auditctl appears to be correctly
reporting a kernel problem based on both straces.

Regarding -D, auditctl supports it. It was in the man pages and appears to have
been accidentally deleted. I added it back to the man pages, thanks for pointing
that out.
Comment 13 Eric Tanguy 2005-07-17 12:18:12 EDT
the straces are not from me but i have the same problem using the last fc4 stock
kernel 2.6.12-1.1398_FC4.
Comment 14 Paul Howarth 2005-07-17 13:32:36 EDT
The second strace (comment #10) was from me and I'm currently running
2.6.12-1.1390_FC4 on the machine that was from.
Comment 15 George N. White III 2005-07-18 18:48:30 EDT
2.6.12-1.1390_FC4 appears to have been configured for audit syscall support:

$ ls -l /lib/modules/2.6.12-1.1390_FC4/build/include/config/audit*.h
-rw-r--r--  7 root root 23 Jun  2 23:54
/lib/modules/2.6.12-1.1390_FC4/build/include/config/audit.h
-rw-r--r--  7 root root 30 Jun  2 23:54
/lib/modules/2.6.12-1.1390_FC4/build/include/config/auditsyscall.h
$ cat /lib/modules/2.6.12-1.1390_FC4/build/include/config/audit*.h
#define CONFIG_AUDIT 1
#define CONFIG_AUDITSYSCALL 1
Comment 16 Ed Johns 2005-07-21 13:08:51 EDT
I am having the same roblem wih auditd.  Have the same audit.rules as the
original post.  I am running:

kernel 2.6.12-1.1398_FC4
audit-0.9.19-1.FC4
audit-libs-0.9.19-1.FC4

When I execute auditctl -D I get:

Error sending rule list request (Invalid argument)
File system watches not supported
Comment 17 Steve Grubb 2005-07-27 08:58:14 EDT
I am using the same packages as listed above and I cannot reproduce the problem.
What arch is the kernels above? Did you ever have 2 instance of audit packages
installed? (up2date bug)  Did you rpm -Fvh the audit packages? Have you rebooted
since installing? Is there anything unusual about the system setup? Are you
mixing rawhide and FC4 packages? Are you tweeking SE Linux policy?

I'm kind of at a dead end without determining what is different about your
systems and how to reproduce.
Comment 18 Andre Ruiz 2005-07-27 09:19:27 EDT
Hi Steve!

This was a fresh FC4 install. No upgrades, nothing fancy. Just installed the
system and upgraded to the last packaged versions using yum. As soon as I can
remember after installing, the error was already there (maybe even before the
yum update). I think I saw it in the first reboot, inside the rhgb window.

- Kernel package: kernel-2.6.12-1.1398_FC4
- Never had 2 instances of audit installed, from what I remember
- Did not rpm -Fvh any package
- Rebooted many times, error always there
- Nothing unusual in the system setup
- Not mixing anything from others into FC4
- SELinux is disabled

If I can do anything to help, please tell me. Remote access to a system with
that problem would help?

-andre
Comment 19 Steve Grubb 2005-07-27 10:01:07 EDT
I still need the arch. Could you run uname -a and paste that into bugzilla. I'm
using 586 & 686 kernels. I have tried SE Linux disabled, but doesn't produce the
problem either. Are you using any security module in place of SE Linux? Do you
have anything LD_PRELOADED? Have you done anything with capabilities?

I might be interested in remote access if I can't figure out what is wrong
another way. However, to run auditctl, I need to have root access. So, I'd
prefer to duplicate the problem on my machine if at all possible.
Comment 20 Steve Grubb 2005-07-27 10:02:40 EDT
Also, how are you disabling SE Linux. Just curious.
Comment 21 Andre Ruiz 2005-07-27 10:20:03 EDT
- arch: x86 32 bits, AMD Sempron 3000+, ASUS A7V8X, GeForce 2 MX400

Linux foobar.mydomain 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686
athlon i386 GNU/Linux

- No other security modules
- Nothing LD_PRELOADED
- Nothing changed in capabilities, at least not at will
- Disabled SE Linux in anaconda, during install.

$ grep -v ^# /etc/sysconfig/selinux
SELINUX=disabled
SELINUXTYPE=targeted

I did not touch that file after instalation, i'm just showing that it is
supposed to be disabled, according to it.
Comment 22 Ed Johns 2005-07-27 10:46:37 EDT
Linux system.domain 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686 i686
i386 GNU/Linux

I disabled selinux using system-config-securitylevel.  The
/etc/sysconfig/selinux file shows:

SELINUX=disabled
SELINUXTYPE=targeted

Nothing is LD_PRELOADED.
Comment 23 Need Real Name 2005-07-27 12:17:10 EDT
[root@localhost ~]# grep -v ^# /etc/sysconfig/selinux
SELINUX=disabled
SELINUXTYPE=targeted
[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.12-1.1398_FC4smp #1 SMP Fri Jul 15 01:30:13 EDT
2005 i686 i686 i386 GNU/Linux
Comment 24 Steve Grubb 2005-07-27 12:57:21 EDT
OK. I'm able to reproduce. I have a feeling this is a kernel bug.
Comment 25 Andre Ruiz 2005-07-27 13:05:40 EDT
Just out of curiosity, what was missing in your setup and what info was the key
to reproduce it?
Comment 26 Steve Grubb 2005-07-27 13:12:27 EDT
Having SELINUX=disabled was the missing issue. This is not a normal
configuration for FC. I tried setenforce 0 and this did not do it. The reference
audit kernels do not exhibit this problem. I think there is a patch collision
kernel side.
Comment 27 Paul Howarth 2005-07-27 14:18:16 EDT
That's not quite solved it I'm afraid:

# uname -a
Linux laurel.intra.city-fan.org 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT
2005 i686 athlon i386 GNU/Linux
# getenforce
Permissive
# rpm -q audit audit-libs
audit-0.9.19-1.FC4
audit-libs-0.9.19-1.FC4
# service auditd restart
Stopping auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
Starting auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
There was an error in line 5 of /etc/audit.rules
#

I'm not LD_PRELOADing anything. Nothing much fancy on this system. No custom
SELinux rules etc. Just rebooted after updating kernel and audit*.

I have other systems on which the combination of audit*0.9.19 and kernel
2.6.12-1.1398_FC4 has fixed this issue for me though.

Comment 28 Steve Grubb 2005-07-27 14:41:05 EDT
Paul, no one said it was solved. I just found out how to reproduce it. In the
system you are reporting on, SE Linux is permissive rather than enforcing. I'd
be willing to bet that the systems which are working are in enforcing mode and
systems with problems are either permissive or disabled.
Comment 29 Paul Howarth 2005-07-28 02:41:49 EDT
Ah, I thought from Comment #26 that you meant that "Permissive" and "Disabled"
behaved differently.

Turning on Enforcing does fix it, as you say:

# setenforce 1
# service auditd restart
Stopping auditd:                                           [  OK  ]
Starting auditd:                                           [  OK  ]
# setenforce 0
# service auditd restart
Stopping auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
Starting auditd:                                           [  OK  ]
Error sending rule list request (Invalid argument)
There was an error in line 5 of /etc/audit.rules

The machine that was "fixed" earlier also was running in Enforced mode because
I'd sorted out the issues I was having with SELinux on that box. Time to do the
last couple of machines now. Thanks.
Comment 30 William Lovaton 2005-08-02 23:00:16 EDT
Just drop by to say "me too".  :-)

I disabled SELinux in anaconda during installation and I am seeing this too with
the updates from a month ago (more or less).

Linux athlon2000 2.6.12-1.1398_FC4 #1 Fri Jul 15 00:52:32 EDT 2005 i686 athlon
i386 GNU/Linux

[william@athlon2000 ~]$ grep -v ^# /etc/sysconfig/selinux
SELINUX=disabled
SELINUXTYPE=targeted

Although it says it fails, auditd seems to work ok.  Any idea about the problem?
Comment 31 David Woodhouse 2005-08-06 16:33:13 EDT
Look at the recvfrom() calls in that strace output. Pass it through 
           grep recvfrom | grep -v MSG_PEEK

Observe that we're only ever retrieving two packets from the netlink socket. The
check_ack() function doesn't actually dequeue the packet it peeks at, if it
detects an error. Thus, it's seeing the error for its second request repeatedly.
Comment 32 Trever Adams 2005-08-08 06:43:41 EDT
This happens on enabled and warn as well.
Comment 33 Steve Grubb 2005-08-08 14:21:12 EDT
Regarding comment #31, while this is "a" problem, it is not "the" problem. The
problem is in the 1st set of exchanges:

sendto(3, "\20\0\0\0\352\3\5\0\1\0\0\0\0\0\0\0", 16, 0, {sa_family=AF_NETLINK, 
pid=0, groups=00000000}, 12) = 16
^^^^
Sent rule list request. seq #1

select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 100000})
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0P\16\0\0\0\0\0\0\20\0\0\0\352\3"..., 8476, 
MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) 
= 36
^^^^
Check for ack. Got EINVAL back. Why? This is the bug !!!

I will update user space to make sure the bad packet gets eaten. I think we
still have the original problem.
Comment 34 Steve Grubb 2005-08-08 14:27:26 EDT
Actually, the first recvfrom is an ack, the 352 is too far to the right. Still
looking...
Comment 35 Steve Grubb 2005-08-09 08:56:16 EDT
audit-1.0.2 was released into rawhide. It will also be released to FC4 testing.
Could everyone please give it a try and let me know if it fixes the problem? Thanks.
Comment 36 Jacek Piskozub 2005-08-10 05:12:25 EDT
I tried audit-1.0.2 from FC4 testing (the development one was built for a newer
glibc so was unusable for me). The results are mixed.

Yes, the line 5 error happily went away (<joke>or at least was nicely hidden
from me</joke>). 

However, I still have another eoor: a shut-down error message that first
appeared at the same time at the "line 5" problem. It happens when system is
syncing hardware clock to system time. The error message says something about
audit daemon not found at pid=<pid_number>. No surprise about that as auditd is
being switched off before clock syncing. However, if I switch off the audit
daemon service, this error message goes away. And I never saw this error before
audit-0.9-15. 

BTW, I use a fully updated FC4 with Selinux disabled. 
Comment 37 David Woodhouse 2005-08-10 05:19:26 EDT
The new error sounds like auditd is dying without 'signing off' by telling the
kernel that the audit_pid is now zero.
Comment 38 Steve Grubb 2005-08-10 09:05:28 EDT
The issue in comment #36 is bug 163500. You can add yourself to the cc list on
that bug if you want to. I will close this bug report based on positive
feedback. Thanks for reporting the bug, sending traces, and having patience.
Comment 39 Dusko Dobranic 2005-08-16 06:46:18 EDT
SE Linux disabled
kernel 2.6.12-1.1398_FC4
audit-libs-1.0.2-3.FC4
audit-1.0.2-3.FC4

When I execute auditctl -D I get:

No rules
File system watches not supported
Comment 40 Tomek 2005-09-04 17:00:03 EDT
Hello,

I have:

[root@ts ~]# uname -a
Linux ts 2.6.12.6 #1 Sun Sep 4 21:09:20 CEST 2005 i686 i686 i386 GNU/Linux

audit-1.0.3-1.fc4

[root@ts ~]# auditctl -D
Error receiving watch list (Invalid argument)
No rules
NLMSG_ERROR 22 (Invalid argument)
[root@ts ~]#

regards
ts.
Comment 41 Steve Grubb 2005-09-05 08:29:45 EDT
Regarding comment #40, could you attach a strace of running "auditcl -D"? Thanks.
Comment 42 Tomek 2005-09-05 09:12:54 EDT
Created attachment 118470 [details]
strace of running "auditcl -D"

I attached strace a strace of running "auditcl -D"

regards
ts.

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