user message limits

DISCUSSION LC Bruzenak 5 participants 18 messages Jan 28, 2009 – Sep 18, 2013

Share & tools

LC Bruzenak

author

2009-01-28 00:01 UTC #0 lore raw

I know I can go look at the code, however I figured I'd ask here first about the limits on the user message in both audit_log_user_message and ausearch.

With audit_log_user_message the maximum length allowed appears to be around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the executable name length (and other stuff auto-pushed into the string) which is why I say "around".

Even when I get a successful return value (from audit_log_user_message), I don't get my string back out in "ausearch" unless it is WAY smaller - ~1K or less I think.

Any ideas/thoughts?

This is the latest (1.7.11-2) audit package.

Thx,
LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]

LC Bruzenak

author

2009-01-28 15:31 UTC #1 lore raw

Quoted 13 lines · LC Bruzenak

I know I can go look at the code, however I figured I'd ask here first about the limits on the user message in both audit_log_user_message and ausearch.
With audit_log_user_message the maximum length allowed appears to be around MAX_AUDIT_MESSAGE_LENGTH-100. I think it may depend on the executable name length (and other stuff auto-pushed into the string) which is why I say "around".
Even when I get a successful return value (from audit_log_user_message), I don't get my string back out in "ausearch" unless it is WAY smaller - ~1K or less I think.

Quoted 7 lines

Any ideas/thoughts?
This is the latest (1.7.11-2) audit package.
Thx,
LCB.

And FWIW the raw and interpreted ausearch results can be slightly different:

[root@v157 ~]# ausearch -r -a 26539
node=v157 type=TRUSTED_APP msg=audit(1233155663.335:26539): user
pid=14134 uid=500 auid=500 ses=17
subj=user_u:user_r:user_t:s0-s15:c0.c1023 msg='test mesg 111AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX: exe="/opt/jcdx/bin/audit-test" (hostname=?, addr=?, t'

[root@v157 ~]# ausearch -i -a 26539
----
node=v157 type=TRUSTED_APP msg=audit(01/28/2009 09:14:23.335:26539) :
user pid=14134 uid=lcb auid=lcb ses=17
subj=user_u:user_r:user_t:s0-s15:c0.c1023 msg='test mesg 111AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAX: exe=/opt/jcdx/bin/audit-test (hostname=?, addr=?,

LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]

Steve Grubb

2009-01-28 17:15 UTC #2 lore raw

In reply to LC Bruzenak

Quoted 5 lines · LC Bruzenak

Even when I get a successful return value (from audit_log_user_message), I don't get my string back out in "ausearch" unless it is WAY smaller - ~1K or less I think.
Any ideas/thoughts?

I tested like this:

auditctl -m perl -e '{print "A"x"2048"}'

and found its getting cutoff just under 1K. So, I checked the kernel code and found this:

761 if (msg_type != AUDIT_USER_TTY)
762 audit_log_format(ab, " msg='%.1024s'",
763 (char *)data);
764 else {

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.

-Steve

LC Bruzenak

author

2009-01-28 17:44 UTC #3 lore raw

Quoted 6 lines · Steve Grubb

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

Thanks 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'm trying to avoid a lot of retry logic on the sending side, where if a failure occurs, we would truncate and resend until it passes. I guess if I were certain that 7K is always going to fit I could artificially clamp my own input there, but it seems better if it were universally constant.

Thx,
LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]

Steve Grubb

2009-01-28 20:14 UTC #4 lore raw

Quoted 7 lines · LC Bruzenak

Quoted 2 lines · Steve Grubb
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.
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.

Sure, but netlink is asynchronous. There is no way to tell user space that the payload sent was too big unless you hit a netlink internal limit.

Quoted 1 line

A secondary concern is - what is the input limit?

The code says it will print up to 1024 chars, some of which comes from libaudit.

Quoted 2 lines

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?

Well, here is a problem. All current kernels only allow 1024. If we make that bigger, then the only thing I can do to reliably determine this is to check at runtime what the kernel version is. uname() is an ugly way to do this when you consider that a kernel could be patched to increase the limit.

Quoted 4 lines

I'm trying to avoid a lot of retry logic on the sending side, where if a failure occurs, we would truncate and resend until it passes. I guess if I were certain that 7K is always going to fit I could artificially clamp my own input there, but it seems better if it were universally constant.

For the time being, you'll need to clamp your input to maybe about 950 chars. In all the work I've done patching everything, I've never needed to send more than 200 bytes or so.

-Steve

LC Bruzenak

author

2009-01-28 20:30 UTC #5 lore raw

Quoted 4 lines · Steve Grubb

Quoted 1 line · LC Bruzenak
On Wed, 2009-01-28 at 12:15 -0500, Steve Grubb wrote:
...

Quoted 9 lines

Quoted 4 lines
I'm trying to avoid a lot of retry logic on the sending side, where if a failure occurs, we would truncate and resend until it passes. I guess if I were certain that 7K is always going to fit I could artificially clamp my own input there, but it seems better if it were universally constant.
For the time being, you'll need to clamp your input to maybe about 950 chars. In all the work I've done patching everything, I've never needed to send more than 200 bytes or so.

That's because maybe you have never worked on a MLS system where all cross-level cut/paste transfers were required to be audited in toto. :)

I'll have to put in some retry logic on my end. Probably would regardless.

LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]

LC Bruzenak

author

2009-01-28 21:04 UTC #6 lore raw

Quoted 7 lines · LC Bruzenak

Quoted 2 lines · Steve Grubb
Quoted 1 line · LC Bruzenak
On Wed, 2009-01-28 at 12:15 -0500, Steve Grubb wrote:
I'll have to put in some retry logic on my end. Probably would regardless.

...actually not retry logic but I meant breaking it up and sending multiple records when the size exceeds the text limit.

Thx,
LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]

Casey Schaufler

2009-01-28 23:38 UTC #7 lore raw

In reply to LC Bruzenak

Quoted 9 lines · LC Bruzenak

Quoted 3 lines
...
That's because maybe you have never worked on a MLS system where all cross-level cut/paste transfers were required to be audited in toto. :)

That would be a most peculiar requirement. Are "they" requiring that you audit the data sent with cross-level send(), read() and write() as well?

Quoted 6 lines

I'll have to put in some retry logic on my end. Probably would regardless.
LCB.

LC Bruzenak

author

2009-01-28 23:52 UTC #8 lore raw

Quoted 8 lines · Casey Schaufler

Quoted 1 line · LC Bruzenak
Quoted 1 line
...
That would be a most peculiar requirement. Are "they" requiring that you audit the data sent with cross-level send(), read() and write() as well?

Casey,

This is similar to the HP CMW trusted copy/paste capability (not necessarily cut). I assume Trusted Irix had something similar?

LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]

Casey Schaufler

2009-01-29 00:37 UTC #9 lore raw

Quoted 14 lines · LC Bruzenak

Quoted 11 lines · Casey Schaufler
Quoted 2 lines · LC Bruzenak
Quoted 2 lines
...
That would be a most peculiar requirement. Are "they" requiring that you audit the data sent with cross-level send(), read() and write() as well?

Quoted 6 lines

Casey,
This is similar to the HP CMW trusted copy/paste capability (not necessarily cut). I assume Trusted Irix had something similar?

Actually, the Trix B1 evaluation had a single level window system and the CC evaluated system was server only.

The notion of auditing the data passed in addition to the subject and object information has got to be a CMW thing. In principle moving data from a Secret window to a TS window is no different from moving it from a Secret file to a TS file, and you would never audit that data.

James W. Hoeft

2009-01-29 06:58 UTC #10 lore raw

The requirement to include the entire cut buffer was only for high to low (downgrade) transfers (which are only allowed for text), and was a "derived" requirement, in that we had to include the text in the audit logs in order to get approval to provide that capability.

Jim

Quoted 42 lines · Casey Schaufler

Quoted 17 lines · LC Bruzenak
Quoted 14 lines · Casey Schaufler
Quoted 3 lines · LC Bruzenak
Quoted 3 lines
...
That would be a most peculiar requirement. Are "they" requiring that you audit the data sent with cross-level send(), read() and write() as well?
Quoted 7 lines
Casey,
This is similar to the HP CMW trusted copy/paste capability (not necessarily cut). I assume Trusted Irix had something similar?
Actually, the Trix B1 evaluation had a single level window system and the CC evaluated system was server only.
The notion of auditing the data passed in addition to the subject and object information has got to be a CMW thing. In principle moving data from a Secret window to a TS window is no different from moving it from a Secret file to a TS file, and you would never audit that data.
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Casey Schaufler

2009-01-30 04:53 UTC #11 lore raw

Quoted 4 lines · James W. Hoeft

The requirement to include the entire cut buffer was only for high to low (downgrade) transfers (which are only allowed for text), and was a "derived" requirement, in that we had to include the text in the audit logs in order to get approval to provide that capability.

