4:26 p.m.
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
2:57 p.m.
Steve Grubb wrote:
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.
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
3:04 p.m.
On Monday 15 May 2006 15:57, Michael C Thompson wrote:
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
3:14 p.m.
Steve Grubb wrote:
On Monday 15 May 2006 15:57, Michael C Thompson wrote:
> 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
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
9:53 a.m.
Michael C Thompson wrote:
Steve Grubb wrote:
> On Monday 15 May 2006 15:57, Michael C Thompson wrote:
>> 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
I've "enchanced" this transcript with strace output (selective) and the
return code of the selinux_socket_recvmsg call.
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
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\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
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
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
10:23 a.m.
On Tuesday 16 May 2006 10:53, Michael C Thompson wrote:
I've "enchanced" this transcript with strace output
(selective) and the
return code of the selinux_socket_recvmsg call.
> # 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\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
This return code says -EPERM.
> # 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
This return code shows the kernel has data.
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
11:08 a.m.
Steve Grubb wrote:
On Tuesday 16 May 2006 10:53, Michael C Thompson wrote:
> I've "enchanced" this transcript with strace output (selective) and
the
> return code of the selinux_socket_recvmsg call.
>
>> # 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\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
This 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...
>> # 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
This return code shows the kernel has data.
and that this section has data? I'm just curious :)
Thanks,
Mike
11:28 a.m.
On Tuesday 16 May 2006 12:08, Michael C Thompson wrote:
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...
You have to look at the audit_reply data structure, which pulls in nlmsghdr
(see /usr/include/linux/netlink.h)
>> recvfrom(3, "$\0\0\0
1st 4 bytes is length
>> \2\0
next 2 is message type. In this case, NLMSG_ERROR
>> \0\0
flags
>> \1\0\0\0
Seq num
>> \322\7\0\0
pid
>> \377\377\377\377
This is return code for NLMSG_ERROR packets. It equals -1.
-Steve
10:34 a.m.
On Tuesday 16 May 2006 10:53, Michael C Thompson wrote:
> [ 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
> ]
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
10:53 a.m.
Steve Grubb wrote:
On Tuesday 16 May 2006 10:53, Michael C Thompson wrote:
>>[ 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
>>]
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
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
12:23 p.m.
On Tuesday 16 May 2006 11:53, Linda Knippers wrote:
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
3:38 p.m.
Steve Grubb wrote:
On Tuesday 16 May 2006 11:53, Linda Knippers wrote:
> 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
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
4:49 p.m.
On Tuesday 16 May 2006 16:38, Michael C Thompson wrote:
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.
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
5:31 p.m.
On Tue, 16 May 2006 17:49:48 EDT, Steve Grubb said:
On Tuesday 16 May 2006 16:38, Michael C Thompson wrote:
> 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.
> 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....
5:25 a.m.
On Tuesday 16 May 2006 18:31, Valdis.Kletnieks(a)vt.edu wrote:
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....
Simple answer...I carry any ABI changes in libaudit.h whenever they are not in
glibc-kernheaders.
-Steve
12:31 p.m.
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)?
-Steve
2:15 p.m.
Is it possible to make auditd compilable to vanilla kernel 2.6.12?
That makes auditd easier to use.
Xin
On 5/22/06, Steve Grubb <sgrubb(a)redhat.com> 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)?
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
2:24 p.m.
On Monday 22 May 2006 15:15, Xin Zhao wrote:
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
2:37 p.m.
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
On 5/22/06, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Monday 22 May 2006 15:15, Xin Zhao wrote:
> 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
3:15 p.m.
No. SE Linux has been disabled. I am trying to use your tool to do
microbenchmark. It's very urgent. Please help!
Xin
On 5/22/06, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Monday 22 May 2006 15:37, Xin Zhao wrote:
> What's wrong with it?
This seems to indicate a permission problem. Do you have SE Linux running?
-Steve
1:56 a.m.
On Mon, May 22, 2006 at 03:37:33PM -0400, Xin Zhao wrote:
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.
Have you built your kernel with CONFIG_AUDIT?
Thanks in advance!
Xin
10:43 p.m.
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
On 5/23/06, Amy Griffis <amy.griffis(a)hp.com> wrote:
On Mon, May 22, 2006 at 03:37:33PM -0400, Xin Zhao wrote:
> 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.
Have you built your kernel with CONFIG_AUDIT?
> Thanks in advance!
>
> Xin
10:11 a.m.
On Monday 22 May 2006 23:43, Xin Zhao wrote:
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
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
11:24 a.m.
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.
Mike
5:20 p.m.
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
6:05 p.m.
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
2:44 p.m.
Linda Knippers wrote:
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
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)
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
3:58 p.m.
On Wed, 2006-05-24 at 14:44 -0500, Michael C Thompson wrote:
Linda Knippers wrote:
> 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
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.
--
James Antill <jantill(a)redhat.com>
8:48 a.m.
James Antill wrote:
On Wed, 2006-05-24 at 14:44 -0500, Michael C Thompson wrote:
> Linda Knippers wrote:
>> 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
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
10:16 a.m.
On Thu, 2006-05-25 at 08:48 -0500, Michael C Thompson wrote:
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();
}
Is that code sample correct?
It is now, yes.
--
James Antill - <james.antill(a)redhat.com>
* What is the penalty for using RHEL without paying?
We
subscribe them to memo-list. -- Bill Nottingham
10:22 a.m.
James Antill wrote:
On Thu, 2006-05-25 at 08:48 -0500, Michael C Thompson wrote:
> 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
10:40 a.m.
On Thu, 2006-05-25 at 10:22 -0500, Michael C Thompson wrote:
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).
--
James Antill - <james.antill(a)redhat.com>
* What is the penalty for using RHEL without paying?
We
subscribe them to memo-list. -- Bill Nottingham
8:04 a.m.
On Tuesday 23 May 2006 18:20, Michael C Thompson wrote:
socket_has_perm returns 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.
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
3:30 p.m.
Steve Grubb wrote:
On Tuesday 23 May 2006 18:20, Michael C Thompson wrote:
> socket_has_perm returns 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.
I do not see this function getting hit with 'auditctl -l'.
> 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
10:32 a.m.
Steve Grubb wrote:
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.
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
----
Signed-off-by: Michael Thompson <mcthomps(a)us.ibm.com>
--- audit-1.2.2-orig/src/auditctl.c 2006-05-12 14:59:59.000000000 -0500
+++ audit-1.2.2/src/auditctl.c 2006-05-16 15:56:31.000000000 -0500
@@ -926,8 +926,14 @@ static int audit_print_reply(struct audi
for (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) {
10:45 a.m.
Michael C Thompson wrote:
Steve Grubb wrote:
> 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
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
4:12 p.m.
Steve Grubb wrote:
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.
auditctl -a entry,always -S chmod -F "watch=/root/file"
This fails... how is one supposed to use the new 'watch' field filter?
Mike
4:23 p.m.
On Wednesday 17 May 2006 17:12, Michael C Thompson wrote:
> 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
4:43 p.m.
Steve Grubb wrote:
On Wednesday 17 May 2006 17:12, Michael C Thompson wrote:
>> 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
4:55 p.m.
On Wednesday 17 May 2006 17:43, Michael C Thompson wrote:
# 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
6785
days inactive
6798
days old
linux-audit@lists.linux-audit.osci.io
40 comments
7 participants
participants (7)
-
Amy Griffis -
James Antill -
Linda Knippers -
Michael C Thompson -
Steve Grubb -
Valdis.Kletnieks＠vt.edu -
Xin Zhao