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
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,
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
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
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
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.
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
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
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
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(),
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
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,
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
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
14 matches
Mail list logo
