Problem with audit

I am running lspp.17 kernel with audit-1.2.1 on an x86_64 system. I noticed this behavior (has anyone encountered anything similar)

After a reboot, the first auditctl command that I try will not work, After that it works fine.

Example:

# auditctl -l
Error sending rule list request (Operation not permitted)
# auditctl -l
No rules
           -- Reboot --
# auditctl -a entry,always -S chmod
Error sending add rule request (Operation not permitted)
# auditctl -a entry,always -S chmod
# auditctl -l
LIST_RULES: entry,always syscall=chmod

The problem is reproducible .. and it happens no matter what auditctl command you try at first (listing, adding watches, or adding rules .. etc)

- Loulwa

How does lspp.18 do? It seems more stable to me than lspp.17. Also, what SE Linux policy do you have loaded ?

Thanks,
-Steve

I am running SELinux in permissive mode.
I tried the lspp.18 kernel and I still see the same problem.

- Loulwa

Hmm. What SE Linux policy are you running? (name & version)

Thanks,
-Steve

I have the default reference policy that came with a version from rawhide just before the FC5 release ... it's version 20 (as in /selinux/policyvers).

Does it even matter if the system is running in permissive mode?

Thanks,
- Loulwa

I guess not. Can you send me an strace output during the problem. FWIW, it works fine on my machine.

Thanks,
-Steve

sure .. I'm attaching the strace output.

Thanks,
-Loulwa

[root@xracer2 ~]# strace auditctl -l
execve("/sbin/auditctl", ["auditctl", "-l"], [/* 22 vars */]) = 0
brk(0) = 0x514000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaaab000 uname({sys="Linux", node="xracer2.ltc.austin.ibm.com", ...}) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=78437, ...}) = 0
mmap(NULL, 78437, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aaaaaaac000
close(3) = 0
open("/lib64/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360W\300"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=115944, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaac0000 mmap(0x38bec00000, 1131368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x38bec00000 mprotect(0x38bec10000, 1044480, PROT_NONE) = 0
mmap(0x38bed0f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xf000) = 0x38bed0f000 mmap(0x38bed11000, 13160, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x38bed11000
close(3) = 0
open("/lib64/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \321\341"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1580600, ...}) = 0
mmap(0x38bae00000, 2334888, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x38bae00000 mprotect(0x38baf32000, 1044480, PROT_NONE) = 0

mmap(0x38bb031000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x131000) = 0x38bb031000
mmap(0x38bb036000, 16552, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x38bb036000
close(3)                                = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaac1000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaac2000

arch_prctl(ARCH_SET_FS, 0x2aaaaaac1870) = 0
mprotect(0x38bed0f000, 4096, PROT_READ) = 0
mprotect(0x38bb031000, 16384, PROT_READ) = 0
mprotect(0x38bad19000, 4096, PROT_READ) = 0
munmap(0x2aaaaaaac000, 78437) = 0
set_tid_address(0x2aaaaaac1900) = 2301
rt_sigaction(SIGRTMIN, {0x38bec053b0, [], SA_RESTORER|SA_SIGINFO, 0x38bec0cce0}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x38bec05310, [], SA_RESTORER|SA_RESTART|SA_SIGINFO, 0x38bec0cce0}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=RLIM_INFINITY}) = 0 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0x7fffde654ce0, 35, (nil), 0}) = 0

getuid()                                = 0
socket(PF_NETLINK, SOCK_RAW, 9)         = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0

sendto(3, "\20\0\0\0\365\3\5\0\1\0\0\0\0\0\0\0", 16, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 16
poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 100) = 1
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\375\10\0\0\377\377\377\377\20\0"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\375\10\0\0\377\377\377\377\20\0"..., 8476, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 write(2, "Error sending rule list request "..., 57Error sending rule list request (Operation not permitted)) = 57
write(2, "\n", 1
) = 1
close(3) = 0
exit_group(0) = ?
Process 2301 detached
[root@xracer2 ~]#

recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\375\10\0\0\377\377\377\377\20\0"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36

This is definitely sending back EPERM. EPERM is only sent back when the sender does not have CAP_AUDIT_CONTROL. Root processes should have that. Not sure why this is failing the first time and OK the second. That seems to sound like an uninitialized variable. Nothing has changed in this part of the code in a very long time...unless this is another netlink bug.

-Steve

Sorry didn't think of that when I read your email first ...

# rpm -qa | grep policy
selinux-policy-2.2.28-1
selinux-policy-targeted-2.2.28-1
selinux-policy-mls-2.2.28-1

According to the /etc/selinux/config I am running the mls policy in permissive mode.

Thanks
-loulwa