From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joy Latten Subject: Re: [redhat-lspp] auditing labeled ipsec Date: Fri, 13 Oct 2006 16:34:18 -0500 Message-ID: <1160775258.17737.100.camel@faith.austin.ibm.com> References: <1160599200.17737.54.camel@faith.austin.ibm.com> <200610120836.54601.sgrubb@redhat.com> <452E4E2B.1030101@hp.com> <200610121024.05288.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200610121024.05288.sgrubb@redhat.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: redhat-lspp@redhat.com, linux-audit@redhat.com List-Id: linux-audit@redhat.com On Thu, 2006-10-12 at 10:24 -0400, Steve Grubb wrote: > On Thursday 12 October 2006 10:16, Paul Moore wrote: > > PF_KEYv2 is a socket family/protocol defined by RFC2367 whose original goal > > was to standardize the interface between the in-kernel IPsec bits and the > > userland key management daemon. > > OK, then the question becomes is the communication protocol asyncronous or > synchronous? If synchronous (the request is handled immediately and not > queued like netlink), then current task struct can be used. Otherwise, there > may be some more code needed to grab the loginuid during the send and store > it with the packet until dequeued. If it is async, there may be selinux > implications as well. > pfkey doesn't appear to use a queue like netlink... it registers socket protocol operations such as .recvmsg and .sendmsg which get called via sock_recvmsg and sock_sendmsg. Joy