2:53 a.m.
Contains Tim's #7U5' patch, Steve's patches for message types and
cleaing up untrusted string logging.
Still doesn't have error handling for the netlink_unicast() call in
audit_send_reply(). Every time I look at that I just cannot bring myself
to add the 'skb_get(); /* netlink frees */' which prefixes the
netlink_unicast() elsewhere. That just looks _wrong_ to me -- there has
to be something wrong with the refcounting.
--
dwmw2
10:02 a.m.
I am still seeing some problems with missing watch records ... here is
one scenario:
auditctl -w /tmp/file -k test-key (watch insert record generated)
touch /tmp/file (watch record generated )
echo "testing" > /tmp/file1 (NO record)
rm /tmp/file1 (NO record & kernel hangs)
It looks like the system hangs every time I attempt to remove a watched
file.
- Loulwa
10:27 a.m.
On Monday 16 May 2005 11:02, Loulwa Salem wrote:
I am still seeing some problems with missing watch records
Me, too. Using the i686 .36 kernel:
[root@endeavor ~]# /etc/rc.d/init.d/auditd stop
Stopping auditd: [ OK ]
[root@endeavor ~]# rm -f /var/log/audit/audit.log
[root@endeavor ~]# /etc/rc.d/init.d/auditd start
Starting auditd: [ OK ]
[root@endeavor ~]# auditctl -l
No rules
No watches
[root@endeavor ~]# auditctl -w /etc/passwd -k fk_passwd -p rwea
No rules
AUDIT_WATCH_LIST: dev=3:2, path=/etc/passwd, filterkey=fk_passwd, perms=15,
valid=0
[root@endeavor ~]# cat /etc/passwd >/dev/null
[root@endeavor ~]# tail /var/log/audit/audit.log
type=DAEMON_START msg=audit(1116256955.597:932) auditd start, ver=0.8.1,
format=raw, uid=4325, auditd pid=2751
type=CONFIG_CHANGE msg=audit(1116256955.810:0): audit_enabled=1 old=1 by auid
4325
type=CONFIG_CHANGE msg=audit(1116256956.013:0): audit_backlog_limit=1024
old=1024 by auid 4325
type=CONFIG_CHANGE msg=audit(1116256965.066:0): auid 4325 inserted watch
[root@endeavor ~]# auditctl -W /etc/passwd -k fk_passwd -p rwea
No rules
No watches
10:36 a.m.
On Monday 16 May 2005 10:27, Steve Grubb wrote:
On Monday 16 May 2005 11:02, Loulwa Salem wrote:
> I am still seeing some problems with missing watch records
Me, too. Using the i686 .36 kernel:
[root@endeavor ~]# /etc/rc.d/init.d/auditd stop
Stopping auditd: [ OK ]
[root@endeavor ~]# rm -f /var/log/audit/audit.log
[root@endeavor ~]# /etc/rc.d/init.d/auditd start
Starting auditd: [ OK ]
[root@endeavor ~]# auditctl -l
No rules
No watches
[root@endeavor ~]# auditctl -w /etc/passwd -k fk_passwd -p rwea
No rules
AUDIT_WATCH_LIST: dev=3:2, path=/etc/passwd, filterkey=fk_passwd, perms=15,
valid=0
[root@endeavor ~]# cat /etc/passwd >/dev/null
[root@endeavor ~]# tail /var/log/audit/audit.log
type=DAEMON_START msg=audit(1116256955.597:932) auditd start, ver=0.8.1,
format=raw, uid=4325, auditd pid=2751
type=CONFIG_CHANGE msg=audit(1116256955.810:0): audit_enabled=1 old=1 by
auid 4325
type=CONFIG_CHANGE msg=audit(1116256956.013:0): audit_backlog_limit=1024
old=1024 by auid 4325
type=CONFIG_CHANGE msg=audit(1116256965.066:0): auid 4325 inserted watch
[root@endeavor ~]# auditctl -W /etc/passwd -k fk_passwd -p rwea
No rules
No watches
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
interesting... i'm not seeing these problems (not at least, with the latest
update patch I replied to the #7U5 thread with)... let me look into it deeper
-tim
5:41 p.m.
On Mon, 2005-05-16 at 10:36 -0500, Timothy R. Chavez wrote:
interesting... i'm not seeing these problems (not at least, with
the latest
update patch I replied to the #7U5 thread with)... let me look into it deeper
Please make sure you're testing on the current RPM kernel -- nothing
else. However, you can ignore audit.38; it had the auditfs patch
disabled because I suspected it of causing memory corruption. As it
happens, it was merely the victim of memory corruption which persists
for me even when I revert to about what was in audit.36. I'm still
debugging it, but the currently lack of responsiveness of my test box
seems to be hinting that it's time to call it a night...
audit.37 in the yum repo has a first attempt to log sys_socketcall()
arguments and any sockaddr which is passed as a syscall argument. (And
no, if I fix the obvious bug in that first version, it doesn't fix my
memory corruption).
--
dwmw2
5:55 a.m.
New subject: Socketcall / sockaddr logging.
On Mon, 2005-05-16 at 23:41 +0100, David Woodhouse wrote:
audit.37 in the yum repo has a first attempt to log sys_socketcall()
arguments and any sockaddr which is passed as a syscall argument. (And
no, if I fix the obvious bug in that first version, it doesn't fix my
memory corruption).
I've tracked down the memory corruption -- it was introduced by my
socketcall patch, and should now be fixed in the attached version.
The patch logs the arguments to the sys_socketcall() system call, and
also any sockaddr which is copied from userspace as part of a system
call. It gives output along these lines...
audit(1116327000.714:160055): syscall=102 arch=40000003 success=no exit=-101 a0=3
a1=bffeeb20 a2=4 a3=806eb40 items=0 pid=4884 loginuid=-1 uid=0 gid=0 euid=0 suid=0 fsuid=0
egid=0 sgid=0 fsgid=0 comm="ping6" exe="/bin/ping6"
audit(1116327000.714:160055):
saddr=0A00040100000000200108B0010B000102095BFFFE840C9E00000000
audit(1116327000.714:160055): nargs=3 a0=4 a1=bffeebe0 a2=1c
The equivalent strace output is this:
connect(4, {sa_family=AF_INET6, sin6_port=htons(1025), inet_pton(AF_INET6,
"2001:8b0:10b:1:209:5bff:fe84:c9e", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
I'm building audit.39 with it now.
--
dwmw2
12:40 p.m.
* David Woodhouse (dwmw2(a)infradead.org) wrote:
Still doesn't have error handling for the netlink_unicast() call
in
audit_send_reply(). Every time I look at that I just cannot bring myself
to add the 'skb_get(); /* netlink frees */' which prefixes the
netlink_unicast() elsewhere. That just looks _wrong_ to me -- there has
to be something wrong with the refcounting.
Yeah, the problem is we add our own 'reliable transmission' to netlink.
So, the refcounting is fine in that it's telling the netlink layer that
it's not the only layer that cares about the skb (well, and it works).
The retry is presently based on an audit_buffer which is lacking for
audit_send_reply.
thanks,
-chris
7159
days inactive
7162
days old
linux-audit@lists.linux-audit.osci.io
6 comments
5 participants
participants (5)
-
Chris Wright -
David Woodhouse -
Loulwa Salem -
Steve Grubb -
Timothy R. Chavez