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: Tue, 17 Sep 2013 14:10:19 -0400 [thread overview]
Message-ID: <5267380.lufFp7267x@x2> (raw)
In-Reply-To: <20130917144802.GA15617@madcap2.tricolour.ca>
On Tuesday, September 17, 2013 10:48:02 AM Richard Guy Briggs wrote:
> On Wed, Jan 28, 2009 at 11:44:27AM -0600, LC Bruzenak wrote:
> > On Wed, 2009-01-28 at 12:15 -0500, Steve Grubb wrote:
> > > Offhand, I don't remember why the kernel sets the limit so low. It could
> > > be
> > > bumped some. How much, I don't know. 4K or 8K would seem fine.
>
> I'm just reading this thread now, relating to
> https://bugzilla.redhat.com/show_bug.cgi?id=1007069
>
> > > -Steve
> >
> > To me the primary thing is consistency with the input text size.
> > Seems strange to successfully send in some data and be unable to
> > retrieve it.
> >
> > A secondary concern is - what is the input limit? If the total input
> > buffer size is 8K and some of that needs to be used internally (by audit
> > lib), maybe it should be clamped at 7K?
>
> I did some tests. I set the format string in the kernel to 8970
> characters. In my example, I had a kernel-generated prefix of 133
> characters and userspace libaudit-appended suffix of 71 characters
> included in the buffer. I got a limit of 8937 characters for the
> resulting message sent to auditd. To fill the buffer, my text ended up
> being 8733 octets with the message from userspace (including the
> libaudit suffix) being 8804. I then deliberately overflowed it and
> stopped receiving messages from userspace when the text was 8798
> octets, truncating most of the suffix.
>
> This tells me the kernel or auditd limit is 8937. I assume this depends
> on netlink buffer structures, which could vary by message or by kernel.
> It also tells me the auditctl-buffer limit is 8804. Given the
> kernel-generated prefix could be a couple hundred characters, can we set
> format string to at least something less than 8937 - 133, if not 8937 -
> 250(or more)? I'd suggest 8637 as a ballpark. Then, set
> MAX_AUDIT_MESSAGE_LENGTH less than that, maybe 200 above 8K. 8K could
> be easily accomodated.
>
> Steve, can you give a sense as to the maximum added by libaudit? Do you
> have a sense as to the maximum added by the kernel?
This is defined in the ABI:
#define MAX_AUDIT_MESSAGE_LENGTH 8970 // PATH_MAX*2+CONTEXT_SIZE*2+11+256+1
It cannot change without recompiling all of user space. 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. (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:
audit_log_format(*ab, "pid=%d uid=%u", task_tgid_vnr(current), uid);
which my count is 29 bytes maximum.
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!!
And then task context:
audit_log_format(ab, " subj=%s", ctx);
which can be 262 bytes.
There is also a preamble that occupies 7 bytes before inserting the buffer from
user space. So, adding this all up and subtract from the ABI defined max, I get
8592 as the maximum possible. You can pad that a little bit in case something
changes in the future and maybe call it 8560...which should be plenty big.
-Steve
next prev parent reply other threads:[~2013-09-17 18:10 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 [this message]
2013-09-18 2:25 ` Richard Guy Briggs
2013-09-18 14:25 ` Steve Grubb
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=5267380.lufFp7267x@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