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=-7.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 CA7CBC11F67 for ; Tue, 29 Jun 2021 16:35:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B1C9061DCB for ; Tue, 29 Jun 2021 16:35:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233299AbhF2Qhg (ORCPT ); Tue, 29 Jun 2021 12:37:36 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:47749 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233161AbhF2Qhf (ORCPT ); Tue, 29 Jun 2021 12:37:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1624984508; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qFtEvrlVui7BaqyBqVH/Nri0P4QA4rILRLxREoawxLs=; b=OtguBL2spcyeM5dPoGYELhuig4h90UCVzmbgK5tCyhCXcrv683eH3dm5YOYSq/KLQUNfJH lM0Lf5iHZTNah98uT3c3LkD2T4PHvPdk6SnVu8J3UbA9756ycS4xc26cpT0sXCvGkEABuE yVAlAIlx51YkjLgPt4csXhsR4vIB348= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-94-JFfAngmYM7iVfbzk8vpftw-1; Tue, 29 Jun 2021 12:35:06 -0400 X-MC-Unique: JFfAngmYM7iVfbzk8vpftw-1 Received: by mail-wr1-f71.google.com with SMTP id d9-20020adffbc90000b029011a3b249b10so6104622wrs.3 for ; Tue, 29 Jun 2021 09:35:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qFtEvrlVui7BaqyBqVH/Nri0P4QA4rILRLxREoawxLs=; b=dn+C6W546m4lan4JTE+I+98uFIoj4/f9LNpLhEArDE+HTvc1itOe3asPEZZAq+RZpE dcQSI9t5qHgVRzkEGRjUyehl8AwG1nYO4UHGG85zUnsRhXRAONQmrP3tiBgz/7IUgt2Q a5/VC/vTH7p6oEkiYQ2P8Jj2VTgx4ruCsEddX/ts7ouTUM8iXnVWWkSXzTX1pBYSghfl hhlEheUiH0h+lE1Gcjwkc8nEot+pWNAOlOClTs7mi4oc+4Q3SmlPBIxKeqixTF4vyH3X U9a6jDCQoXtuR+bx0haZAFJOIsE4ds+lpayFGCHAeM6axHJ7cN5j94tVpQUfRR0eV80b JD2A== X-Gm-Message-State: AOAM5328ehVXcqT7erhIimWeq0HEY0/BFaXbnajC5Xq9iLzFcOI97gVb /txHqxbVQwQxWUTWa1b8IVGa/+qSYlgbYhezYEqgUspr7NdINGjAyGWe8dD7GQvBI4GTyp3OW/C MjL75NgnBUQXiJBr0mAa8z0bbJHscKtsMHYM/ X-Received: by 2002:a05:600c:214b:: with SMTP id v11mr6664204wml.46.1624984505138; Tue, 29 Jun 2021 09:35:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbXpe6YhaxmyBREWJcgIymhFJ1te792D2kTWPT4Yam7vgoBla33uYBYbd6hpfHa5vYENMtew== X-Received: by 2002:a05:600c:214b:: with SMTP id v11mr6664187wml.46.1624984504942; Tue, 29 Jun 2021 09:35:04 -0700 (PDT) Received: from work-vm (cpc109021-salf6-2-0-cust453.10-2.cable.virginm.net. [82.29.237.198]) by smtp.gmail.com with ESMTPSA id f2sm9166880wrd.64.2021.06.29.09.35.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Jun 2021 09:35:04 -0700 (PDT) Date: Tue, 29 Jun 2021 17:35:02 +0100 From: "Dr. David Alan Gilbert" To: Casey Schaufler Cc: Vivek Goyal , dwalsh@redhat.com, "Schaufler, Casey" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "viro@zeniv.linux.org.uk" , "virtio-fs@redhat.com" , "berrange@redhat.com" , linux-security-module , "selinux@vger.kernel.org" Subject: Re: [RFC PATCH 0/1] xattr: Allow user.* xattr on symlink/special files if caller has CAP_SYS_RESOURCE Message-ID: References: <20210628131708.GA1803896@redhat.com> <1b446468-dcf8-9e21-58d3-c032686eeee5@redhat.com> <5d8f033c-eba2-7a8b-f19a-1005bbb615ea@schaufler-ca.com> <20210629152007.GC5231@redhat.com> <78663f5c-d2fd-747a-48e3-0c5fd8b40332@schaufler-ca.com> MIME-Version: 1.0 In-Reply-To: <78663f5c-d2fd-747a-48e3-0c5fd8b40332@schaufler-ca.com> User-Agent: Mutt/2.0.7 (2021-05-04) Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dgilbert@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Precedence: bulk List-ID: * Casey Schaufler (casey@schaufler-ca.com) wrote: > On 6/29/2021 8:20 AM, Vivek Goyal wrote: > > On Tue, Jun 29, 2021 at 07:38:15AM -0700, Casey Schaufler wrote: > > > > [..] > >>>>>> User xattrs are less protected than security xattrs. You are exposing the > >>>>>> security xattrs on the guest to the possible whims of a malicious, unprivileged > >>>>>> actor on the host. All it needs is the right UID. > >>>>> Yep, we realise that; but when you're mainly interested in making sure > >>>>> the guest can't attack the host, that's less worrying. > >>>> That's uncomfortable. > >>> Why exactly? > >> If a mechanism is designed with a known vulnerability you > >> fail your validation/evaluation efforts. > > We are working with the constraint that shared directory should not be > > accessible to unpriviliged users on host. And with that constraint, what > > you are referring to is not a vulnerability. > > Sure, that's quite reasonable for your use case. It doesn't mean > that the vulnerability doesn't exist, it means you've mitigated it. > > > >> Your mechanism is > >> less general because other potential use cases may not be > >> as cavalier about the vulnerability. > > Prefixing xattrs with "user.virtiofsd" is just one of the options. > > virtiofsd has the capability to prefix "trusted.virtiofsd" as well. > > We have not chosen that because we don't want to give it CAP_SYS_ADMIN. > > > > So other use cases which don't like prefixing "user.virtiofsd", can > > give CAP_SYS_ADMIN and work with it. > > > >> I think that you can > >> approach this differently, get a solution that does everything > >> you want, and avoid the known problem. > > What's the solution? Are you referring to using "trusted.*" instead? But > > that has its own problem of giving CAP_SYS_ADMIN to virtiofsd. > > I'm coming to the conclusion that xattr namespaces, analogous > to user namespaces, are the correct solution. They generalize > for multiple filesystem and LSM use cases. The use of namespaces > is well understood, especially in the container community. It > looks to me as if it would address your use case swimmingly. Yeh; although the details of getting the semantics right is tricky; in particular, the stuff which clears capabilitiies/setuid/etc on writes - should it clear xattrs that represent capabilities? If the host performs a write, should it clear mapped xattrs capabilities? If the namespace performs a write should it clear just the mapped ones or the host ones as well? Our virtiofsd code performs acrobatics to make sure they get cleared on write that are painful. Dave > > > > Thanks > > Vivek > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK