All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miklos Szeredi <miklos@szeredi.hu>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	linux-kernel@vger.kernel.org,
	"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>,
	LSM <linux-security-module@vger.kernel.org>,
	Daniel J Walsh <dwalsh@redhat.com>,
	David Howells <dhowells@redhat.com>,
	pmoore@redhat.com, Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 5/5] overlayfs: Use vfs_getxattr_noperm() for real inode
Date: Wed, 6 Jul 2016 16:58:37 +0200	[thread overview]
Message-ID: <CAJfpegv6QnpFM-pPwAUtqYCHVP2f18htQj1TfcxQDFephXO23g@mail.gmail.com> (raw)
In-Reply-To: <20160706105408.GB6550@redhat.com>

On Wed, Jul 6, 2016 at 12:54 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
> On Wed, Jul 06, 2016 at 06:36:49AM +0200, Miklos Szeredi wrote:
>> On Tue, Jul 5, 2016 at 11:16 PM, Vivek Goyal <vgoyal@redhat.com> wrote:
>> > On Tue, Jul 05, 2016 at 01:29:39PM -0700, Casey Schaufler wrote:
>> >> On 7/5/2016 8:50 AM, Vivek Goyal wrote:
>> >> > ovl_getxattr() currently uses vfs_getxattr() on realinode. This fails
>> >> > if mounter does not have DAC/MAC permission to access getxattr.
>> >> >
>> >> > Specifically this becomes a problem when selinux is trying to initialize
>> >> > overlay inode and does ->getxattr(overlay_inode). A task might trigger
>> >> > initialization of overlay inode and we will access real inode xattr in the
>> >> > context of mounter and if mounter does not have permissions, then inode
>> >> > selinux context initialization fails and inode is labeled as unlabeled_t.
>> >> >
>> >> > One way to deal with it is to let SELinux do getxattr checks both on
>> >> > overlay inode and underlying inode and overlay can call vfs_getxattr_noperm()
>> >> > to make sure when selinux is trying to initialize label on inode, it does
>> >> > not go through checks on lower levels and initialization is successful.
>> >> > And after inode initialization, SELinux will make sure task has getatttr
>> >> > permission.
>> >> >
>> >> > One issue with this approach is that it does not work for directories as
>> >> > d_real() returns the overlay dentry for directories and not the underlying
>> >> > directory dentry.
>> >> >
>> >> > Another way to deal with it to introduce another function pointer in
>> >> > inode_operations, say getxattr_noperm(), which is responsible to get
>> >> > xattr without any checks. SELinux initialization code will call this
>> >> > first if it is available on inode. So user space code path will call
>> >> > ->getxattr() and that will go through checks and SELinux internal
>> >> > initialization will call ->getxattr_noperm() and that will not
>> >> > go through checks.
>> >> >
>> >> > For now, I am just converting ovl_getxattr() to get xattr without
>> >> > any checks on underlying inode. That means it is possible for
>> >> > a task to get xattr of a file/dir on lower/upper through overlay mount
>> >> > while it is not possible outside overlay mount.
>> >> >
>> >> > If this is a major concern, I can look into implementing getxattr_noperm().
>> >>
>> >> This is a major concern.
>> >
>> > Hmm.., In that case I will write patch to provide another inode operation
>> > getxattr_noperm() and a wrapper which falls back to getxattr() if noperm
>> > variant is not defined. That should take care of this issue.
>>
>> That's not going to fly.  A slighly better, but still quite ugly
>> solution would be to add a "flags" arg to the current ->getxattr()
>> callback indicating whether the caller wants permission checking
>> inside the call or not.
>>
>
> Ok, will try that.
>
>> But we already have the current->creds.  Can't that be used to control
>> the permission checking done by the callback?
>
> Sorry, did not get how to use current->creds to control permission
> checking.

I'm not sure about the details either.  But current->creds *is* the
context provided for the VFS and filesystems to check permissions.  It
might make sense to use that to indicate to overlayfs that permission
should not be checked.

Thanks,
Miklos

  reply	other threads:[~2016-07-06 14:58 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-05 15:50 [PATCH 0/5][RFC] Overlayfs SELinux Support Vivek Goyal
2016-07-05 15:50 ` [PATCH 1/5] security, overlayfs: provide copy up security hook for unioned files Vivek Goyal
2016-07-05 16:53   ` kbuild test robot
2016-07-05 16:53     ` kbuild test robot
2016-07-05 17:43     ` Vivek Goyal
2016-07-05 17:20   ` kbuild test robot
2016-07-05 17:20     ` kbuild test robot
2016-07-05 19:36   ` Casey Schaufler
2016-07-05 20:42     ` Vivek Goyal
2016-07-07 20:33     ` Vivek Goyal
2016-07-07 21:44       ` Casey Schaufler
2016-07-08  7:21         ` Miklos Szeredi
2016-07-08 12:45           ` Vivek Goyal
2016-07-08 13:42             ` Vivek Goyal
2016-07-08 15:34               ` Casey Schaufler
2016-07-05 21:35   ` Paul Moore
2016-07-05 21:52     ` Vivek Goyal
2016-07-05 22:03       ` Paul Moore
2016-07-05 15:50 ` [PATCH 2/5] security,overlayfs: Provide security hook for copy up of xattrs for overlay file Vivek Goyal
2016-07-05 20:22   ` Casey Schaufler
2016-07-05 21:15     ` Vivek Goyal
2016-07-05 21:34       ` Casey Schaufler
2016-07-06 17:09         ` Vivek Goyal
2016-07-06 17:50           ` Vivek Goyal
2016-07-06 19:01           ` Vivek Goyal
2016-07-06 19:22             ` Casey Schaufler
2016-07-05 21:45   ` Paul Moore
2016-07-05 21:53     ` Vivek Goyal
2016-07-05 15:50 ` [PATCH 3/5] selinux: Pass security pointer to determine_inode_label() Vivek Goyal
2016-07-05 20:25   ` Casey Schaufler
2016-07-05 21:09     ` Vivek Goyal
2016-07-05 15:50 ` [PATCH 4/5] overlayfs: Correctly label newly created file over whiteout Vivek Goyal
2016-07-05 15:50 ` [PATCH 5/5] overlayfs: Use vfs_getxattr_noperm() for real inode Vivek Goyal
2016-07-05 20:29   ` Casey Schaufler
2016-07-05 21:16     ` Vivek Goyal
2016-07-06  4:36       ` Miklos Szeredi
2016-07-06 10:54         ` Vivek Goyal
2016-07-06 14:58           ` Miklos Szeredi [this message]
2016-07-07 18:35             ` Vivek Goyal
2016-07-08  7:06               ` Miklos Szeredi
2016-07-08 15:28                 ` Casey Schaufler

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=CAJfpegv6QnpFM-pPwAUtqYCHVP2f18htQj1TfcxQDFephXO23g@mail.gmail.com \
    --to=miklos@szeredi.hu \
    --cc=casey@schaufler-ca.com \
    --cc=dhowells@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=pmoore@redhat.com \
    --cc=sds@tycho.nsa.gov \
    --cc=vgoyal@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.