10:45 p.m.
Hi,
I'm not sure if this is the default behavior,
I'm using audit 2.3.2, and I've configured auditd not to log anything
(NOLOG option), and I set the queue buffer to 10240 messages.
When the buffer is full or auditd is suddenly killed or for some other
reason, it seems to write a lot of things to dmesg or
/var/log/messages
So, did kauditd wrote all these? I already killed auditd process but I
can still see logs piling up.
Can I ask kauditd not print anything if user space program cannot
handle that much message?
--
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33
11:11 p.m.
It's still printing logs even I set all printk parameters to zeros:
cat /proc/sys/kernel/printk
0 0 0 0
P.S I'm running kernel 2.6.32
On Mon, Jan 20, 2014 at 12:45 PM, Aaron Lewis
<the.warl0ck.1989(a)gmail.com> wrote:
Hi,
I'm not sure if this is the default behavior,
I'm using audit 2.3.2, and I've configured auditd not to log anything
(NOLOG option), and I set the queue buffer to 10240 messages.
When the buffer is full or auditd is suddenly killed or for some other
reason, it seems to write a lot of things to dmesg or
/var/log/messages
So, did kauditd wrote all these? I already killed auditd process but I
can still see logs piling up.
Can I ask kauditd not print anything if user space program cannot
handle that much message?
--
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33
--
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33
11:36 a.m.
On 14/01/20, Aaron Lewis wrote:
Hi,
I'm not sure if this is the default behavior,
I'm using audit 2.3.2, and I've configured auditd not to log anything
(NOLOG option), and I set the queue buffer to 10240 messages.
I assume this is because you are using remote logging or using the
dispatcher?
When the buffer is full or auditd is suddenly killed or for some
other
reason, it seems to write a lot of things to dmesg or
/var/log/messages
This is by design.
So, did kauditd wrote all these? I already killed auditd process but
I
can still see logs piling up.
If auditd has ever run, kaudit will continue to try delivering messages.
Can I ask kauditd not print anything if user space program cannot
handle that much message?
Sure, on the kernel boot line you can set audit=0 to disable kaudit, or
you can tell the init system to not start auditd.
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
11:40 a.m.
On Mon, 20 Jan 2014 12:36:27 -0500
Richard Guy Briggs <rgb(a)redhat.com> wrote:
> Can I ask kauditd not print anything if user space program
cannot
> handle that much message?
Sure, on the kernel boot line you can set audit=0 to disable kaudit,
or you can tell the init system to not start auditd.
what if someone never wants events to go to syslog?
-Steve
12:24 p.m.
On 14/01/20, Steve Grubb wrote:
On Mon, 20 Jan 2014 12:36:27 -0500
Richard Guy Briggs <rgb(a)redhat.com> wrote:
> > Can I ask kauditd not print anything if user space program cannot
> > handle that much message?
>
> Sure, on the kernel boot line you can set audit=0 to disable kaudit,
> or you can tell the init system to not start auditd.
what if someone never wants events to go to syslog?
Then we need to add a new feature to kaudit to stop them.
This also begs the question of what happens to AUDIT_USER_AVC
messages... This patchwork is messy.
-Steve
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
12:34 p.m.
Hi Guys,
Yes just like what Steve says.
I use a dispatcher to handle all logs, and rather discard them all if
the dispatcher can't handle it.
And no, the dispatcher is a perl program runs locally, not remote
logging. (I replaced the 'dispatcher=' line in auditd.conf)
On Tue, Jan 21, 2014 at 2:24 AM, Richard Guy Briggs <rgb(a)redhat.com> wrote:
On 14/01/20, Steve Grubb wrote:
> On Mon, 20 Jan 2014 12:36:27 -0500
> Richard Guy Briggs <rgb(a)redhat.com> wrote:
>
> > > Can I ask kauditd not print anything if user space program cannot
> > > handle that much message?
> >
> > Sure, on the kernel boot line you can set audit=0 to disable kaudit,
> > or you can tell the init system to not start auditd.
>
> what if someone never wants events to go to syslog?
Then we need to add a new feature to kaudit to stop them.
This also begs the question of what happens to AUDIT_USER_AVC
messages... This patchwork is messy.
> -Steve
- RGB
--
Richard Guy Briggs <rbriggs(a)redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33
2:43 p.m.
On Mon, 2014-01-20 at 12:45 +0800, Aaron Lewis wrote:
Hi,
I'm not sure if this is the default behavior,
I'm using audit 2.3.2, and I've configured auditd not to log anything
(NOLOG option), and I set the queue buffer to 10240 messages.
When the buffer is full or auditd is suddenly killed or for some other
reason, it seems to write a lot of things to dmesg or
/var/log/messages
So, did kauditd wrote all these? I already killed auditd process but I
can still see logs piling up.
Can I ask kauditd not print anything if user space program cannot
handle that much message?
Hmmm, no. If the buffer overflows you will get messages about lost
audit records in printk. We have no way to silence those.
If auditd is not running we dump audit messages to dmesg/printk. (and
rate limit them). We don't have a way to turn that off (and people in
general seem to like it).
So, no, we can't do what you want today. (You can run auditctl -e 0 to
get them to stop)
If you are a Red Hat customer I would suggest opening a support case
requesting this new feature. If not, you may feel free to open a
bugzilla at bugzilla.redhat.com and explain what you are doing and what
you want. We will get to it as time allows.
If you have the chops to work on it yourself, you'll want to implement a
new 'audit feature'. You can look at kernel commit 21b85c31d23f2047d47
for an example of a new feature. Then likely check out
kernel/audit.c::audit_printk_skb() If your new feature is true you'll
want to skip all of that function, except the audit_hold_skb().
Shouldn't be too hard to do....
-Eric
3992
days inactive
3992
days old
linux-audit@lists.linux-audit.osci.io
6 comments
4 participants
participants (4)
-
Aaron Lewis -
Eric Paris -
Richard Guy Briggs -
Steve Grubb