From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bombadil.infradead.org ([198.137.202.9]:58742 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1756071AbcLVJHA (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Thu, 22 Dec 2016 04:07:00 -0500
Date: Thu, 22 Dec 2016 01:06:52 -0800
From: Christoph Hellwig <hch@infradead.org>
To: =?iso-8859-1?Q?Micka=EBl_Sala=FCn?= <mic@digikod.net>
Cc: Al Viro <viro@ZenIV.linux.org.uk>,
        Casey Schaufler <casey@schaufler-ca.com>,
        linux-kernel@vger.kernel.org,
        Andreas Gruenbacher <agruenba@redhat.com>,
        Andy Lutomirski <luto@amacapital.net>,
        Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
        Eric Paris <eparis@parisplace.org>,
        James Morris <james.l.morris@oracle.com>,
        John Johansen <john.johansen@canonical.com>,
        Kees Cook <keescook@chromium.org>,
        Kentaro Takeda <takedakn@nttdata.co.jp>,
        Mimi Zohar <zohar@linux.vnet.ibm.com>,
        Paul Moore <paul@paul-moore.com>,
        "Serge E . Hallyn" <serge@hallyn.com>,
        Stephen Smalley <sds@tycho.nsa.gov>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        Vivek Goyal <vgoyal@redhat.com>, linux-fsdevel@vger.kernel.org,
        linux-security-module@vger.kernel.org,
        Christoph Hellwig <hch@infradead.org>
Subject: Re: [PATCH v1] security: Add a new hook: inode_touch_atime
Message-ID: <20161222090652.GA8715@infradead.org>
References: <20161221231506.19800-1-mic@digikod.net>
 <f47921a9-bd93-34e4-bbc5-c9129d0c4426@schaufler-ca.com>
 <585B17E3.5040809@digikod.net>
 <20161222005725.GE1555@ZenIV.linux.org.uk>
 <585B95C2.5050801@digikod.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <585B95C2.5050801@digikod.net>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Dec 22, 2016 at 09:58:42AM +0100, Micka�l Sala�n wrote:
> Of course a read-only mount point can do the trick (except for anonymous
> inodes). However, a security policy (e.g. for SELinux) should not (and
> can't always) rely on mount options. For example, a security policy can
> come from a distro but they may not want to tie mount options with this
> policy. We may also not want a sandbox to being able to change mount
> options (even with user namespaces).
> 
> Being able to write (meta-)data, whereas a security policy said that
> it's not allowed, seems like a flaw in this policy. Moreover, modifying
> access time is an easy way to create cover-channels without any LSM
> being able to notice it.

A security policy must not mess with the readonly state of a file system
or mount, period.  You're overstepping your boundaries.