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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C6D95C433EF for ; Mon, 7 Feb 2022 14:14:26 +0000 (UTC) Received: from localhost ([::1]:53560 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nH4mf-00079G-RV for qemu-devel@archiver.kernel.org; Mon, 07 Feb 2022 09:14:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nH46D-0005Je-76 for qemu-devel@nongnu.org; Mon, 07 Feb 2022 08:30:38 -0500 Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]:23687) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nH466-0003hm-Ds for qemu-devel@nongnu.org; Mon, 07 Feb 2022 08:30:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644240623; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lwzPoapuyhc25NLKywFxhw8IDnlXhMCXjHD+E2jBF1Q=; b=WwAd02Blv/CKqrYsWoKQOSyY5qZNWcG0kgfyOBeiHE2/JdeLeqe7HPVaq2F3+vMghKMIPP E8KVxY3sTuTpw1l/caJaYvbr8vmhwT85WrbLmUArljNStPPd4vOUzs0FQUbpgK+TkJmodk 5rYoihgIhUSTXIHJq3FUA0AN8zFwXrY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-655-tStlBrk4Nyea1kEDstKxqg-1; Mon, 07 Feb 2022 08:30:21 -0500 X-MC-Unique: tStlBrk4Nyea1kEDstKxqg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AD51B18982A4 for ; Mon, 7 Feb 2022 13:30:20 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.143]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4FFC974E9A; Mon, 7 Feb 2022 13:30:19 +0000 (UTC) Date: Mon, 7 Feb 2022 13:30:16 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Vivek Goyal Subject: Re: [PATCH v5 0/9] virtiofsd: Add support for file security context at file creation Message-ID: References: <20220202193935.268777-1-vgoyal@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.1.5 (2021-12-30) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=170.10.129.124; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= Cc: virtio-fs@redhat.com, mszeredi@redhat.com, qemu-devel@nongnu.org, dgilbert@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Mon, Feb 07, 2022 at 08:24:08AM -0500, Vivek Goyal wrote: > On Mon, Feb 07, 2022 at 01:05:16PM +0000, Daniel P. Berrangé wrote: > > On Wed, Feb 02, 2022 at 02:39:26PM -0500, Vivek Goyal wrote: > > > Hi, > > > > > > This is V5 of the patches. I posted V4 here. > > > > > > https://listman.redhat.com/archives/virtio-fs/2022-January/msg00041.html > > > > > > These will allow us to support SELinux with virtiofs. This will send > > > SELinux context at file creation to server and server can set it on > > > file. > > > > I've not entirely figured it out from the code, so easier for me > > to ask... > > > > How is the SELinux labelled stored on the host side ? It is stored > > directly in the security.* xattr namespace, or is is subject to > > xattr remapping that virtiofsd already supports. > > > > Storing directly means virtiofsd has to run in an essentially > > unconfined context, to let it do arbitrary changes on security.* > > xattrs without being blocked by SELinux) and has risk that guest > > initiated changes can open holes in the host confinement if > > the exported FS is generally visible to processes on the host. > > > > > > Using remapping lets virtiofsd be strictly isolated by SELinux > > policy on the host, and ensures that guest context changes > > can't open up holes in the host. > > > > Both are valid use cases, so I'd ultimately expect us to want > > to support both, but my preference for a "default" behaviour > > would be remapping. > > I am expecting users to configure virtiofsd to remap "security.selinux" > to "trusted.virtiofsd.security.selinux" and that will allow guest > and host security selinux to co-exist and allow separate SELinux policies > for guest and host. > > I agree that my preference for a default behavior is remapping as well. > That makes most sense. > > One downside of mapping to trusted namespace is that it requires > CAP_SYS_ADMIN for virtiofsd. > > Having said that, these patches don't enforce the remapping default. That > has to come from the user because it also needs to be given CAP_SYS_ADMIN. > So out of box default is no remapping and passthrough SELinux. Ok, that all makes sense then. My only suggestion then is to put something more explicit in the man page docs to highlight the implications / interaction beteen the new command line options for labelling and the likely need for remapping security.* Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|