Received: by 10.192.165.148 with SMTP id m20csp4944822imm; Tue, 24 Apr 2018 10:58:33 -0700 (PDT) X-Google-Smtp-Source: AIpwx48weaq2VVeday1iT3cjpvtr9xpXgosk72E98M77HiemoURtvLRu7D4AlKuJ3axtPPsygfi+ X-Received: by 10.98.153.204 with SMTP id t73mr24676729pfk.121.1524592713300; Tue, 24 Apr 2018 10:58:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524592713; cv=none; d=google.com; s=arc-20160816; b=bR8LdHaPZefXHm+rSVLhfnf65YhFQHgJxXTvPnnhn7A4IayVDSuUor1SFA7icg6o7l QZ7RiVj3drt/sukJ0dWVQKaHLDs8ovcRL/zCLdlZQpfrnrwpLdJ65lh4WiEhzg4z52Re U2oPgqvy9oAwb3P1Q6vNPyYvh/lZ8mUTjOZt71qgW0D/h59X152mmo0D0zR8LMOqa+Tn QlknASB77JI7b6GSPpk3lSqR+3U359RBgsmazVBF8kXqOppAWJ466J+Uh3TKkIBlAFqN d8cM+JrBaD76a4AhpjY6XJjeKmngsVfIElCzWutxBHmXhKZW3eCQs/fEpck5VzeV71cw +kgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=oF+YO+Cb+o6rK35EIA9h/pd88bVftSzqO8P1YX40XdI=; b=OeK9mDVNuxz7XwJhEgwe8vpvnFYPrsvIoNXoghWUXmGYx8rfTuyTS7P54JKEI4j5Nu dWQhMe5bOGDz7e9CFHD8RiZiJQKP8bOXqkDljVTSiE5SzdDeoZuY8goZ72YLga17jwGu 1CRcnVTPgCbPUKSlYX/69CPFmJjG8050u0pRfM0hxTnim7gE6rtAdeyn8+/GZq/KDtDO IzXsyYQykw10QixLTrEE/MF/pKT4CxVApogTrNGHdBm87F6c7rChEB6HLp8MrWTU8hLi kp7ef4JRPRnrF+G/AfGZ58Vy5XYrk7e1gE81nRdouvJkMDmphvIsfXq6d6oHecfQcSuM 94mQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l12si12048830pgc.438.2018.04.24.10.58.18; Tue, 24 Apr 2018 10:58:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752269AbeDXR45 (ORCPT + 99 others); Tue, 24 Apr 2018 13:56:57 -0400 Received: from shards.monkeyblade.net ([184.105.139.130]:38040 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750735AbeDXR4y (ORCPT ); Tue, 24 Apr 2018 13:56:54 -0400 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id DAB781042DC19; Tue, 24 Apr 2018 10:56:52 -0700 (PDT) Date: Tue, 24 Apr 2018 13:56:51 -0400 (EDT) Message-Id: <20180424.135651.492329246141701047.davem@davemloft.net> To: paul@paul-moore.com Cc: dh.herrmann@gmail.com, linux-kernel@vger.kernel.org, jmorris@namei.org, teg@jklm.no, sds@tycho.nsa.gov, selinux@tycho.nsa.gov, linux-security-module@vger.kernel.org, eparis@parisplace.org, serge@hallyn.com, netdev@vger.kernel.org Subject: Re: [PATCH 2/3] net/unix: hook unix_socketpair() into LSM From: David Miller In-Reply-To: References: <20180423133015.5455-1-dh.herrmann@gmail.com> <20180423133015.5455-3-dh.herrmann@gmail.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 24 Apr 2018 10:56:53 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Paul Moore Date: Tue, 24 Apr 2018 13:55:31 -0400 > On Mon, Apr 23, 2018 at 9:30 AM, David Herrmann wrote: >> Use the newly created LSM-hook for unix_socketpair(). The default hook >> return-value is 0, so behavior stays the same unless LSMs start using >> this hook. >> >> Signed-off-by: David Herrmann >> --- >> net/unix/af_unix.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c >> index 68bb70a62afe..bc9705ace9b1 100644 >> --- a/net/unix/af_unix.c >> +++ b/net/unix/af_unix.c >> @@ -1371,6 +1371,11 @@ static int unix_stream_connect(struct socket *sock, struct sockaddr *uaddr, >> static int unix_socketpair(struct socket *socka, struct socket *sockb) >> { >> struct sock *ska = socka->sk, *skb = sockb->sk; >> + int err; >> + >> + err = security_unix_stream_socketpair(ska, skb); >> + if (err) >> + return err; > > I recognize that AF_UNIX is really the only protocol that supports > socketpair(2) at the moment, but I like to avoid protocol specific LSM > hooks whenever possible. Unless someone can think of a good > objection, I would prefer to see the hook placed in __sys_socketpair() > instead (and obviously drop the "unix_stream" portion from the hook > name). The counterargument is that after 30 years no other protocol has grown usage of this operation. :-)