From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Guy Briggs Subject: Re: user message limits Date: Tue, 17 Sep 2013 10:48:02 -0400 Message-ID: <20130917144802.GA15617@madcap2.tricolour.ca> References: <1233100868.30154.103.camel@homeserver> <200901281215.16996.sgrubb@redhat.com> <1233164667.30154.142.camel@homeserver> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <1233164667.30154.142.camel@homeserver> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com Cc: Justin Stephenson List-Id: linux-audit@redhat.com 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@magitekltd.com - RGB -- Richard Guy Briggs 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