audit 1.2.2 released
Hi,
I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit It will also be in rawhide tomorrow. The Changelog is:
- Updates for new glibc-kernheaders
- Change auditctl to collect list of rules then delete them on -D
- Update capp.rules and lspp.rules to comment out rules for the possible list
- Add new message types
- Support sigusr1 sender identity of newer kernels
- Add support for ppid in auditctl and ausearch
- fix auditctl to trim the '/' from watches
- Move audit daemon config files to /etc/audit for better SE Linux protection
Beware ! This release has 2 changes to notice. It requires newer glibc-kernheaders and it moves the audit configuration files to the /etc/audit directory. The specfile should handle the transition gracefully.
This release also supports new options in our current development kernels. It adds support for filtering by ppid and searching for ppid in the logs. It supports getting the signal info for senders of sigusr1. And completes the fix for listing or deleting large amounts of syscall rules. Watches that have a trailing '/' will now have it trimmed to make the kernel happier.
2 new message types were added AUDIT_DEV_ALLOC and AUDIT_DEV_DEALLOC for LSPP work. The capp & lspp rules were updated to not have "possible" as the list action.
Please let me know if there are any problems with this release.
-Steve
Quoted 13 lines · Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit It will also be in rawhide tomorrow. The Changelog is:
- Updates for new glibc-kernheaders
- Change auditctl to collect list of rules then delete them on -D
- Update capp.rules and lspp.rules to comment out rules for the possible list
- Add new message types
- Support sigusr1 sender identity of newer kernels
- Add support for ppid in auditctl and ausearch
- fix auditctl to trim the '/' from watches
- Move audit daemon config files to/etc/auditfor better SE Linux protection
Quoted 7 lines
Beware ! This release has 2 changes to notice. It requires newer glibc-kernheaders and it moves the audit configuration files to the
/etc/auditdirectory. The specfile should handle the transition gracefully.This release also supports new options in our current development kernels. It adds support for filtering by ppid and searching for ppid in the logs. It supports getting the signal info for senders of sigusr1. And completes the fix for listing or deleting large amounts of syscall rules. Watches that have a trailing '/' will now have it trimmed to make the kernel happier.
2 new message types were added
AUDIT_DEV_ALLOCandAUDIT_DEV_DEALLOCfor LSPP work. The capp & lspp rules were updated to not have "possible" as the list action.Please let me know if there are any problems with this release.
auditctl is still reporting the "error sending rule" problem. Here are my auditctl and kernel versions:
auditctl version 1.2.2
2.6.16-1.2200.2.2_FC6.lspp.25
# auditctl -l Error sending rule list request (Operation not permitted) # auditctl -l No rules
Thanks,
Mike
Quoted 8 lines · Michael C Thompson
auditctl is still reporting the "error sending rule" problem. Here are my auditctl and kernel versions:
auditctl version 1.2.2
2.6.16-1.2200.2.2_FC6.lspp.25# auditctl -l Error sending rule list request (Operation not permitted)
This is not the error sending rule problem. This looks like a permission problem. What selinux policy and role are you doing this from? Are there any relevant AVCs in the audit logs from this time?
-Steve
Quoted 7 lines · Steve Grubb
Quoted 6 lines · Michael C Thompson
auditctl is still reporting the "error sending rule" problem. Here are my auditctl and kernel versions:
auditctl version 1.2.2
2.6.16-1.2200.2.2_FC6.lspp.25
Quoted 6 lines
Quoted 2 lines
# auditctl -l Error sending rule list request (Operation not permitted)This is not the error sending rule problem. This looks like a permission problem. What selinux policy and role are you doing this from? Are there any relevant AVCs in the audit logs from this time?
-Steve
This is a transcript from Permissive mode, with role being staff_r. I do not see the "Error sending rule list request (Operation not permitted)" when SELinux is disabled (selinux=0) or when as auditadm_r at SystemHigh.
# auditctl -l
Error sending rule list request (Operation not permitted)
[ resulting log activity:
type=AVC msg=audit(1147657744.953:39): avc: denied { nlmsg_readpriv } for pid=2091 comm="auditctl" scontext=root:staff_r:staff_t:s0-s15:c0.c255 tcontext=root:staff_r:staff_t:s0-s15:c0.c255 tclass=netlink_audit_socket
type=SYSCALL msg=audit(1147657744.953:39): arch=40000003 syscall=102 success=yes exit=16 a0=b a1=bfad2760 a2=805b0f8 a3=10 items=0 ppid=2067 pid=2091 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="auditctl" exe="/sbin/auditctl" subj=root:staff_r:staff_t:s0-s15:c0.c255
type=SOCKADDR msg=audit(1147657744.953:39): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1147657744.953:39): nargs=6 a0=3 a1=bfad69fc a2=10 a3=0 a4=bfad2790 a5=c
]# auditctl -l No rules [ no log activity ]
Why does auditctl report a denial for the 1st attempt, and not for later attempts?
Thanks,
Mike
Quoted 8 lines · Michael C Thompson
Quoted 7 lines · Steve Grubb
Quoted 6 lines · Michael C Thompson
auditctl is still reporting the "error sending rule" problem. Here are my auditctl and kernel versions:
auditctl version 1.2.2
2.6.16-1.2200.2.2_FC6.lspp.25
Quoted 7 lines
Quoted 6 lines
Quoted 2 lines
# auditctl -l Error sending rule list request (Operation not permitted)This is not the error sending rule problem. This looks like a permission problem. What selinux policy and role are you doing this from? Are there any relevant AVCs in the audit logs from this time?
-Steve
I've "enchanced" this transcript with strace output (selective) and the return code of the selinux_socket_recvmsg call.
Quoted 3 lines
This is a transcript from Permissive mode, with role being
staff_r. I do not see the "Error sending rule list request (Operation not permitted)" when SELinux is disabled (selinux=0) or when asauditadm_rat SystemHigh.# auditctl -l
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) = 16poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 100) = 1
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\322\7\0\0\377\377\377\377\20\0"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 -> selinux_sock_recvmsg returns 0
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\322\7\0\0\377\377\377\377\20\0"..., 8476, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 -> selinux_sock_recvmsg returns 0
write(2, "Error sending rule list request "..., 57Error sending rule list request (Operation not permitted)) = 57
Quoted 9 lines
Error sending rule list request (Operation not permitted)
[ resulting log activity:
type=AVC msg=audit(1147657744.953:39): avc: denied {nlmsg_readpriv} for pid=2091 comm="auditctl" scontext=root:staff_r:staff_t:s0-s15:c0.c255 tcontext=root:staff_r:staff_t:s0-s15:c0.c255 tclass=netlink_audit_socket
type=SYSCALL msg=audit(1147657744.953:39): arch=40000003 syscall=102 success=yes exit=16 a0=b a1=bfad2760 a2=805b0f8 a3=10 items=0 ppid=2067 pid=2091 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="auditctl" exe="/sbin/auditctl" subj=root:staff_r:staff_t:s0-s15:c0.c255 type=SOCKADDR msg=audit(1147657744.953:39): saddr=100000000000000000000000
type=SOCKETCALL msg=audit(1147657744.953:39): nargs=6 a0=3 a1=bfad69fc a2=10 a3=0 a4=bfad2790 a5=c
]# auditctl -l
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\326\7\0\0\0\0\0\0\20\0\0\0\365"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 -> selinux_sock_recvmsg returns 0
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\326\7\0\0\0\0\0\0\20\0\0\0\365"..., 8476, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36 -> selinux_sock_recvmsg returns 0
select(4, [3], NULL, NULL, {0, 100000}) = 1 (in [3], left {0, 100000})
recvfrom(3, "\20\0\0\0\3\0\2\0\1\0\0\0\326\7\0\0", 8476, MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 16 -> selinux_sock_recvmsg returns 0
Quoted 2 lines
No rules
[ no log activity ]
I do not know enough of about the auditctl code, but to me this looks like auditctl is failing to issue the 3rd recvfrom syscall.
As a side note, auditctl is somehow executable by staff_t, but staff_t can send to the netlink socket (although staff_t can estabish one).
Thanks,
Mike
Quoted 13 lines · Michael C Thompson
I've "enchanced" this transcript with strace output (selective) and the return code of the
selinux_socket_recvmsgcall.Quoted 1 line
# auditctl -lsendto(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\322\7\0\0\377\377\377\377\20\0"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
->selinux_sock_recvmsgreturns 0
Quoted 4 lines
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\322\7\0\0\377\377\377\377\20\0"..., 8476,
MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
->selinux_sock_recvmsgreturns 0
This return code says -EPERM.
Quoted 10 lines
Quoted 1 line
# auditctl -lsendto(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)= 1recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\326\7\0\0\0\0\0\0\20\0\0\0\365"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
->selinux_sock_recvmsgreturns 0
This return code shows the kernel has data.
Quoted 2 lines
I do not know enough of about the auditctl code, but to me this looks like auditctl is failing to issue the 3rd recvfrom syscall.
When it gets the answer, EPERM, there's no need to do anything else cause the kernel rejected the request.
-Steve
Quoted 13 lines · Steve Grubb
Quoted 12 lines · Michael C Thompson
I've "enchanced" this transcript with strace output (selective) and the return code of the
selinux_socket_recvmsgcall.Quoted 1 line
# auditctl -lsendto(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\322\7\0\0\377\377\377\377\20\0"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
->selinux_sock_recvmsgreturns 0
Quoted 6 lines
Quoted 4 lines
recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\322\7\0\0\377\377\377\377\20\0"..., 8476,
MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
->selinux_sock_recvmsgreturns 0This return code says
-EPERM.
I'm sorry, but I've not spent enough time playing with sockets, how do you determine the return code as -EPERM from the above output...
Quoted 11 lines
Quoted 9 lines
Quoted 1 line
# auditctl -lsendto(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)= 1recvfrom(3, "$\0\0\0\2\0\0\0\1\0\0\0\326\7\0\0\0\0\0\0\20\0\0\0\365"..., 8476, MSG_PEEK|MSG_DONTWAIT, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 36
->selinux_sock_recvmsgreturns 0This return code shows the kernel has data.
and that this section has data? I'm just curious :)
Thanks,
Mike
Quoted 2 lines · Michael C Thompson
I'm sorry, but I've not spent enough time playing with sockets, how do you determine the return code as
-EPERMfrom the above output...
You have to look at the audit_reply data structure, which pulls in nlmsghdr (see /usr/include/linux/netlink.h)
Quoted 1 line
Quoted 1 line
Quoted 1 line
recvfrom(3, "$\0\0\0
1st 4 bytes is length
Quoted 1 line
Quoted 1 line
Quoted 1 line
\2\0
next 2 is message type. In this case, NLMSG_ERROR
Quoted 1 line
Quoted 1 line
Quoted 1 line
\0\0
flags
Quoted 1 line
Quoted 1 line
Quoted 1 line
\1\0\0\0
Seq num
Quoted 1 line
Quoted 1 line
Quoted 1 line
\322\7\0\0
pid
Quoted 1 line
Quoted 1 line
Quoted 1 line
\377\377\377\377
This is return code for NLMSG_ERROR packets. It equals -1.
-Steve
Quoted 7 lines · Michael C Thompson
Quoted 7 lines
[ resulting log activity:
type=AVC msg=audit(1147657744.953:39): avc: denied {nlmsg_readpriv} for pid=2091 comm="auditctl" scontext=root:staff_r:staff_t:s0-s15:c0.c255 tcontext=root:staff_r:staff_t:s0-s15:c0.c255 tclass=netlink_audit_socket type=SYSCALL msg=audit(1147657744.953:39): arch=40000003 syscall=102 success=yes exit=16 a0=b a1=bfad2760 a2=805b0f8 a3=10 items=0 ppid=2067
Quoted 8 lines
Quoted 8 lines
pid=2091 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="auditctl" exe="/sbin/auditctl" subj=root:staff_r:staff_t:s0-s15:c0.c255
type=SOCKADDR msg=audit(1147657744.953:39):
saddr=100000000000000000000000 type=SOCKETCALL msg=audit(1147657744.953:39): nargs=6 a0=3 a1=bfad69fc a2=10 a3=0 a4=bfad2790 a5=c
]
I missed this. This is the smoking gun...why did SE Linux reject the syscall? Next time, SE Linux was OK and allowed access. I wonder if this points to an avc caching problem since subsequent attempts is just fine.
-Steve
Quoted 19 lines · Steve Grubb
Quoted 7 lines · Michael C Thompson
Quoted 7 lines
[ resulting log activity:
type=AVC msg=audit(1147657744.953:39): avc: denied {nlmsg_readpriv} for pid=2091 comm="auditctl" scontext=root:staff_r:staff_t:s0-s15:c0.c255 tcontext=root:staff_r:staff_t:s0-s15:c0.c255 tclass=netlink_audit_socket type=SYSCALL msg=audit(1147657744.953:39): arch=40000003 syscall=102 success=yes exit=16 a0=b a1=bfad2760 a2=805b0f8 a3=10 items=0 ppid=2067Quoted 8 lines
Quoted 8 lines
pid=2091 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 comm="auditctl" exe="/sbin/auditctl" subj=root:staff_r:staff_t:s0-s15:c0.c255
type=SOCKADDR msg=audit(1147657744.953:39):
saddr=100000000000000000000000 type=SOCKETCALL msg=audit(1147657744.953:39): nargs=6 a0=3 a1=bfad69fc a2=10 a3=0 a4=bfad2790 a5=c
]
Quoted 3 lines
I missed this. This is the smoking gun...why did SE Linux reject the syscall? Next time, SE Linux was OK and allowed access. I wonder if this points to an avc caching problem since subsequent attempts is just fine.
His transcript was when running in permissive mode so won't you only get the avc deny once?
-- ljk
Quoted 7 lines
-Steve
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 2 lines · Linda Knippers
His transcript was when running in permissive mode so won't you only get the avc deny once?
If its in permissive, you shouldn't get any failure that results in EPERM from SE Linux. But on second look, this AVC has a success=yes, so maybe not the smoking gun. If there was a corresponding AVC with success=no, then that would be notable.
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.
-Steve
Quoted 9 lines · Steve Grubb
Quoted 2 lines · Linda Knippers
His transcript was when running in permissive mode so won't you only get the avc deny once?
If its in permissive, you shouldn't get any failure that results in EPERM from SE Linux. But on second look, this AVC has a success=yes, so maybe not the smoking gun. If there was a corresponding AVC with success=no, then that would be notable.
AFAICT, there are 2 places where an access decision is made,
audit_netlink_okinkernel/audit.c. And the other place isselinux_nlmsg_lookupinsecurity/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.-Steve
Interesting factoid here for you Steve:
I just compiled auditctl from scratch, and the newly compiled binary got the "Error sending rule list request" thing, even though I had been using the /sbin/auditctl -l functionality for a long while prior.
Does this mean anything to you? or at least help narrow the search? Mike
Quoted 2 lines · Michael C Thompson
I just compiled auditctl from scratch, and the newly compiled binary got the "Error sending rule list request" thing
There are many possibilities for errors. Was it the same EPERM? The part that in parenthesis is the interpreted errno.
Quoted 1 line
Does this mean anything to you? or at least help narrow the search?
Don't know what to make of it. Based on the strace you sent to the mail list earlier...the problem is in the kernel.
-Steve
Quoted 4 lines · Steve Grubb
Quoted 2 lines · Michael C Thompson
I just compiled auditctl from scratch, and the newly compiled binary got the "Error sending rule list request" thing
Quoted 8 lines
There are many possibilities for errors. Was it the same EPERM? The part that
in parenthesis is the interpreted errno.
Quoted 1 line
Does this mean anything to you? or at least help narrow the search?
Don't know what to make of it. Based on the strace you sent to the mail list earlier...the problem is in the kernel.
One has to wonder if the audit.h used in userspace corresponds to the kernel's view of the world. Is that being picked up from a private .h in the audit RPM, or is it getting it from the version in glibc-kernheaders RPM? If the latter, and there's an API change, we'll be dependent on the version of glibc-kernheaders present at RPM build/compile time....
Quoted 5 lines · On Tuesday 16 May 2006 18:31, [email protected] wrote:
One has to wonder if the
audit.hused in userspace corresponds to the kernel's view of the world. Is that being picked up from a private .h in the audit RPM, or is it getting it from the version in glibc-kernheaders RPM? If the latter, and there's an API change, we'll be dependent on the version of glibc-kernheaders present at RPM build/compile time....
Simple answer...I carry any ABI changes in libaudit.h whenever they are not in glibc-kernheaders.
-Steve
Quoted 5 lines · Steve Grubb
AFAICT, there are 2 places where an access decision is made,
audit_netlink_okinkernel/audit.c. And the other place isselinux_nlmsg_lookupinsecurity/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)?
-Steve
Is it possible to make auditd compilable to vanilla kernel 2.6.12? That makes auditd easier to use.
Xin
Quoted 19 lines · Steve Grubb
Quoted 5 lines · Steve Grubb
AFAICT, there are 2 places where an access decision is made,
audit_netlink_okinkernel/audit.c. And the other place isselinux_nlmsg_lookupinsecurity/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)?
-Steve
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 2 lines · Xin Zhao
Is it possible to make auditd compilable to vanilla kernel 2.6.12? That makes auditd easier to use.
You should be able to use audit-1.0.14 with that kernel. The only issue you may run into is kernel headers for linux/audit.h. But it should work.
Auditing was not really stable, though, until the 2.6.14 kernel.
-Steve
I tried 1.0.14. It compiles without any problem. But after I ran "./auditd", I got the following error messages in /var/log/messages:
--------- ERROR MSGS -----------------------------------
May 22 15:35:03 shanghai auditd[16985]: Error sending failure mode request (Connection refused) May 22 15:35:03 shanghai auditd[16985]: Unable to set audit pid, exiting May 22 15:35:03 shanghai auditd[16985]: The audit daemon is exiting. May 22 15:35:03 shanghai auditd[16985]: Error sending failure mode request (Connection refused) May 22 15:35:03 shanghai auditd: Cannot daemonize (No child processes) May 22 15:35:03 shanghai auditd: The audit daemon is exiting.
What's wrong with it? I am using FC4, but the kernel is 2.6.12 with xen support.
Thanks in advance!
Xin
Quoted 11 lines · Steve Grubb
Quoted 2 lines · Xin Zhao
Is it possible to make auditd compilable to vanilla kernel 2.6.12? That makes auditd easier to use.
You should be able to use audit-1.0.14 with that kernel. The only issue you may run into is kernel headers for
linux/audit.h. But it should work.Auditing was not really stable, though, until the 2.6.14 kernel.
-Steve
Quoted 1 line · Xin Zhao
What's wrong with it?
This seems to indicate a permission problem. Do you have SE Linux running?
-Steve
No. SE Linux has been disabled. I am trying to use your tool to do microbenchmark. It's very urgent. Please help!
Xin
Quoted 7 lines · Steve Grubb
Quoted 1 line · Xin Zhao
What's wrong with it?
This seems to indicate a permission problem. Do you have SE Linux running?
-Steve
Quoted 15 lines · Xin Zhao
I tried 1.0.14. It compiles without any problem. But after I ran "./auditd", I got the following error messages in
/var/log/messages:--------- ERROR MSGS -----------------------------------
May 22 15:35:03 shanghai auditd[16985]: Error sending failure mode request (Connection refused) May 22 15:35:03 shanghai auditd[16985]: Unable to set audit pid, exiting May 22 15:35:03 shanghai auditd[16985]: The audit daemon is exiting. May 22 15:35:03 shanghai auditd[16985]: Error sending failure mode request (Connection refused) May 22 15:35:03 shanghai auditd: Cannot daemonize (No child processes) May 22 15:35:03 shanghai auditd: The audit daemon is exiting.
Quoted 2 lines
What's wrong with it? I am using FC4, but the kernel is 2.6.12 with xen support.
Have you built your kernel with CONFIG_AUDIT?
Quoted 3 lines
Thanks in advance!
Xin
Thanks for your help! You are right. This is the problem. I am using xeno Linux 2.6.12 without enabling AUDIT when compiling the kernel. After I did that and recompile the kernel, it works for me. Really appreciated for your help!
Now I have to move to next question: can auditd record how much time each system call uses. I am developing a file system and might want to monitor all file system related system call to find the performance bottleneck in my system.
Again, thanks a lot for kind help!
Xin
Quoted 25 lines · Amy Griffis
Quoted 15 lines · Xin Zhao
I tried 1.0.14. It compiles without any problem. But after I ran "./auditd", I got the following error messages in
/var/log/messages:--------- ERROR MSGS -----------------------------------
May 22 15:35:03 shanghai auditd[16985]: Error sending failure mode request (Connection refused) May 22 15:35:03 shanghai auditd[16985]: Unable to set audit pid, exiting May 22 15:35:03 shanghai auditd[16985]: The audit daemon is exiting. May 22 15:35:03 shanghai auditd[16985]: Error sending failure mode request (Connection refused) May 22 15:35:03 shanghai auditd: Cannot daemonize (No child processes) May 22 15:35:03 shanghai auditd: The audit daemon is exiting.Quoted 2 lines
What's wrong with it? I am using FC4, but the kernel is 2.6.12 with xen support.
Have you built your kernel with
CONFIG_AUDIT?Quoted 3 lines
Thanks in advance!
Xin
Quoted 2 lines · Xin Zhao
Now I have to move to next question: can auditd record how much time each system call uses.
No. Its view of the world is very much like strace's. I think for that you are better off looking at system-tap or oprofile:
http://sources.redhat.com/systemtap/documentation.html
Quoted 2 lines
I am developing a file system and might want to monitor all file system related system call to find the performance bottleneck in my system.
I have a feeling that system tap may be a better fit for your project. You can certainly monitor all files or extend the audit system to give you time hacks via an auxiliary record, but that was never its intended use.
Also look at oprofile:
http://oprofile.sourceforge.net/about/
-Steve
Quoted 10 lines · Steve Grubb
Quoted 5 lines · Steve Grubb
AFAICT, there are 2 places where an access decision is made,
audit_netlink_okinkernel/audit.c. And the other place isselinux_nlmsg_lookupinsecurity/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.
Mike
Quoted 8 lines · Michael C Thompson
Quoted 7 lines · Steve Grubb
Quoted 5 lines · Steve Grubb
AFAICT, there are 2 places where an access decision is made,
audit_netlink_okinkernel/audit.c. And the other place isselinux_nlmsg_lookupinsecurity/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.
Quoted 5 lines
Quoted 3 lines
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
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
Quoted 44 lines · Michael C Thompson
Quoted 13 lines · Michael C Thompson
Quoted 11 lines · Steve Grubb
Quoted 7 lines · Steve Grubb
AFAICT, there are 2 places where an access decision is made,
audit_netlink_okinkernel/audit.c. And the other place isselinux_nlmsg_lookupinsecurity/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.Quoted 8 lines
Quoted 4 lines
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_replystructure to fully understand what is happening. This is what I know:
socket_has_permreturns 0, andnetlink_recvmsgdoes 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,
MikeSignature · 3 lines
Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
Quoted 5 lines · Linda Knippers
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.
I've been running mostly on an i686 (Intel) with the .27 kernel and 1.2.2 tools with the MLS policy. I've tested this on an x86_64 (AMD opteron) and see this problem too. However, this problem does NOT exist when using targeted policy, so it is most likely an MLS SELinux issue. My MLS policy is 2.2.42
Quoted 2 lines
Can you describe more about your configuration and provide exact steps to reproduce the problem?
1) Reboot your system (so you've a clean slate)
2) Login (tty or pty, doesn't matter, I've done both)
3) auditctl -l
Error sending rule list request (Operation not permitted)
4) auditctl -l
No rules (or whatever you expect to see)
Quoted 3 lines
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.
Loulwa sees this problem (I used her x86_64 machine above) and I have just seen this problem on George's machine (he was originally not using the MLS policy).
Therefore, this evidence leads me to believe its an issue in the MLS policy, although I do not what the problem is.
Thanks,
Mike
Quoted 7 lines · Michael C Thompson
Quoted 5 lines · Linda Knippers
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.
Quoted 5 lines
I've been running mostly on an i686 (Intel) with the .27 kernel and 1.2.2 tools with the MLS policy. I've tested this on an
x86_64(AMD opteron) and see this problem too. However, this problem does NOT exist when using targeted policy, so it is most likely an MLS SELinux issue. My MLS policy is 2.2.42
I've recently hit the same issue (or one that looks just like it[1]) on
current FC-5 with targeted policy in permissive mode.
[1] Program calls audit_log_user_message() at boot time, and gets -1 (EPERM) ... if you put a "for (int i = 1; i < 1; ++i)" in front of it, it returns 0.
Signature · 1 line
James Antill <[email protected]>
Quoted 10 lines · James Antill
Quoted 8 lines · Michael C Thompson
Quoted 5 lines · Linda Knippers
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.I've been running mostly on an i686 (Intel) with the .27 kernel and 1.2.2 tools with the MLS policy. I've tested this on an
x86_64(AMD opteron) and see this problem too. However, this problem does NOT exist when using targeted policy, so it is most likely an MLS SELinux issue. My MLS policy is 2.2.42
Quoted 6 lines
I've recently hit the same issue (or one that looks just like it[1]) on
current FC-5 with targeted policy in permissive mode.[1] Program calls
audit_log_user_message()at boot time, and gets -1 (EPERM) ... if you put a "for (int i = 1; i < 1; ++i)" in front of it, it returns 0.
Do you mean to say that embedded audit_log_user_message() inside a loop changes it's return code? int i;
for (i=1;i<1;i++) {
audit_log_user_message();
}Is that code sample correct?
Mike
Quoted 2 lines · Michael C Thompson
Do you mean to say that embedded
audit_log_user_message()inside a loop changes it's return code?
Sorry, my explanation probably wasn't clear.
It changes from the first to the second invocation, the first is always
-1 the second is always 0 (on boot, only, after boot the first succeeds as well).
int i;
for (i=0; i<2; i++) {
rc = audit_log_user_message();
}Quoted 1 line
Is that code sample correct?
It is now, yes.
Signature · 1 line
James Antill - <[email protected]>
Quoted 1 line
* What is the penalty for using RHEL without paying?
We subscribe them to memo-list. -- Bill Nottingham
Quoted 8 lines · James Antill
Quoted 1 line · Michael C Thompson
Do you mean to say that embedded
audit_log_user_message()inside a loop changes it's return code?Sorry, my explanation probably wasn't clear.
It changes from the first to the second invocation, the first is always
-1 the second is always 0 (on boot, only, after boot the first succeeds as well).
This is interesting, that does seem like we're being denied for the first attempt of actions against the kernel... you said you've seen this in the targeted policy? (I've only seen this problem with the MLS policy)
Mike
Quoted 3 lines · Michael C Thompson
This is interesting, that does seem like we're being denied for the first attempt of actions against the kernel... you said you've seen this in the targeted policy? (I've only seen this problem with the MLS policy)
Yes, it's a mostly vanilla FC5 box using targeted policy (and still
happens when configured in permissive mode).
Signature · 1 line
James Antill - <[email protected]>
Quoted 1 line
* What is the penalty for using RHEL without paying?
We subscribe them to memo-list. -- Bill Nottingham
Quoted 1 line · Michael C Thompson
socket_has_permreturns 0,
This function is not exactly the one I was after..
3387 static int selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb) 3388 {
<snip>
3401 err = selinux_nlmsg_lookup(isec->sclass, nlh->nlmsg_type, &perm);
3402 if (err) {
<snip>
3415 goto out;
3416 }
3417
3418 err = socket_has_perm(current, sock, perm);
3419 out:
3420 return err;
3421 }
Socket_has_perm has the second vote. This function in turn gets called by selinux_netlink_send, so that is probably the best place to hook.
Quoted 2 lines
If you have any possible fixes, I'll gladly test them, but currently, I'm at a loss for time and can't continue.
I guess I'll put the hooks in the next kernel and let you test them.
-Steve
Quoted 18 lines · Steve Grubb
Quoted 1 line · Michael C Thompson
socket_has_permreturns 0,This function is not exactly the one I was after..
3387 static int
selinux_nlmsg_perm(struct sock *sk, struct sk_buff *skb)3388 {
<snip>
3401 err =selinux_nlmsg_lookup(isec->sclass, nlh->nlmsg_type, &perm);
3402 if (err) {
<snip>
3415 goto out;
3416 }
3417 3418 err =socket_has_perm(current, sock, perm);
3419 out:
3420 return err;
3421 }
Quoted 1 line
Socket_has_permhas the second vote. This function in turn gets called byselinux_netlink_send, so that is probably the best place to hook.
I do not see this function getting hit with 'auditctl -l'.
Quoted 4 lines
Quoted 2 lines
If you have any possible fixes, I'll gladly test them, but currently, I'm at a loss for time and can't continue.
I guess I'll put the hooks in the next kernel and let you test them.
Send 'em my way :)
Thanks,
Mike
Quoted 13 lines · Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit It will also be in rawhide tomorrow. The Changelog is:
- Updates for new glibc-kernheaders
- Change auditctl to collect list of rules then delete them on -D
- Update capp.rules and lspp.rules to comment out rules for the possible list
- Add new message types
- Support sigusr1 sender identity of newer kernels
- Add support for ppid in auditctl and ausearch
- fix auditctl to trim the '/' from watches
- Move audit daemon config files to/etc/auditfor better SE Linux protection
Quoted 7 lines
Beware ! This release has 2 changes to notice. It requires newer glibc-kernheaders and it moves the audit configuration files to the
/etc/auditdirectory. The specfile should handle the transition gracefully.This release also supports new options in our current development kernels. It adds support for filtering by ppid and searching for ppid in the logs. It supports getting the signal info for senders of sigusr1. And completes the fix for listing or deleting large amounts of syscall rules. Watches that have a trailing '/' will now have it trimmed to make the kernel happier.
2 new message types were added
AUDIT_DEV_ALLOCandAUDIT_DEV_DEALLOCfor LSPP work. The capp & lspp rules were updated to not have "possible" as the list action.Please let me know if there are any problems with this release.
With the current version of audit, auditctl -l only prints an equal, not equal operator when it displays rules, while the rules in the kernel are operating correctly, this is most an inconvenience, since is not possible to tell what rules are really in the kernel.
The problem lies in the audit_print_reply logic not detecting the type of the message (either AUDIT_LIST or AUDIT_LIST_RULE).
Below is a patch which adds this detection.
Thanks,
Mike
----
src/auditctl.c +8 -2
@@ -926,8 +926,14 @@ static int audit_print_reply(struct audifor (i =0 ; i < rep->rule->field_count; i++) {int field = rep->rule->fields[i] & ~AUDIT_OPERATORS & ~AUDIT_NEGATE ; -int op = rep->rule->fields[i] & - (AUDIT_OPERATORS |AUDIT_NEGATE ); +int op; +if (rep->type ==AUDIT_LIST_RULES ) { + op = rep->ruledata->fieldflags[i] & + (AUDIT_OPERATORS |AUDIT_NEGATE ); + }else { + op = rep->rule->fields[i] & + (AUDIT_OPERATORS |AUDIT_NEGATE ); + }const char *name =audit_field_to_name (field);if (name) {
Quoted 11 lines · Michael C Thompson
Quoted 1 line · Steve Grubb
Please let me know if there are any problems with this release.
With the current version of audit, auditctl -l only prints an equal, not equal operator when it displays rules, while the rules in the kernel are operating correctly, this is most an inconvenience, since is not possible to tell what rules are really in the kernel.
The problem lies in the
audit_print_replylogic not detecting the type of the message (eitherAUDIT_LISTorAUDIT_LIST_RULE).Below is a patch which adds this detection.
Thanks,
Mike
Below is some testing between the original code and the patched code.
# auditctl -a entry,always -S chmod -F 'uid=100' # auditctl -a entry,always -S chmod -F 'uid>200' # auditctl -a entry,always -S chmod -F 'uid>=300' # auditctl -a entry,always -S chmod -F 'uid!=400' # auditctl -a entry,always -S chmod -F 'uid<500' # auditctl -a entry,always -S chmod -F 'uid<=600'
# auditctl -l [ audit-1.2.2 auditctl pre-patch] LIST_RULES: entry,always uid=100 (0x64) syscall=chmod LIST_RULES: entry,always uid=200 (0xc8) syscall=chmod LIST_RULES: entry,always uid=300 (0x12c) syscall=chmod LIST_RULES: entry,always uid=400 (0x190) syscall=chmod LIST_RULES: entry,always uid=500 (0x1f4) syscall=chmod LIST_RULES: entry,always uid=600 (0x258) syscall=chmod
# auditctl -l [ audit-1.2.2 auditctl post-patch ] LIST_RULES: entry,always uid=100 (0x64) syscall=chmod LIST_RULES: entry,always uid>200 (0xc8) syscall=chmod LIST_RULES: entry,always uid>=300 (0x12c) syscall=chmod LIST_RULES: entry,always uid!=400 (0x190) syscall=chmod LIST_RULES: entry,always uid<500 (0x1f4) syscall=chmod LIST_RULES: entry,always uid<=600 (0x258) syscall=chmod
Thanks,
Mike
Quoted 13 lines · Steve Grubb
Hi,
I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit It will also be in rawhide tomorrow. The Changelog is:
- Updates for new glibc-kernheaders
- Change auditctl to collect list of rules then delete them on -D
- Update capp.rules and lspp.rules to comment out rules for the possible list
- Add new message types
- Support sigusr1 sender identity of newer kernels
- Add support for ppid in auditctl and ausearch
- fix auditctl to trim the '/' from watches
- Move audit daemon config files to/etc/auditfor better SE Linux protection
Quoted 7 lines
Beware ! This release has 2 changes to notice. It requires newer glibc-kernheaders and it moves the audit configuration files to the
/etc/auditdirectory. The specfile should handle the transition gracefully.This release also supports new options in our current development kernels. It adds support for filtering by ppid and searching for ppid in the logs. It supports getting the signal info for senders of sigusr1. And completes the fix for listing or deleting large amounts of syscall rules. Watches that have a trailing '/' will now have it trimmed to make the kernel happier.
2 new message types were added
AUDIT_DEV_ALLOCandAUDIT_DEV_DEALLOCfor LSPP work. The capp & lspp rules were updated to not have "possible" as the list action.Please let me know if there are any problems with this release.
auditctl -a entry,always -S chmod -F "watch=/root/file"
This fails... how is one supposed to use the new 'watch' field filter?
Mike
Quoted 5 lines · Michael C Thompson
Quoted 1 line
Please let me know if there are any problems with this release.
auditctl -a entry,always -S chmod -F "watch=/root/file"
This fails... how is one supposed to use the new 'watch' field filter?
This was already reported on SE Linux mail list last week. The short answer is that policy needs to be adjusted to make this work. I don't know if the changes have been rolled out yet. Just as a test, try "setenforce 0" and then load the audit rule.
-Steve
Quoted 7 lines · Steve Grubb
Quoted 4 lines · Michael C Thompson
Quoted 1 line
Please let me know if there are any problems with this release.
auditctl -a entry,always -S chmod -F "watch=/root/file"
This fails... how is one supposed to use the new 'watch' field filter?
This was already reported on SE Linux mail list last week. The short answer is that policy needs to be adjusted to make this work. I don't know if the changes have been rolled out yet. Just as a test, try "setenforce 0" and then load the audit rule.
The above command was tried in permissive mode. The resulting error is:
# auditctl -a entry,always -S chmod -F "watch=/root/file" -F unknown field: watch=/root/file
Thanks,
Mike
Quoted 2 lines · Michael C Thompson
# auditctl -a entry,always -S chmod -F "watch=/root/file" -F unknown field: watch=/root/file
Ok, I misread what you were reporting...sorry.
It is like this:
auditctl -a exit,always -S chmod -F path=/root/file
Must be exit list and use path not watch.
-Steve