I'm running the .27 kernel and the 1.2.2 tools on an x86_64
(Xeon/EM64T) SMP box with the targeted policy in enforcing mode.
I tried to reproduce the problem discussed yesterday (the very fist
rule doesn't take and the rest do) but it seems to work fine on my
system.
Can you describe more about your configuration and provide exact steps
to reproduce the problem? If you and Loulwa are seeing it but George
(at least not on ppc64) and I aren't, there's got to be something
different about what we're doing or what we're doing it on.
-- ljk
Michael C Thompson wrote:
Michael C Thompson wrote:
> Steve Grubb wrote:
>
>> On Tuesday 16 May 2006 13:23, Steve Grubb wrote:
>>
>>> AFAICT, there are 2 places where an access decision is made,
>>> audit_netlink_ok in kernel/audit.c. And the other place is
>>> selinux_nlmsg_lookup in security/selinux/nlmsgtab.c. I think you'd
>>> want to
>>> patch your kernel to printk its access decision results in both of
>>> those
>>> functions. That should tell us something about what's going on.
>>
>>
>> Mike,
>>
>> Did you ever patch your kernel to get more info or did this problem
>> go away in the latest kernel (lspp.26)?
>
>
> I have tested this on the 26 and 27 kernel and am still experiencing
> the problem. I'm working on tracking it down now.
This is definately not an SELinux issue. I don't know enough about the
audit_reply structure to fully understand what is happening. This is
what I know:
socket_has_perm returns 0, and netlink_recvmsg does definitely get hit.
The error is getting packaged up in the body of the netlink message, but
I don't know where to begin looking for this, nor do I have the time to
continue looking.
If you have any possible fixes, I'll gladly test them, but currently,
I'm at a loss for time and can't continue.
Thanks,
Mike
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit