user message limits

[Richard Guy Briggs]

On Tue, Sep 17, 2013 at 02:10:19PM -0400, Steve Grubb wrote:
> 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:
> > > 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

So, 4096*2 + ?*2 + 11 + 256 + 1 means CONTEXT_SIZE is 255?  Is this
better documented somewhere?

> It cannot change without recompiling all of user space.

Of course.  I'm curious how it is used.  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.

> 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.

> 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 at localhost.localdomain nonetheless!).  auditd seems
to be doing the right thing when writing out /var/log/audit/audit.log
though.

> And then task context:
> audit_log_format(ab, " subj=%s", ctx);
> which can be 262 bytes.

I'll take your word for it, 6 + 256...

> 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.

Good.  I just want to be able to justify this number...

> -Steve

- RGB

--
Richard Guy Briggs <rbriggs at redhat.com>
Senior Software Engineer
Kernel Security
AMER ENG Base Operating Systems
Remote, Ottawa, Canada
Voice: +1.647.777.2635
Internal: (81) 32635
Alt: +1.613.693.0684x3545