From: Steve Grubb <sgrubb@redhat.com>
To: Richard Guy Briggs <rgb@redhat.com>
Cc: linux-audit@redhat.com, Justin Stephenson <jstephen@redhat.com>
Subject: Re: user message limits
Date: Wed, 18 Sep 2013 10:25:57 -0400 [thread overview]
Message-ID: <1733218.gexlcdx6Tt@x2> (raw)
In-Reply-To: <20130918022523.GB13962@madcap2.tricolour.ca>
On Tuesday, September 17, 2013 10:25:23 PM Richard Guy Briggs wrote:
> On Tue, Sep 17, 2013 at 02:10:19PM -0400, Steve Grubb wrote:
> > This is defined in the ABI:
> >
> > #define MAX_AUDIT_MESSAGE_LENGTH 8970 //
> > PATH_MAX*2+CONTEXT_SIZE*2+11+256+1
> So, 4096*2 + ?*2 + 11 + 256 + 1 means CONTEXT_SIZE is 255? Is this
> better documented somewhere?
I believe this was based on
#define INITCONTEXTLEN 255
> > It cannot change without recompiling all of user space.
>
> Of course. I'm curious how it is used.
Setting buffers on the stack. Immediately below that define is:
struct audit_message {
struct nlmsghdr nlh;
char data[MAX_AUDIT_MESSAGE_LENGTH];
};
and that gets used by user space in various programs. I think we've run into
problems with pam in the past if the constant ever changes. The constant was
designed at the time to handle the largest record known, AUDIT_PATH. It might
need adjusting upward as I think a couple things have been added over the
years.
> If userspace can't actually make use of that, then it should be changed, or
> the other limitations fixed. I suspect a kernel limitation, but would need
> to investigate more.
User space needs an idea of the largest possible event its expected to handle.
Some apps have to be very reliable in terms of auditing and they make use of
the stack so there is no chance of leaks or memory fragmentation.
> > But the kernel always
> >
> > includes this in any event:
> > audit_log_format(ab, "audit(%lu.%03lu:%u): ",
> >
> > t.tv_sec, t.tv_nsec/1000000, serial);
> >
> > an unsigned is 4 bytes and long unsigned is 8 bytes. Translated to decimal
> >
> > 4026531839
> > 18446744073709551615
> >
> > So, I'd say the header can occupy 43 bytes max.
>
> I'm not sure where you got that 4-byte max decimal, but it has the right
> number of digits... ;-) I get 11 chars for formatting, 20 for the
> first number, 3 for the second and 10 for the last, giving 44.
>
> > (All the following numbers
> > assume maximum size.) Then if you look at the message body, it starts by
>
> > logging an identifier "user ", which is 5 bytes. Then:
> Where is this? I don't see it.
Looks like it has been dropped some time recently. But its in old kernels such
as 2.6.32.
> > audit_log_format(*ab, "pid=%d uid=%u", task_tgid_vnr(current), uid);
> > which my count is 29 bytes maximum.
>
> Yup.
>
> > and then session information:
> > audit_log_format(ab, " auid=%u ses=%u\n", auid, sessionid);
> > which is 32 characters...but I don't know why the \n is in there. That
> > should probably be deleted!!
>
> That is unexpected... added in 4d3fb709 when the session id was
> refactored (by eparis@localhost.localdomain nonetheless!). auditd seems
> to be doing the right thing when writing out /var/log/audit/audit.log
> though.
Please drop the '\n' as I mentioned above. It doesn't belong there and wastes
room in the audit trail. Auditd strips all '\n' and it would run faster if it
didn't have to strip it out.
-Steve
next prev parent reply other threads:[~2013-09-18 14:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 0:01 user message limits LC Bruzenak
2009-01-28 15:30 ` LC Bruzenak
2009-01-28 17:15 ` Steve Grubb
2009-01-28 17:44 ` LC Bruzenak
2009-01-28 20:14 ` Steve Grubb
2009-01-28 20:30 ` LC Bruzenak
2009-01-28 21:04 ` LC Bruzenak
2009-01-28 23:37 ` Casey Schaufler
2009-01-28 23:52 ` LC Bruzenak
2009-01-29 0:36 ` Casey Schaufler
2009-01-29 6:57 ` James W. Hoeft
2009-01-30 4:49 ` Casey Schaufler
2013-09-17 14:48 ` Richard Guy Briggs
2013-09-17 18:10 ` Steve Grubb
2013-09-18 2:25 ` Richard Guy Briggs
2013-09-18 14:25 ` Steve Grubb [this message]
2013-09-18 15:10 ` spurious \n in session id helper [was: Re: user message limits] Richard Guy Briggs
2009-06-08 22:08 ` user message limits LC Bruzenak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1733218.gexlcdx6Tt@x2 \
--to=sgrubb@redhat.com \
--cc=jstephen@redhat.com \
--cc=linux-audit@redhat.com \
--cc=rgb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox