6:01 p.m.
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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
9:30 a.m.
On Tue, 2009-01-27 at 18:01 -0600, LC Bruzenak wrote:
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.
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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
11:15 a.m.
On Tuesday 27 January 2009 07:01:08 pm LC Bruzenak wrote:
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
11:44 a.m.
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.
-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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
2:14 p.m.
On Wednesday 28 January 2009 12:44:27 pm 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.
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.
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.
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.
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
2:30 p.m.
On Wed, 2009-01-28 at 15:14 -0500, Steve Grubb wrote:
On Wednesday 28 January 2009 12:44:27 pm LC Bruzenak wrote:
> On Wed, 2009-01-28 at 12:15 -0500, Steve Grubb wrote:
...
> 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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
3:04 p.m.
On Wed, 2009-01-28 at 14:30 -0600, LC Bruzenak wrote:
On Wed, 2009-01-28 at 15:14 -0500, Steve Grubb wrote:
> On Wednesday 28 January 2009 12:44:27 pm LC Bruzenak wrote:
> > 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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
5:37 p.m.
LC Bruzenak wrote:
> ...
>
>
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?
I'll have to put in some retry logic on my end. Probably would
regardless.
LCB.
5:52 p.m.
On Wed, 2009-01-28 at 15:37 -0800, Casey Schaufler wrote:
LC Bruzenak wrote:
>> ...
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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
6:36 p.m.
LC Bruzenak wrote:
On Wed, 2009-01-28 at 15:37 -0800, Casey Schaufler wrote:
> LC Bruzenak wrote:
>
>>> ...
>>>
>
>
> 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?
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.
12:57 a.m.
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
Casey Schaufler wrote:
LC Bruzenak wrote:
> On Wed, 2009-01-28 at 15:37 -0800, Casey Schaufler wrote:
>
>
>> LC Bruzenak wrote:
>>
>>
>>>> ...
>>>>
>>>>
>>
>>
>> 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?
>
>
>
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
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
10:49 p.m.
James W. Hoeft wrote:
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.
9:48 a.m.
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?
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...
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
- RGB
--
Richard Guy Briggs <rbriggs(a)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
1:10 p.m.
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
9:25 p.m.
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(a)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(a)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
9:25 a.m.
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(a)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
10:10 a.m.
New subject: spurious \n in session id helper [was: Re: user message limits]
On Wed, Sep 18, 2013 at 10:25:57AM -0400, Steve Grubb wrote:
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:
> > 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(a)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.
Yup, I'll do that...
-Steve
- RGB
--
Richard Guy Briggs <rbriggs(a)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
5:08 p.m.
On Wed, 2009-01-28 at 12:15 -0500, Steve Grubb wrote:
On Tuesday 27 January 2009 07:01:08 pm LC Bruzenak wrote:
> 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
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.
--
LC (Lenny) Bruzenak
lenny(a)magitekltd.com
4112
days inactive
5806
days old
linux-audit@lists.linux-audit.osci.io
17 comments
5 participants
participants (5)
-
Casey Schaufler -
James W. Hoeft -
LC Bruzenak -
Richard Guy Briggs -
Steve Grubb