From: Christoph Hellwig <hch@infradead.org>
To: "Mickaël Salaün" <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
Date: Thu, 22 Dec 2016 01:06:52 -0800 [thread overview]
Message-ID: <20161222090652.GA8715@infradead.org> (raw)
In-Reply-To: <585B95C2.5050801@digikod.net>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@infradead.org>
To: "Mickaël Salaün" <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
Date: Thu, 22 Dec 2016 01:06:52 -0800 [thread overview]
Message-ID: <20161222090652.GA8715@infradead.org> (raw)
In-Reply-To: <585B95C2.5050801@digikod.net>
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.
next prev parent reply other threads:[~2016-12-22 9:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-21 23:15 [PATCH v1] security: Add a new hook: inode_touch_atime Mickaël Salaün
2016-12-21 23:15 ` Mickaël Salaün
2016-12-21 23:33 ` Casey Schaufler
2016-12-22 0:01 ` Mickaël Salaün
2016-12-22 0:30 ` Casey Schaufler
2016-12-22 0:57 ` Al Viro
2016-12-22 0:57 ` Al Viro
2016-12-22 8:58 ` Mickaël Salaün
2016-12-22 9:06 ` Christoph Hellwig [this message]
2016-12-22 9:06 ` Christoph Hellwig
2016-12-22 6:25 ` Christoph Hellwig
2016-12-22 6:25 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161222090652.GA8715@infradead.org \
--to=hch@infradead.org \
--cc=agruenba@redhat.com \
--cc=casey@schaufler-ca.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eparis@parisplace.org \
--cc=james.l.morris@oracle.com \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mic@digikod.net \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=sds@tycho.nsa.gov \
--cc=serge@hallyn.com \
--cc=takedakn@nttdata.co.jp \
--cc=vgoyal@redhat.com \
--cc=viro@ZenIV.linux.org.uk \
--cc=zohar@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.