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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 615E5C433E1 for ; Fri, 19 Jun 2020 19:16:37 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2C71620809 for ; Fri, 19 Jun 2020 19:16:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AzS/16qd" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C71620809 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:34104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmMVA-0004yi-Dd for qemu-devel@archiver.kernel.org; Fri, 19 Jun 2020 15:16:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmMUT-0004RN-Jc for qemu-devel@nongnu.org; Fri, 19 Jun 2020 15:15:53 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:50127 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1jmMUR-00010z-Uz for qemu-devel@nongnu.org; Fri, 19 Jun 2020 15:15:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592594150; 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=t21k1U6S7U9WKM5QqQkL3iAtt4A8qkLHkkfB0i72AsI=; b=AzS/16qde7dBVsTNPl6xxYJkW1OfpEYSOFnej4Du4wKgNWkuCqPQOe8sey3oWodX5wzl5/ 8mXZ8INNvBpmw4xClQR/EvCRhIbv+SoacPlk6/WG+pNOJYl+hwa6TtxyelV2/WYxgzFntC TE/qRyePXZnLKngPHyDwtRbwWy0JjCU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-98-4nsCQTVRNBaYgLem4TwigQ-1; Fri, 19 Jun 2020 15:15:47 -0400 X-MC-Unique: 4nsCQTVRNBaYgLem4TwigQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9D32DBFC3; Fri, 19 Jun 2020 19:15:41 +0000 (UTC) Received: from horse.redhat.com (ovpn-114-35.rdu2.redhat.com [10.10.114.35]) by smtp.corp.redhat.com (Postfix) with ESMTP id 319D32AF4D; Fri, 19 Jun 2020 19:15:41 +0000 (UTC) Received: by horse.redhat.com (Postfix, from userid 10451) id AC260220390; Fri, 19 Jun 2020 15:15:40 -0400 (EDT) Date: Fri, 19 Jun 2020 15:15:40 -0400 From: Vivek Goyal To: Chirantan Ekbote Subject: Re: [Virtio-fs] [PATCH 0/2] virtiofsd: drop Linux capabilities(7) Message-ID: <20200619191540.GI3154@redhat.com> References: <20200416164907.244868-1-stefanha@redhat.com> <20200618190816.GD3814@redhat.com> <20200618191655.GI2769@work-vm> <20200618192717.GE3814@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=205.139.110.61; envelope-from=vgoyal@redhat.com; helo=us-smtp-delivery-1.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/19 02:45:39 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: virtio-fs-list , Miklos Szeredi , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Fri, Jun 19, 2020 at 01:46:20PM +0900, Chirantan Ekbote wrote: > On Fri, Jun 19, 2020 at 4:27 AM Vivek Goyal wrote: > > > > On Thu, Jun 18, 2020 at 08:16:55PM +0100, Dr. David Alan Gilbert wrote: > > > * Vivek Goyal (vgoyal@redhat.com) wrote: > > > > On Thu, Apr 16, 2020 at 05:49:05PM +0100, Stefan Hajnoczi wrote: > > > > > virtiofsd doesn't need of all Linux capabilities(7) available to root. Keep a > > > > > whitelisted set of capabilities that we require. This improves security in > > > > > case virtiofsd is compromised by making it hard for an attacker to gain further > > > > > access to the system. > > > > > > > > Hi Stefan, > > > > > > > > I just noticed that this patch set breaks overlayfs on top of virtiofs. > > > > > > > > overlayfs sets "trusted.overlay.*" and xattrs in trusted domain > > > > need CAP_SYS_ADMIN. > > > > > > Not just that but it needs CAP_SYS_ADMIN in the init namespace[1]. We > have the same problem. Our virtiofs process has CAP_SYS_ADMIN in a > user namespace and it cannot set any trusted or security xattrs. The > security xattrs check is at least namespace aware so you only need > CAP_SYS_ADMIN in the namespace that mounted the fs but that doesn't > help us much. > > We ended up working around it by prefixing "user.virtiofs." to the > xattr name[2], which has its own problems but there was pretty much no > chance that we would be able to give the fs device CAP_SYS_ADMIN in > the init namespace. Chirantan, So you ended up renaming all "trusted", "security" and "system" xattrs? Only "user" xattrs are complete passthrough? IOW, security.selinux will be renamed to user.virtiofs.security.selinux on host? Thanks Vivek