Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751047AbeAOVAe (ORCPT + 1 other); Mon, 15 Jan 2018 16:00:34 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:39652 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750799AbeAOVAd (ORCPT ); Mon, 15 Jan 2018 16:00:33 -0500 Subject: Re: [PATCH 0/2] turn on force option for FUSE in builtin policies From: Mimi Zohar To: Christoph Hellwig Cc: Dongsu Park , linux-kernel@vger.kernel.org, Alban Crequy , Miklos Szeredi , Seth Forshee , linux-integrity Date: Mon, 15 Jan 2018 16:00:23 -0500 In-Reply-To: <20180115171825.GA28088@infradead.org> References: <20180115144804.GA28856@infradead.org> <1516033961.6607.18.camel@linux.vnet.ibm.com> <20180115171825.GA28088@infradead.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18011521-0040-0000-0000-00000425094D X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18011521-0041-0000-0000-000020C872FE Message-Id: <1516050023.6607.57.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-15_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1801150295 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Mon, 2018-01-15 at 09:18 -0800, Christoph Hellwig wrote: > On Mon, Jan 15, 2018 at 11:32:41AM -0500, Mimi Zohar wrote: > > For XFS, which considers fsmagic numbers private to the filesystem, > > *always* using the fsmagic number is wrong.  As to whether this is > > true for other filesystems is unclear.  IMA policies have been defined > > in terms of fsmagic numbers for a long time.  fsmagic numbers were > > moved from the filesystems to magic.h for this purpose.  Someone would > > have complained earlier if it is always wrong. > >   > > I just posted a patch titled "ima: define new policy condition based > > on the filesystem name" to allow policies to be defined in terms of > > the i_sb->s_type->name. > > ima has no business looking at either the name _or_ the magic number. There are a couple of reasons to define policies in terms of the filesystem name or magic numbers. One example is pseudo filesystems (eg. pseudo filesystems - sysfs, securitys, cgroups, selinuxfs, etc).  These should never be measured or appraised. The current example is fuse and remote file systems.  These should always be re-evaluated and not rely on cached file info. If not based on IMA policy, what do you propose?  Define new SB_ flags  to indicate IMA disabled/enabled (eg. SB_IMA) and nocaching (eg. SB_IMA_NOCACHE)? Mimi