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;
From:   TongZhang <ztong@vt.edu>
Content-Type: text/plain;
        charset=us-ascii
Content-Transfer-Encoding: 8BIT
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Leaking Path in XFS's ioctl interface(missing LSM check)
Message-Id: <5EF0D46A-C098-4B51-AD13-225FFCA35D4C@vt.edu>
Date:   Tue, 25 Sep 2018 20:51:50 -0400
Cc:     linux-xfs@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        linux-security-module@vger.kernel.org,
        Wenbo Shen <shenwenbosmile@gmail.com>
To:     darrick.wong@oracle.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.

see the original post below:

>We noticed a use of vfs_readlink() in xfs_file_ioctl(), which should have been checked by 
>security_inode_readlink().
>The callgraph is:
>	xfs_file_ioctl()->xfs_readlink_by_handle()->vfs_readlink()
>
>This path allows user to do things similar to SyS_readlinkat(), and the parameters
>are user controllable.

security_inode_readlink() is not used inside vfs_readlink()

- Tong