Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp164942imm; Tue, 25 Sep 2018 18:34:05 -0700 (PDT) X-Google-Smtp-Source: ACcGV63oKWF87qmaajlhLNoTXQKXz04TOFfMIZ2YU9K25hTBGTCK8xchwNvrmje+GyJRMXRFYtB7 X-Received: by 2002:a62:c502:: with SMTP id j2-v6mr3770673pfg.194.1537925645467; Tue, 25 Sep 2018 18:34:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537925645; cv=none; d=google.com; s=arc-20160816; b=mrw9ltAD6CuDruccZlfBqCPR8TYG64C7cJatvMyxCOGySQLH59QefjZ7cyOTLhqc9+ 58QuyyQ4e/UKwswfRF53h/jPUC4M+KkdR77iBiSW2qypqp8QjxzMEoth95WECgzTliEL Vy0NQh+WoduySl9wa2/AvI+F6sG9NR3DuFcd/ycy+hQIkGP2EGV3RhsH9Y6R8IQTaeAB +CXEIvvgXl7slY2A4+xT2euUoRv5M5w9KzwEuSlyTC05rjrb9D+cavdfXhoLp7YuuuQZ B/UxWU5ShIca/XhsV0ccb9rn58qNCaapDohaX+7ibF71W+tCF3skTiop69aTcNAUOeNP Gwwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ntP6J/EP30/cqo1ODxSh0n4xzngkHCNRUiL6FqZ21Ok=; b=sKfXoZVQib7m0hen3fNruzMRr+VcQ/p4H/dR1UFXENzQPbKGioGzDCzHEfIU30q8YP 4y4/fcDWQs9hjKuyASqixV+TMAlISqoTaBx0EhgFbuIAgV7JE3ymnjZAMObXvz/BBYjI rW/VdfwqqNgRMVudCc74akpCeGEysdJeWxeleCCGeG5pSeIPlHWf/mEVCWagVE5wtvJD DyxMSyOH9eZrRr6EEc5fYf2L7AKSXbM78RjG3Rp9UHxDk1h1Rz0I6Pfu5EZuM3SlqGX/ cFDwLRyjTdZBPaCW2x1BUSQ+zz9MtKR0a+ilw+g2hrsm+riFnRKMwkAVSUO6jXbT0rtF HGNw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 137-v6si3578173pfb.45.2018.09.25.18.33.36; Tue, 25 Sep 2018 18:34:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727049AbeIZHnv (ORCPT + 99 others); Wed, 26 Sep 2018 03:43:51 -0400 Received: from ipmail06.adl6.internode.on.net ([150.101.137.145]:40671 "EHLO ipmail06.adl6.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726596AbeIZHnu (ORCPT ); Wed, 26 Sep 2018 03:43:50 -0400 Received: from ppp59-167-129-252.static.internode.on.net (HELO dastard) ([59.167.129.252]) by ipmail06.adl6.internode.on.net with ESMTP; 26 Sep 2018 11:03:29 +0930 Received: from dave by dastard with local (Exim 4.80) (envelope-from ) id 1g4yhl-0006XV-4z; Wed, 26 Sep 2018 11:33:29 +1000 Date: Wed, 26 Sep 2018 11:33:29 +1000 From: Dave Chinner To: TongZhang Cc: darrick.wong@oracle.com, linux-xfs@vger.kernel.org, LKML , linux-security-module@vger.kernel.org, Wenbo Shen Subject: Re: Leaking Path in XFS's ioctl interface(missing LSM check) Message-ID: <20180926013329.GD31060@dastard> References: <5EF0D46A-C098-4B51-AD13-225FFCA35D4C@vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EF0D46A-C098-4B51-AD13-225FFCA35D4C@vt.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 25, 2018 at 08:51:50PM -0400, TongZhang wrote: > Hi, > > I'm bringing up this issue again to let of LSM developers know the situation, and would like to know your thoughts. > Several weeks ago I sent an email to the security list to discuss the issue where > XFS's ioctl interface can do things like vfs_readlink without asking LSM's > permission, which we think is kind of weird and this kind of operation should be > audited by LSM. These aren't user interfaces. They are filesystem maintenance and extension interfaces. They are intended for low level filesystem utilities that require complete, unrestricted access to the underlying filesystem via holding CAP_SYSADMIN in the initns. i.e. they are used to perform filesystem maintenance and extension operations that need to be completely invisible to users from userspace. e.g. online file defragmentation (xfs_fsr), data migration (e.g. HSM products), efficient backup of data (xfsdump), metadata and data scrubbing, online repair, etc. IOWs, I really don't think these interfaces are something the LSMs should be trying to intercept or audit, because they are essentially internal filesystem interfaces used by trusted code and not general user application facing APIs. Cheers, Dave. -- Dave Chinner david@fromorbit.com