7:29 a.m.
I wonder if it is needed to audit auditd's syscalls. For example if I
want to
audit like "write,always -S all" then auditd writes log and it causes
another write call and it causes audit to log and it causes auditd writes
log and so on... I briefly looked into kernel audit code but there's no
check(I could be wrong). In some extreme situation it will cause
kernel panic in kernel audit code 'cuz no memory. Try "exit,always -S all".
So, I'd like to suggest that 1)we should have some option to disable
audit for auditd's pid 2)add option to use netlink_broadcast for kernel
audit error log instead of printk(KERN_ERR) because printk(KERN_ERR)
causes syslog write. Then auditd listens the broadcast channel to detect
error.
Please let me know if any problems. If this is acceptable then I'm going to
do it.
Thanks
--
Junji Kanemaru
Linuon Inc.
Tokyo Japan
7:50 a.m.
On Thursday 03 February 2005 08:29, Junji Kanemaru wrote:
I wonder if it is needed to audit auditd's syscalls.
This is configurable by the auditctl rules. If the system admin wants it, he
can get it. If not, he can add a rule not to log it.
For example if I want to audit like "write,always -S all"
then auditd
writes log and it causes another write call and it causes audit to log and
it causes auditd writes log and so on...
I think this is expected.
I briefly looked into kernel audit code but there's no check(I
could be
wrong). In some extreme situation it will cause kernel panic in kernel
audit code 'cuz no memory. Try "exit,always -S all".
I think Chris added a patch that helps a little with out of memory conditions.
There is also other audit subsystem control parameters to let you limit the
rate at which packets are sent and how many buffers it should setup.
So, I'd like to suggest that 1)we should have some option to
disable
audit for auditd's pid
auditctl -a entry,never -S all -F pid=XXXX
This rule should be at the top of the list. I believe they are "executed" from
top to bottom like iptables does.
2)add option to use netlink_broadcast for kernel
audit error log instead of printk(KERN_ERR) because printk(KERN_ERR)
causes syslog write.
I don't want the audit log polluted with kernel error messages. I think they
belong in syslog.
-Steve
8:15 a.m.
auditctl -a entry,never -S all -F pid=XXXX
I see. Thank you for the info.
>2)add option to use netlink_broadcast for kernel
>audit error log instead of printk(KERN_ERR) because printk(KERN_ERR)
>causes syslog write.
I don't want the audit log polluted with kernel error messages. I think they
belong in syslog.
Yeah, but isn't it nice to have if auditd can get kernel audit warnings with
netlink channel before panic? For example if auditd can check
audit_backlog_limit then auditd can do some safer action before
sudden kernel panic... I'm not saying completely replace it, just another
event for auditd.
--
Junji Kanemaru
Linuon Inc.
Tokyo Japan
10:08 a.m.
I ran into the same problem - you can solve it with a little script that
starts auditd:
#!/bin/bash
/etc/init.d/auditd restart || exit 1
/sbin/auditctl -e 1
PID=`ps x | grep auditd | grep -v grep | cut -c 2-5`
if [ -z "$PID" ] ; then
exit 2;
fi
/sbin/auditctl -a entry,always -S all -F pid!=$PID || exit3
Hope it helps.
Avishay Traeger
On Thu, 2005-02-03 at 23:15 +0900, Junji Kanemaru wrote:
> auditctl -a entry,never -S all -F pid=XXXX
I see. Thank you for the info.
>>2)add option to use netlink_broadcast for kernel
>>audit error log instead of printk(KERN_ERR) because printk(KERN_ERR)
>>causes syslog write.
>
>
> I don't want the audit log polluted with kernel error messages. I think they
> belong in syslog.
Yeah, but isn't it nice to have if auditd can get kernel audit warnings with
netlink channel before panic? For example if auditd can check
audit_backlog_limit then auditd can do some safer action before
sudden kernel panic... I'm not saying completely replace it, just another
event for auditd.
--
Avishay Traeger <atraeger(a)cs.sunysb.edu>
11:24 a.m.
On Thu, 03 Feb 2005 11:08:08 EST, Avishay Traeger said:
PID=`ps x | grep auditd | grep -v grep | cut -c 2-5`
/sbin/auditctl -a entry,always -S all -F pid!=$PID || exit3
This will, under some conditions, allow an attacker a "free lunch" just by
calling his process something with 'auditd' in it. You really need to check
against what process is actually doing the auditd function (i.e. is it listening
to the netlink?)
The 'cut -c 2-5' will bork if auditd gets a process ID over 9999. '-c 1-6'
or
awk '{print $1}' might be better....
Also, you can save a fork/exec like this:
PID=`ps x | grep 'aud[i]td' | -c 1-5`
(Think carefully about how grep applies the regexp when it finds itself...)
11:40 a.m.
Well I wasn't worried about security risks because I was using it for a
personal study, but yes, definitely a "free lunch". Also, thanks for
the bash scripting corrections! :)
Avishay Traeger
On Thu, 2005-02-03 at 12:24 -0500, Valdis.Kletnieks(a)vt.edu wrote:
On Thu, 03 Feb 2005 11:08:08 EST, Avishay Traeger said:
> PID=`ps x | grep auditd | grep -v grep | cut -c 2-5`
> /sbin/auditctl -a entry,always -S all -F pid!=$PID || exit3
This will, under some conditions, allow an attacker a "free lunch" just by
calling his process something with 'auditd' in it. You really need to check
against what process is actually doing the auditd function (i.e. is it listening
to the netlink?)
The 'cut -c 2-5' will bork if auditd gets a process ID over 9999. '-c
1-6' or
awk '{print $1}' might be better....
Also, you can save a fork/exec like this:
PID=`ps x | grep 'aud[i]td' | -c 1-5`
(Think carefully about how grep applies the regexp when it finds itself...)
--
Linux-audit mailing list
Linux-audit(a)redhat.com
http://www.redhat.com/mailman/listinfo/linux-audit
7262
days inactive
7262
days old
linux-audit@lists.linux-audit.osci.io
5 comments
4 participants
participants (4)
-
Avishay Traeger -
Junji Kanemaru -
Steve Grubb -
Valdis.Kletnieks＠vt.edu