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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 5E173C10DCE for ; Tue, 10 Mar 2020 21:51:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F3DD2071B for ; Tue, 10 Mar 2020 21:51:06 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="ML2h3mAT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726283AbgCJVvF (ORCPT ); Tue, 10 Mar 2020 17:51:05 -0400 Received: from mail-ot1-f65.google.com ([209.85.210.65]:34765 "EHLO mail-ot1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726273AbgCJVvF (ORCPT ); Tue, 10 Mar 2020 17:51:05 -0400 Received: by mail-ot1-f65.google.com with SMTP id j16so14788709otl.1 for ; Tue, 10 Mar 2020 14:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vb0GLcs/8L01cTZ3HReaJOKCCqFsvClKHIQrRrGWG3I=; b=ML2h3mATLzke2m39a1Y6P/zDeHMxWqmWXR8CmeCANV0lcaQJmDMP4U3tgRYj3VwNVk gcrsdaOTXdOK+JjqpLxko+kEbnGIn7QupEmi+2Q0b4vwqC6coa38rR0r7QcCru31DAfk sP5TSdEzlau5ApuVktDVZXO2kqn+tioqibI+YdajtqBI/IN2FQIVXJjbMrmTR6N8aagK 4bYw66E+LCk5utYxoMeGj/mgh0bXybW9Hy21qFbJP8VzcWirKwIuqM4fg53vOIcf2M5G 457LG5EtugTnBxKo2TqABdeUV2BIWYtxrAYSp56R1HBngCTQ7tFbkZP+oMTR4otrECVK bGtg== 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=Vb0GLcs/8L01cTZ3HReaJOKCCqFsvClKHIQrRrGWG3I=; b=GIgUfiZXmXuqptDte2Y2opB1QLI9SRyHua6ESNP/g09zXV7hREth3RZL10IB+fBF+K XyqaMigLpMiNrs+15JrT24Ko5ds9KorNCgFRJTUBo/+Jj6jlMOZcg6wOlliGHrzFrG+O kjXSHG+6yYvr2QFd7tmJIVJP3NrflIAi1QFRNXqIz0ecGgpAKamlkjeUlDCCkbzrJlHh 2a6QW53QXAitrdc8Jyw4OJh6P1f9mi0Psge+nuDJGT4lxQswvJrKzNNgA3ybhrH1Ni1v CW1VlYghhh47X8tuwe+Cdcj/pQJUl11Fqrq341P68A6cLoVXsfQUxoJy+UPUY6KMVtWW TpjA== X-Gm-Message-State: ANhLgQ2Pz1E0/w2QYARkhpoF2BJ+gnKV9AuNYJY7ITjC90vHHflBybG+ 2qo9W3GAtwUHe7uCD06oZnFG4cFtS5RCQIFNy0gK+A== X-Google-Smtp-Source: ADFU+vv6rIwq0naQzaPUTbSTkQPR9MrTSMoZs8D8+Kw1FxXqF+vvTQ6t7/pUXhQZwCfMKjxzfvYNNNcfLsXZgyFIH1w= X-Received: by 2002:a9d:2028:: with SMTP id n37mr19373893ota.127.1583877064482; Tue, 10 Mar 2020 14:51:04 -0700 (PDT) MIME-Version: 1.0 References: <20200213194157.5877-1-sds@tycho.nsa.gov> In-Reply-To: From: Daniel Colascione Date: Tue, 10 Mar 2020 14:50:27 -0700 Message-ID: Subject: Re: [RFC PATCH] security,anon_inodes,kvm: enable security support for anon inodes To: Stephen Smalley Cc: Casey Schaufler , Sandeep Patil , Paul Moore , LSM List , Linux FS Devel , Al Viro , SElinux list , kvm@vger.kernel.org, Nick Kralevich , Stephen Smalley 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 Tue, Mar 10, 2020 at 11:25 AM Stephen Smalley wrote: > > On Tue, Mar 10, 2020 at 2:11 PM Daniel Colascione wrote: > > > > On Thu, Feb 20, 2020 at 10:50 AM Daniel Colascione wrote: > > > > > > On Thu, Feb 20, 2020 at 10:11 AM Casey Schaufler wrote: > > > > > > > > On 2/17/2020 4:14 PM, Paul Moore wrote: > > > > > On Thu, Feb 13, 2020 at 2:41 PM Stephen Smalley wrote: > > > > >> Add support for labeling and controlling access to files attached to anon > > > > >> inodes. Introduce extended interfaces for creating such files to permit > > > > >> passing a related file as an input to decide how to label the anon > > > > >> inode. Define a security hook for initializing the anon inode security > > > > >> attributes. Security attributes are either inherited from a related file > > > > >> or determined based on some combination of the creating task and policy > > > > >> (in the case of SELinux, using type_transition rules). As an > > > > >> example user of the inheritance support, convert kvm to use the new > > > > >> interface for passing the related file so that the anon inode can inherit > > > > >> the security attributes of /dev/kvm and provide consistent access control > > > > >> for subsequent ioctl operations. Other users of anon inodes, including > > > > >> userfaultfd, will default to the transition-based mechanism instead. > > > > >> > > > > >> Compared to the series in > > > > >> https://lore.kernel.org/selinux/20200211225547.235083-1-dancol@google.com/, > > > > >> this approach differs in that it does not require creation of a separate > > > > >> anonymous inode for each file (instead storing the per-instance security > > > > >> information in the file security blob), it applies labeling and control > > > > >> to all users of anonymous inodes rather than requiring opt-in via a new > > > > >> flag, it supports labeling based on a related inode if provided, > > > > >> it relies on type transitions to compute the label of the anon inode > > > > >> when there is no related inode, and it does not require introducing a new > > > > >> security class for each user of anonymous inodes. > > > > >> > > > > >> On the other hand, the approach in this patch does expose the name passed > > > > >> by the creator of the anon inode to the policy (an indirect mapping could > > > > >> be provided within SELinux if these names aren't considered to be stable), > > > > >> requires the definition of type_transition rules to distinguish userfaultfd > > > > >> inodes from proc inodes based on type since they share the same class, > > > > >> doesn't support denying the creation of anonymous inodes (making the hook > > > > >> added by this patch return something other than void is problematic due to > > > > >> it being called after the file is already allocated and error handling in > > > > >> the callers can't presently account for this scenario and end up calling > > > > >> release methods multiple times), and may be more expensive > > > > >> (security_transition_sid overhead on each anon inode allocation). > > > > >> > > > > >> We are primarily posting this RFC patch now so that the two different > > > > >> approaches can be concretely compared. We anticipate a hybrid of the > > > > >> two approaches being the likely outcome in the end. In particular > > > > >> if support for allocating a separate inode for each of these files > > > > >> is acceptable, then we would favor storing the security information > > > > >> in the inode security blob and using it instead of the file security > > > > >> blob. > > > > > Bringing this back up in hopes of attracting some attention from the > > > > > fs-devel crowd and Al. As Stephen already mentioned, from a SELinux > > > > > perspective we would prefer to attach the security blob to the inode > > > > > as opposed to the file struct; does anyone have any objections to > > > > > that? > > > > > > > > Sorry for the delay - been sick the past few days. > > > > > > > > I agree that the inode is a better place than the file for information > > > > about the inode. This is especially true for Smack, which uses > > > > multiple extended attributes in some cases. I don't believe that any > > > > except the access label will be relevant to anonymous inodes, but > > > > I can imagine security modules with policies that would. > > > > > > > > I am always an advocate of full xattr support. It goes a long > > > > way in reducing the number and complexity of special case interfaces. > > > > > > It sounds like we have broad consensus on using the inode to hold > > > security information, implying that anon_inodes should create new > > > inodes. Do any of the VFS people want to object? > > > > Ping? > > I'd recommend refreshing your patch series to incorporate feedback on > the previous version and re-post, > including viro and linux-fsdevel on the cc, and see if they have any > comments on it. I don't think there's anything in the patch series that needs to change right now. AFAICT, we're still just waiting on comment from the VFS people, who should be on this thread. Did I miss something?