audit 1.2.2 released

audit 1.2.2 released

[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/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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Linda Knippers]

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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 922 bytes --]

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....

[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

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

Re: audit 1.2.2 released

[Steve Grubb]

On Tuesday 16 May 2006 18:31, Valdis.Kletnieks@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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Xin Zhao]

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@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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[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.


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@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
>

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Xin Zhao]

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@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
>

Re: audit 1.2.2 released

[Amy Griffis]

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

Re: audit 1.2.2 released

[Xin Zhao]

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@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
>

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[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.

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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 1037 bytes --]

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@redhat.com>

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 658 bytes --]

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@redhat.com>
> * What is the penalty for using RHEL without paying?
We subscribe them to memo-list. -- Bill Nottingham

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[James Antill]

[-- Attachment #1.1: Type: text/plain, Size: 565 bytes --]

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@redhat.com>
> * What is the penalty for using RHEL without paying?
We subscribe them to memo-list. -- Bill Nottingham

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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@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) {

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

Re: audit 1.2.2 released

[Michael C Thompson]

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

Re: audit 1.2.2 released

[Steve Grubb]

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

RE: audit 1.2.2 released

[Chad Hanson]

Comments below...

> 
> 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)

Are you running enforcing or permissive?

I only see this behavior on the LSPP kernels (including 28) after
transitioning to permissive mode, but not on the FC5 2.6.15 2054 kernel
running MLS with the same procedures.

Also, I don't see this behavior the same way. I can reboot, login, newrole
to auditadm_r and run auditctl -l correctly everytime.

The problem behavior I see is as follows below 

1) newrole to secadm_r
2) auditctl -l -- denied as expected. 
3) setenforce 0
4) auditctl -l -- denied (WRONG)
5) auditctl -l -- works correctly (can repeat as many times as desired)
6) setenforce 1 -- everything is back to normal

repeat from #3 to see problems again

-Chad

Re: audit 1.2.2 released

[Darrel Goeddel]

Chad Hanson wrote:
> Comments below...
> 
> 
>>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)
> 
> 
> Are you running enforcing or permissive?
> 
> I only see this behavior on the LSPP kernels (including 28) after
> transitioning to permissive mode, but not on the FC5 2.6.15 2054 kernel
> running MLS with the same procedures.
> 
> Also, I don't see this behavior the same way. I can reboot, login, newrole
> to auditadm_r and run auditctl -l correctly everytime.
> 
> The problem behavior I see is as follows below 
> 
> 1) newrole to secadm_r
> 2) auditctl -l -- denied as expected. 
> 3) setenforce 0
> 4) auditctl -l -- denied (WRONG)
> 5) auditctl -l -- works correctly (can repeat as many times as desired)
> 6) setenforce 1 -- everything is back to normal
> 
> repeat from #3 to see problems again

I can reproduce Chad's behavior on an up-to-date rawhide box (currently using
kernel 2.6.16-1.2218_FC6).  If I then boot to the latest published FC5 kernel
(2.6.16-1.2122_FC5) on that machine, I do not see the problem.  So...  I'll
see if I can spot any changes between the two source trees that would cause
the problem.  I'll also try building the working FC5 kernel with the rawhide
toolchain, and possibly building the FC6 kernel with a reduced set of patches
if it comes down to that.  Does this information spark any other ideas?

-- 

Darrel