public inbox for linux-audit@redhat.com
 help / color / mirror / Atom feed
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

  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