... if she floats, she weighs less than a duck, and that makes her
a witch! Burn her!

How did you become so wise in the ways of science?

Ah yes, evaluators. There were several places in the CMW spec that pretty well required things that it also forbade you from doing. It explains much.

Richard Guy Briggs

2013-09-17 14:48 UTC #12 lore raw

In reply to LC Bruzenak

Quoted 3 lines · LC Bruzenak

Quoted 2 lines · Steve Grubb
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

Quoted 9 lines

Quoted 1 line
-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?

Quoted 4 lines

I'm trying to avoid a lot of retry logic on the sending side, where if a failure occurs, we would truncate and resend until it passes. I guess if I were certain that 7K is always going to fit I could artificially clamp my own input there, but it seems better if it were universally constant.

As to the question of buffer size detection, that's a more involved problem as noted with unreliable tests on kernel version...

Quoted 2 lines

LC (Lenny) Bruzenak
[email protected]

- RGB

--
Richard Guy Briggs <[email protected]>
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

Steve Grubb

2013-09-17 18:10 UTC #13 lore raw

Quoted 38 lines · Richard Guy Briggs

Quoted 4 lines · LC Bruzenak
Quoted 3 lines · Steve Grubb
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
Quoted 9 lines
Quoted 1 line
-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.

Quoted 2 lines

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

Richard Guy Briggs

2013-09-18 02:25 UTC #14 lore raw

Quoted 26 lines · Steve Grubb

Quoted 25 lines · Richard Guy Briggs
Quoted 4 lines · LC Bruzenak
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.

Quoted 6 lines

Quoted 2 lines
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?

Quoted 1 line

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.

Quoted 6 lines

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);

Quoted 6 lines

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.

Quoted 3 lines

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

Quoted 2 lines

audit_log_format(*ab, "pid=%d uid=%u", task_tgid_vnr(current), uid); which my count is 29 bytes maximum.

Yup.

Quoted 4 lines

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

Quoted 3 lines

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

Quoted 4 lines

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

Quoted 1 line

-Steve

- RGB

Steve Grubb

2013-09-18 14:25 UTC #15 lore raw

Quoted 7 lines · Richard Guy Briggs

Quoted 4 lines · Steve Grubb
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

Quoted 3 lines

Quoted 1 line
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.

Quoted 3 lines

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.

Quoted 18 lines

Quoted 7 lines
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);
Quoted 6 lines
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.

Quoted 5 lines

Quoted 4 lines
(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.

Quoted 10 lines

Quoted 2 lines
audit_log_format(*ab, "pid=%d uid=%u", task_tgid_vnr(current), uid); which my count is 29 bytes maximum.
Yup.
Quoted 4 lines
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!!

Quoted 4 lines

That is unexpected... added in 4d3fb709 when the session id was refactored (by [email protected] 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

Richard Guy Briggs

2013-09-18 15:10 UTC #16 lore raw

spurious \n in session id helper [was: Re: user message limits]

Quoted 7 lines · Steve Grubb

Quoted 6 lines · Richard Guy Briggs
Quoted 4 lines · Steve Grubb
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!!

Quoted 8 lines

Quoted 4 lines
That is unexpected... added in 4d3fb709 when the session id was refactored (by [email protected] 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.

Yup, I'll do that...

Quoted 1 line

-Steve

- RGB

LC Bruzenak

author

2009-06-08 22:08 UTC #17 lore raw

In reply to Steve Grubb

Quoted 19 lines · Steve Grubb

Quoted 5 lines · LC Bruzenak
Even when I get a successful return value (from audit_log_user_message), I don't get my string back out in "ausearch" unless it is WAY smaller - ~1K or less I think.
Any ideas/thoughts?
I tested like this:
auditctl -m perl -e '{print "A"x"2048"}'
and found its getting cutoff just under 1K. So, I checked the kernel code and found this:
761 if (msg_type != AUDIT_USER_TTY)
762 audit_log_format(ab, " msg='%.1024s'",
763 (char *)data);
764 else {

Quoted 4 lines

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

I apologize in advance, but I've lost the bubble on input event length. Is there a plan for the kernel to allow bigger buffers in to be audited?

As of my current one (2.6.29.4-75.fc10) I'm still in the same ~900 byte range.

To me, it seems that an increase would be automatically backward-compatible. The "dropoff" point would just extend out a ways...

Thx,
LCB.

Signature · 2 lines

LC (Lenny) Bruzenak
[email protected]