user message limits

[Steve Grubb]

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