Problem with audit

Problem with audit

[Loulwa Salem]

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

Re: Problem with audit

[Steve Grubb]

On Thursday 20 April 2006 19:06, Loulwa Salem wrote:
> The problem is reproducible .. and it happens no matter what auditctl
> command you try at first (listing, adding watches, or adding rules .. etc)

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

Re: Problem with audit

[Loulwa Salem]

Steve Grubb wrote:

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

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

- Loulwa

Re: Problem with audit

[Steve Grubb]

On Thursday 20 April 2006 19:26, Loulwa Salem wrote:
> > How does lspp.18 do? It seems more stable to me than lspp.17. Also, what
> > SE Linux policy do you have loaded ?
>
> I am running SELinux in permissive mode.

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

Thanks,
-Steve

Re: Problem with audit

[Loulwa Salem]

Steve Grubb wrote:
> On Thursday 20 April 2006 19:26, Loulwa Salem wrote:

> Hmm. What SE Linux policy are you running? (name & version)
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

Re: Problem with audit

[Steve Grubb]

On Friday 21 April 2006 10:27, Loulwa Salem wrote:
> Does it even matter if the system is running in permissive mode?

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

Thanks,
-Steve

Re: Problem with audit

[Loulwa Salem]

[-- Attachment #1: Type: text/plain, Size: 185 bytes --]

Steve Grubb wrote:

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

sure .. I'm attaching the strace output.

Thanks,
-Loulwa

[-- Attachment #2: trace-bad.txt --]
[-- Type: text/plain, Size: 3624 bytes --]

[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 ~]#

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Problem with audit

[Steve Grubb]

On Friday 21 April 2006 11:30, Loulwa Salem wrote:
> sure .. I'm attaching the strace output.

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

Re: Problem with audit

[Loulwa Salem]

Steve Grubb wrote:
> On Thursday 20 April 2006 19:26, Loulwa Salem wrote:

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

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