From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751475AbbI2EgQ (ORCPT ); Tue, 29 Sep 2015 00:36:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43553 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751066AbbI2EgP (ORCPT ); Tue, 29 Sep 2015 00:36:15 -0400 Date: Tue, 29 Sep 2015 00:36:11 -0400 From: Richard Guy Briggs To: Paul Moore Cc: linux-audit@redhat.com, linux-kernel@vger.kernel.org, sgrubb@redhat.com, eparis@redhat.com, v.rathor@gmail.com, ctcard@hotmail.com Subject: Re: [PATCH 1/2] audit: stop an old auditd being starved out by a new auditd Message-ID: <20150929043611.GC22712@madcap2.tricolour.ca> References: <206b0f415832c9fde6befaa13a7b6efe916d1ba4.1442494593.git.rgb@redhat.com> <37985395.CCHtq1r3PJ@sifl> <20150928111731.GA22712@madcap2.tricolour.ca> <2360811.VVg2NkZJdF@sifl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2360811.VVg2NkZJdF@sifl> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/09/28, Paul Moore wrote: > On Monday, September 28, 2015 07:17:31 AM Richard Guy Briggs wrote: > > On 15/09/25, Paul Moore wrote: > > > The audit_make_reply() function is the wrong thing to be using here, we > > > should create our own buffer from scratch like most other records. Also, > > > yes, we want to include the new pid, but I really don't think there is > > > any value in including the seqno of the AUDIT_SET/AUDIT_STATUS_PID > > > message. > > > > Most other records use audit_log_start(), which isn't what we want here, > > since we want to bypass the queue to test if it is still alive. We > > don't care if it is delivered. We just care if the socket is still > > alive. We don't want a context either. > > Yes, that is why I mentioned creating the buffer from scratch. > > > So, I believ audit_make_reply() can be used just fine, setting portid, > > seq, done and multi to zero. > > The 'multi' flag should definitely be set to zero, 'seq' is fine at zero, but > I think we can do better with 'portid'; we know the 'portid' value so just use > it in the call to audit_make_reply(). Most other audit_log_start() created messages set portid to zero except user messages, and those are set using the initiating process' portid and not the destination id. So here I think portid should be zero. The target task should know its own portid and the netlink field for portid isn't used for routing to that destination that I can discern from the netlink code. > I don't like that we are reusing audit_make_reply() for non-reply netlink > messages, but I'll get over that. This will likely get a revamp when we get > around to a proper fix of the queuing system. This could even be renamed audit_make_message() and possibly be generalized to be useful to audit_log_start(), or rather audit_buffer_alloc(). Later... > > > > > Also, this is more of a attempted hijack message and not a > > > > > simple ping, right? > > > > > > > > Ok, so maybe AUDIT_PING is not the appropriate name for it. I don't > > > > have a problem changing it, but I think the pid of the hijacker would be > > > > useful information to the ping-ee unless the ping message was only ever > > > > issues in a contextless kernel-initiated message. > > > > > > Let's change the message name, this isn't a ping message and we may want > > > to have a ping message at some point in the future. > > > > Ok, how about AUDIT_HIJACK_TEST, with a payload of the u32 > > representation of the PID of the task attempting to replace it. > > Why add the TEST? It is a hijack attempt, or at least it is if the record is > emitted successfully :) I would go simply with AUDIT_HIJACK or maybe > AUDIT_REPLACE (or similar) if "hijack" is a bit too inflammatory (it probably > is ...). I had actually named it AUDIT_REPLACE_TEST, but your repeated use of the term "hijack" swayed me... I'd still lean towards *_TEST since it is testing to replace a stale socket and not a live one. > paul moore - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545