Re: [PATCH v1] security: Add a new hook: inode_touch_atime

From: "Mickaël Salaün" <mic@digikod.net>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: 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
Date: Thu, 22 Dec 2016 09:58:42 +0100	[thread overview]
Message-ID: <585B95C2.5050801@digikod.net> (raw)
In-Reply-To: <20161222005725.GE1555@ZenIV.linux.org.uk>

[-- Attachment #1.1: Type: text/plain, Size: 1390 bytes --]

On 22/12/2016 01:57, Al Viro wrote:
> On Thu, Dec 22, 2016 at 01:01:39AM +0100, Mickaël Salaün wrote:
> 
>> SELinux should be interested. This is useful to create sandboxes so
>> other LSM may be interested too
>>
>> I'm working on a new LSM and I would like this kind of hook to create a
>> real read-only environment.
> 
> What the...?  Have you noticed
>         if (!sb_start_write_trylock(inode->i_sb))
>                 return;
> 
>         if (__mnt_want_write(mnt) != 0)
>                 goto skip_update;
> in touch_atime()?  Just mount them read-only in your sandbox (on either
> level - both per-mountpoint and per-fs r/o will do) and be done
> with that; why bother with LSM when regular tools would suffice?
> 

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]