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.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 C78F4C54FD0 for ; Thu, 23 Apr 2020 15:38:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A7BB52075A for ; Thu, 23 Apr 2020 15:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587656290; bh=gNuSCC47zvyIpLuTBzO63qOyw2+XLh1hnmdTAhceGTg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=mEMuhrQTMkMD8fLzrkoSfOHXULUdzp5e8UIVkVukN/TDBc1utkAEN6uy9qhEh1G2G OC050uypNFqznnkPNDJW5iBFfgnd7+BExzzNCvQo4wffWTT3s9GFg513sbBZ7KDvFc 0CfiBJioSTLCALy8U3ckdvPHmyPEINm7NFnzvphg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729268AbgDWPiK (ORCPT ); Thu, 23 Apr 2020 11:38:10 -0400 Received: from mail.kernel.org ([198.145.29.99]:49886 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729231AbgDWPiJ (ORCPT ); Thu, 23 Apr 2020 11:38:09 -0400 Received: from gmail.com (unknown [104.132.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D2C872075A; Thu, 23 Apr 2020 15:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1587656289; bh=gNuSCC47zvyIpLuTBzO63qOyw2+XLh1hnmdTAhceGTg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QrUHkOjYuCDNFRZ/3MvnBxO4LKJWu+ajgOB6x5hkqksFy0HvGuqrS9hQ7dFIwIPsa EXCy+00IuxCWb82mhyt+L9lFP0PewiJL5mK7XkX11k1NWqJMzW1UHBq6MjAXJ0g9Dt ycxPmB92BIz1hXqOE10XcvM37SLAnpip0oJvAPYc= Date: Thu, 23 Apr 2020 08:38:07 -0700 From: Eric Biggers To: Chirantan Ekbote Cc: =Miklos Szeredi , linux-fsdevel@vger.kernel.org, Dylan Reid , Suleiman Souhlal , linux-fscrypt@vger.kernel.org Subject: Re: [PATCH] fuse: Mark fscrypt ioctls as unrestricted Message-ID: <20200423153807.GA205729@gmail.com> References: <20200423074706.107016-1-chirantan@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200423074706.107016-1-chirantan@chromium.org> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org [+Cc linux-fscrypt@vger.kernel.org] On Thu, Apr 23, 2020 at 04:47:06PM +0900, Chirantan Ekbote wrote: > The definitions for these 2 ioctls have been reversed: "get" is marked > as a write ioctl and "set" is marked as a read ioctl. Moreover, since > these are now part of the public kernel interface they can never be > fixed because fixing them might break userspace applications compiled > with the older headers. > > Since the fuse module strictly enforces the ioctl encodings, it will > reject any attempt by the fuse server to correctly implement these > ioctls. Instead, check if the process is trying to make one of these > ioctls and mark it unrestricted. This will allow the server to fix the > encoding by reading/writing the correct data. > > Signed-off-by: Chirantan Ekbote > --- > fs/fuse/file.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/fs/fuse/file.c b/fs/fuse/file.c > index 9d67b830fb7a2..9b6d993323d53 100644 > --- a/fs/fuse/file.c > +++ b/fs/fuse/file.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > static struct page **fuse_pages_alloc(unsigned int npages, gfp_t flags, > struct fuse_page_desc **desc) > @@ -2751,6 +2752,16 @@ long fuse_do_ioctl(struct file *file, unsigned int cmd, unsigned long arg, > > fuse_page_descs_length_init(ap.descs, 0, fc->max_pages); > > + /* > + * These commands are encoded backwards so it is literally impossible > + * for a fuse server to implement them. Instead, mark them unrestricted > + * so that the server can deal with the broken encoding itself. > + */ > + if (cmd == FS_IOC_GET_ENCRYPTION_POLICY || > + cmd == FS_IOC_SET_ENCRYPTION_POLICY) { > + flags |= FUSE_IOCTL_UNRESTRICTED; > + } Are there any security concerns with marking these ioctls unrestricted, as opposed to dealing with the payload in the kernel? Also, can you elaborate on why you need only these two specific ioctls? FS_IOC_GET_ENCRYPTION_POLICY_EX and FS_IOC_ADD_ENCRYPTION_KEY take a variable-length payload and thus are similarly incompatible with FUSE, right? I thought we had discussed that for your use case the ioctl you actually need isn't the above two, but rather FS_IOC_GET_ENCRYPTION_POLICY_EX. So I'm a bit confused by this patch. - Eric