Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp833359ybz; Fri, 1 May 2020 09:20:10 -0700 (PDT) X-Google-Smtp-Source: APiQypK08jx6PE7mWGdWtABRGrtTbO5ohy2CX5I8SxFwwr3k+5LHQsz2l23h3Mvf6Bc0WJFeMht1 X-Received: by 2002:a05:6402:b03:: with SMTP id bm3mr4082069edb.299.1588350009949; Fri, 01 May 2020 09:20:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588350009; cv=none; d=google.com; s=arc-20160816; b=NzjdvuOn4egmg2qglC1zLyAUvgYlgtw5N1ui5U1d/ogfBtwhow2W7l6ubq/kYok41R 4z5a5Jum385oPZUog9zE0T/tlhUNDQfJPx41YIuIynmdH4R6WI/xxnHVoTIh4sEVGFR5 Gdo/9vrjBd/Nb9HZ+oHk2MPT+Mi4JfcQeDya34qU1/gRWvGvblWP7kp0Ht8OywI8FHAZ +GQktbvk6w04W8Zaj3+S3eMLgj/RmvyRlCBYRFUYIVCHY4krG0/YG9mIWPOanzl4xcJA N7SlcForJQqBUHP8csWJiB4aU3idSqkSi7TcNNgrWOgUvahPEBJi2y+yaMliNZUPzJ14 83+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=23jPYeIHxkO0ujsGD7eYlRbwJShWG3r7UKIREhK5bgw=; b=ISw5ULUP/8tVw76I3ntNhhiEIJ1m5HPxLUbqgyoTLEFmR4clkyDOtSuwTYJm5mHUHu ZNvT5EXJ+Ql2wK+1QuogI2Q1PaD3JZhAMhcYY9nKUqObV6jJOdUnSzaJbr5Ie3D6iio2 yQ1RAaxgCKEHYKi/HLKL7H5g06b3XlTCpoz3VvpLOvMvZLYQBLT0qUUSaY2mTzchOY5o HRXNc861qV7UchQrERwhXWwuHeqMciUoCGIO06f9CrpkpuY4sU5zF/mUHcFAuNBM+bBs HHSuCy+w5g/o6YpIgdCvwmKp96kr+9crL2ANsUy+Ulg6/xL3FaBCcAUNyuapF7NIyo41 8qIQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=m5o6DjW2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d10si1891211edq.344.2020.05.01.09.19.45; Fri, 01 May 2020 09:20:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@paul-moore-com.20150623.gappssmtp.com header.s=20150623 header.b=m5o6DjW2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729581AbgEAQRt (ORCPT + 99 others); Fri, 1 May 2020 12:17:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728495AbgEAQRs (ORCPT ); Fri, 1 May 2020 12:17:48 -0400 Received: from mail-ej1-x643.google.com (mail-ej1-x643.google.com [IPv6:2a00:1450:4864:20::643]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C2FABC061A0C for ; Fri, 1 May 2020 09:17:46 -0700 (PDT) Received: by mail-ej1-x643.google.com with SMTP id re23so7861600ejb.4 for ; Fri, 01 May 2020 09:17:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paul-moore-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=23jPYeIHxkO0ujsGD7eYlRbwJShWG3r7UKIREhK5bgw=; b=m5o6DjW23uDqvbH6ScTDm+6wn+eSq6aJHkCW7h0E7PQK2TC3+9C/vXX2qmTMXOjDJV 5m7dDloIaOCSsVWgmy7ijk65TLdTjrJ35UszXTvgQ+9FAhewqXUSAX95ukIByWJVG8Lc aJ7FU+3rG+rlYO/LV/MbE4r+CuM0NZfQfnEoIVfNHKM5uWW6T0vZY8K1Xh0pMqnuCdoB 3NteUzx8k6UL8h+e6dKHslAXt3Zm5yYdLt8ZZFPmzTn15hRPVkNYH3tm/IV4ZnwkNiyz FKeNDhmMd7lLEeaZhxMAmD4CqLTsnybNjFKZKZBtJF0qDkGghOeiehwGobytDRRCd4i7 HHjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=23jPYeIHxkO0ujsGD7eYlRbwJShWG3r7UKIREhK5bgw=; b=c+4zRkfd3Vf6vnRKVMdRfKPNCWkcJDDDfy3cIjYPiTd39OMdJeZD1Pyzr7ltlCsQKx 7BmhmS09EnuI5N6PqSO+NvObquVpNRAZIPCggtVULmClxP1WLArNy/RIJrE9fk1oV2ah 2kalgpnYie3+pxjIsHAXDX8EiAouYufMroUn4SoANtoptdSx1BmaPPGz5Rw5+quJ8Do8 lGxmE6ihw+dtTOetGyTedvoXgwDpw3F+V8TyvBAbanxmbUMnYQihZgT3C8/sTFzTi6NG LfOVjFZ7Kv1bY2Gka2xItqa/wsmmk29414bv4QOXGCCbUYMaCIAU/m0SOGVfjbOaCwQk SKSQ== X-Gm-Message-State: AGi0PuZaHtr+PQ1KtMJjoD1Jigx5y7x2yvXFD/GOMU6AFf/1No6NNHSK 2LEPwXbdM+PvOGRxWRFE5zLWfhcBSg1i3NaxzJJw X-Received: by 2002:a17:906:29c4:: with SMTP id y4mr3965185eje.95.1588349865367; Fri, 01 May 2020 09:17:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Paul Moore Date: Fri, 1 May 2020 12:17:33 -0400 Message-ID: Subject: Re: [GIT PULL] SELinux fixes for v5.7 (#2) To: Linus Torvalds Cc: selinux@vger.kernel.org, LSM List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 30, 2020 at 7:43 PM Linus Torvalds wrote: > On Thu, Apr 30, 2020 at 2:24 PM Paul Moore wrote: > > > > Two more SELinux patches to fix problems in the v5.7-rcX releases. > > Wei Yongjun's patch fixes a return code in an error path, and my patch > > fixes a problem where we were not correctly applying access controls > > to all of the netlink messages in the netlink_send LSM hook. > > Side note: could we plan on (not for 5.7, but future) moving the "for > each message" part of that patch into the generic security layer (ie > security_netlink_send()), so that if/when other security subsystems > start doing that netlink thing, they won't have to duplicate that > code? > > Obviously the "for each message" thing should only be done if there is > any security hook at all.. > > Right now selinux is the only one that does this, so there's no > duplication of effort, but it seems a mistake to do this at the > low-level security level. > > Or is there some fundamental reason why a security hook would want to > look at a single skb rather than the individual messages? Off the top of my head I can't think of why a LSM would want to look only at the skb instead of the individual netlink messages. I suppose if that ever becomes an issue we could always pass the skb to the hook along with the nlmsghdr, and the LSM would just need to deal with being called multiple times for the same skb. Another option might be to give the LSM the option of registering one of two hooks for the netlink_send hook; one type of hook would behave the same as the hook does now, the other type would be called once for each message in the skb. Although this second option seems like a lot of extra complexity for a questionable advantage, especially since only SELinux is using the hook at the moment and we can easily change the hook without breaking things. It's also worth mentioning that we've always tried to keep the hook layer (the stuff in security/security.c) relatively thin, but that's a battle we've been slowly losing over time. Moving the skb/nlmsghdr processing into security_netlink_send() seems reasonable given some of the other hooks. Regardless, I'll work on something for an upcoming merge window, stay tuned. -- paul moore www.paul-moore.com