From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C3EDBC3A59B for ; Fri, 30 Aug 2019 21:46:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92F572342E for ; Fri, 30 Aug 2019 21:46:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=paul-moore-com.20150623.gappssmtp.com header.i=@paul-moore-com.20150623.gappssmtp.com header.b="aoFTsFCW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728242AbfH3Vqy (ORCPT ); Fri, 30 Aug 2019 17:46:54 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:39900 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728053AbfH3Vqy (ORCPT ); Fri, 30 Aug 2019 17:46:54 -0400 Received: by mail-lj1-f194.google.com with SMTP id j16so1578917ljg.6 for ; Fri, 30 Aug 2019 14:46:52 -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=h/IKEwtiMoZTtijwK84EjX+6xulxKmEOQTSwaaf+y48=; b=aoFTsFCWzMtsMdDPZj1Iv+ZXjcGyzvvosDEXplOewRaj+VHWw2zUfXIYkswbA6TzJG NWskcFkqaH33yD+gnvU6OO/RnyTek1/Exi1PL2s5XvzcF0WOzloSQDks895e3GD+I6Ru yfoGDqbh7NXYFS8NxLwN3aMItjNI4N4qw9p1GJVb527MIY+fAYqZihttFdD1lM1jTR/G XPyyDWKMXjWmZUab9jO0ywCx8EOyDfknhtAwoChxtu9Fkiw8rx0o98r68ncPLR1iFFGR pw7g9f+S0bTZTxxjffvpwIIAVsRK0jXWsL+MZHB+HRZFdOyfLgBxSb9Hefqrf9jS3bxq tfrA== 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=h/IKEwtiMoZTtijwK84EjX+6xulxKmEOQTSwaaf+y48=; b=W1qtmtySM2XCZcR5Go3ya6oyKJDDRzRE8B9rM6uK4k9qAl1JrFtYWte+x0pUTEwi0R ZFf3RKmhAi4BjpL8pwcSyKdvX9c8YIBrh9+n8GIWYWBqP5l0UB0YQGrtheDFzZa/v4qG /7WmXYrEV8M9r+SYL7KIN0fFjSfQFaMW8g3tjFSmV5SWrQ0ErPCG1mf2VmZKv9VQkofA 3Ed+52mpkeVJMGpuzw1AWSrGDNjbziBtuI1KkhEaJlxBvW3qaDlZFwUkonSdclU5TKJK ONWhpGL1+JajS1LALWpBzIXIHQh8ahj9Zm/h6IA1dyRDoaSd9aksLWRRlzgis1pIyQSp NJsA== X-Gm-Message-State: APjAAAUEulES8x/wTD6mewxVNqnyAbf6K/YEGyYKZduU/mcRYS+CzYMe iGQTjkMXm9HZmbp/pWKmU5RHao+4vKHxQRSR8PLM X-Google-Smtp-Source: APXvYqxirrtwxKydgvqj+iXwb2e01CWP4pG1x5kPYkURSbjtWQcwHoS1PGYLKIwllBMJ+BeSHOXr3+1+9uKQ3teRW3k= X-Received: by 2002:a05:651c:1111:: with SMTP id d17mr9377947ljo.87.1567201611994; Fri, 30 Aug 2019 14:46:51 -0700 (PDT) MIME-Version: 1.0 References: <20190821134547.96929-1-jeffv@google.com> <20190822.161913.326746900077543343.davem@davemloft.net> <20190829074516.GM29594@unicorn.suse.cz> In-Reply-To: <20190829074516.GM29594@unicorn.suse.cz> From: Paul Moore Date: Fri, 30 Aug 2019 17:46:40 -0400 Message-ID: Subject: Re: [PATCH 1/2] rtnetlink: gate MAC address with an LSM hook To: Michal Kubecek Cc: netdev@vger.kernel.org, Jeffrey Vander Stoep , David Miller , LSM List , selinux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: selinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: selinux@vger.kernel.org On Thu, Aug 29, 2019 at 3:45 AM Michal Kubecek wrote: > On Tue, Aug 27, 2019 at 04:47:04PM -0400, Paul Moore wrote: > > > > I'm also not a big fan of inserting the hook in rtnl_fill_ifinfo(); as > > presented it is way too specific for a LSM hook for me to be happy. > > However, I do agree that giving the LSMs some control over netlink > > messages makes sense. As others have pointed out, it's all a matter > > of where to place the hook. > > > > If we only care about netlink messages which leverage nlattrs I > > suppose one option that I haven't seen mentioned would be to place a > > hook in nla_put(). While it is a bit of an odd place for a hook, it > > would allow the LSM easy access to the skb and attribute type to make > > decisions, and all of the callers should already be checking the > > return code (although we would need to verify this). One notable > > drawback (not the only one) is that the hook is going to get hit > > multiple times for each message. > > For most messages, "multiple times" would mean tens, for many even > hundreds of calls. For each, you would have to check corresponding > socket (and possibly also genetlink header) to see which netlink based > protocol it is and often even parse existing part of the message to get > the context (because the same numeric attribute type can mean something > completely different if it appears in a nested attribute). > > Also, nla_put() (or rather __nla_put()) is not used for all attributes, > one may also use nla_reserve() and then compose the attribute date in > place. I never said it was a great idea, just an idea ;) Honestly I'm just trying to spur some discussion on this so we can hopefully arrive at a solution which allows a LSM to control kernel generated netlink messages that we can all accept. -- paul moore www.paul-moore.com