From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web09.15342.1608412576690159073 for ; Sat, 19 Dec 2020 13:16:17 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Odw5+Mhq; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1608412574; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=z3QZZzuLD6lW/8nQ5WCEQgJ3HRtYw5HADkplSGbyih4=; b=Odw5+Mhqik5MXQyWlDlPKSm+4vpIu1mJ79wuJbYOtikgx6USNOZiep/kfDUMNcEc+ddAW0 NGQ02vluKPJp4dIXYqvbJFLxqnXuvDK+IrWyTxOo3XBeDo2BG0wFeITwe5SgPuv2gEM22/ MdrArffq+10DTQvEINOWrmuJovBxhRk= 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-177-GZZtcEs8MXe5sY9MA2XYlg-1; Sat, 19 Dec 2020 16:16:11 -0500 X-MC-Unique: GZZtcEs8MXe5sY9MA2XYlg-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AC20E107ACF8; Sat, 19 Dec 2020 21:16:10 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-112-53.ams2.redhat.com [10.36.112.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 908D5106D5AC; Sat, 19 Dec 2020 21:16:02 +0000 (UTC) Subject: Re: [Virtio-fs] [edk2 PATCH 01/48] OvmfPkg: introduce VirtioFsDxe To: "Dr. David Alan Gilbert" , Ard Biesheuvel Cc: devel@edk2.groups.io, virtio-fs@redhat.com, Jordan Justen , =?UTF-8?Q?Philippe_Mathieu-Daud=c3=a9?= References: <20201216211125.19496-1-lersek@redhat.com> <20201216211125.19496-2-lersek@redhat.com> <57ec49d2-1540-f693-23ef-12a0cf217a81@arm.com> <20201218181335.GG2956@work-vm> From: "Laszlo Ersek" Message-ID: Date: Sat, 19 Dec 2020 22:16:01 +0100 MIME-Version: 1.0 In-Reply-To: <20201218181335.GG2956@work-vm> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit (I'm breaking my PTO rules for this, because writing this driver was a very intense experience for me, and it's not like I can put it out of my mind from a Friday to a Saturday, after waking with it and going to bed with it for three weeks... I just couldn't resist checking the mailing list archive, and then logging in.) On 12/18/20 19:13, Dr. David Alan Gilbert wrote: > * Ard Biesheuvel (ard.biesheuvel@arm.com) wrote: >> On 12/16/20 10:10 PM, Laszlo Ersek wrote: [...] >>> +# Permission Model of this driver: >>> +# >>> +# Regardless of the UID and GID values this driver send in the FUSE request >>> +# header, the daemon (that is, the Virtio Filesystem device) always acts with >>> +# root privileges on the host side. The only time the daemon considers said UID >>> +# and GID fields is when creating a new file or directory. Thus, the guest >>> +# driver cannot rely on the host for enforcing any file mode permissions, >>> +# regardless of the "personality" that the guest driver poses as, because >>> +# "root" on the host side ignores all file mode bits. >>> +# >>> +# Therefore the guest driver has to do its own permission checking, and use the >>> +# host-side file mode bits only as a kind of "metadata storage" or "reminder" >>> +# -- hopefully in a way that makes some sense on the host side too. >>> +# >> >> Can you please explain why this is safe? Or should virtio-fs only be >> used with guests that can be trusted with root privileges on the host? > > The daemon sandboxes itself and generally you only expose a private area > of a filesystem to the guest; i.e. a per-guest rootfs or temporary or > whatever. Stefan wrote a document about this: [PULL 059/111] virtiofsd: add security guide document https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05464.html some excerpts: > +Security Requirements > +===================== > +Guests have root access to the shared directory. This is necessary for root > +file systems on virtio-fs and similar use cases. and > +Deployment Best Practices > +========================= > +The shared directory should be a separate file system so that untrusted guests > +cannot cause a denial-of-service by using up all available inodes or exhausting > +free space. > + > +If the shared directory is also accessible from a host mount namespace, it is > +recommended to keep a parent directory with rwx------ permissions so that other > +users on the host are unable to access any setuid executables or device nodes > +in the shared directory. The `nosuid` and `nodev` mount options can also be > +used to prevent this issue. This document, originally proposed as "docs/tools/virtiofsd-security.rst", doesn't seem to have made it to the QEMU tree yet; it was put aside while a good location for it would be figured out. See this subthread under the v1 PULL: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05733.html and then see the PULL v2 changelog -- "drop the docs while we discuss where they should live": https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05780.html (If there have been developments in this area since then, I'm not aware of them; sorry if my info on the docs' location is out-of-date.) Thanks! Laszlo