public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Salyzyn <salyzyn@android.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: linux-kernel@vger.kernel.org, Miklos Szeredi <miklos@szeredi.hu>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-unionfs@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: overlayfs: caller_credentials option bypass creator_cred
Date: Mon, 18 Jun 2018 12:18:25 -0700	[thread overview]
Message-ID: <f141f883-0dbd-10ea-83b9-a1b38119b0c5@android.com> (raw)
In-Reply-To: <20180618185448.GA8749@redhat.com>

On 06/18/2018 11:54 AM, Vivek Goyal wrote:
> On Mon, Jun 18, 2018 at 08:42:15AM -0700, Mark Salyzyn wrote:
>> All accesses to the lower filesystems reference the creator (mount)
>> and not the source context.  This is a security issue.
> Can you elaborate with an example that how this is a security issue.
> mounter's check is in addition to caller's check. So we have two
> checks in ovl_permission(). overlay inode gets the credentials from
> underlying inode and we first check if caller is allowed to the
> operation and if that's allowed, then we check if mounter is allowed
> to do the operation.
init which does the mount and represents the creator_cred which is 
granted a restricted MAC to do just what it needs to do, eg mount, but 
not be able to access the files. The caller comes in and is rejected 
because init domain is not allowed, even though the caller's domain is. 
MAC does not require overlap in privileges between the creator and the user.

-- Mark

  reply	other threads:[~2018-06-18 19:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 15:42 overlayfs: caller_credentials option bypass creator_cred Mark Salyzyn
2018-06-18 18:54 ` Vivek Goyal
2018-06-18 19:18   ` Mark Salyzyn [this message]
2018-06-18 19:43     ` Vivek Goyal
2018-06-18 21:59       ` Mark Salyzyn
2018-06-19 14:36         ` Vivek Goyal
2018-06-20 15:28           ` Mark Salyzyn
2018-06-18 18:57 ` kbuild test robot

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=f141f883-0dbd-10ea-83b9-a1b38119b0c5@android.com \
    --to=salyzyn@android.com \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox