selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	Mark Salyzyn <salyzyn@android.com>,
	Paul Moore <paul@paul-moore.com>,
	linux-kernel@vger.kernel.org,
	overlayfs <linux-unionfs@vger.kernel.org>,
	linux-fsdevel@vger.kernel.org, selinux@vger.kernel.org,
	Daniel J Walsh <dwalsh@redhat.com>
Subject: Re: overlayfs access checks on underlying layers
Date: Tue, 4 Dec 2018 11:15:06 -0500	[thread overview]
Message-ID: <20181204161506.GB16818@redhat.com> (raw)
In-Reply-To: <311721a0-26d4-3cf6-1628-acb2c2b1478b@tycho.nsa.gov>

On Tue, Dec 04, 2018 at 10:42:35AM -0500, Stephen Smalley wrote:

[..]
> > > Yes, in that case there isn't an escalation of privilege for the mounter (I
> > > acknowledged that above).  I'm still not sure copy-up of special files is a
> > > good idea though:
> > > 
> > > - In the case of device files, there is the potential for mischief by the
> > > client task in misusing the mounter's privileges to gain access to otherwise
> > > unusable device node (nodev lower vs upper?),
> > 
> > I was thinking about it as well. But client can always bypass permissions
> > of lower device inode by first removing device file and then by doing
> > a mknod. And that will be equivalent of copy up. IOW, IIUC, we do not deny
> > mknod to client and that always creates a way for it to write to device
> > file (and it does not matter what are permissions on lower?)
> 
> I'm not sure what you mean by "we do not deny mknod to client".  Depends on
> your policy and what context the client is running in.  Plenty of situations
> where the client is not allowed to create device files directly, and the
> mounter is.
> 

Oh, I meant for the cases where policy allows client to mknod with context
label. In that case, it does not matter what's the label on lower. Client
can always bypass it by first removing device node and creating a new
device node.

Thanks
Vivek

  reply	other threads:[~2018-12-04 16:15 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-27 19:55 overlayfs access checks on underlying layers Miklos Szeredi
2018-11-27 19:58 ` Miklos Szeredi
2018-11-27 21:05   ` Vivek Goyal
2018-11-28 10:00     ` Miklos Szeredi
2018-11-28 17:03       ` Vivek Goyal
2018-11-28 19:34         ` Stephen Smalley
2018-11-28 20:24           ` Miklos Szeredi
2018-11-28 21:46             ` Stephen Smalley
2018-11-29 11:04               ` Miklos Szeredi
2018-11-29 13:49                 ` Vivek Goyal
2019-03-04 17:01                   ` Mark Salyzyn
2019-03-04 17:56                     ` Casey Schaufler
2019-03-04 18:44                     ` Stephen Smalley
2019-03-04 19:21                       ` Amir Goldstein
2018-11-29 16:16                 ` Stephen Smalley
2018-11-29 16:22                   ` Stephen Smalley
2018-11-29 19:47                   ` Miklos Szeredi
2018-11-29 21:03                     ` Stephen Smalley
2018-11-29 21:19                       ` Stephen Smalley
2018-12-04 13:32                         ` Miklos Szeredi
2018-12-04 14:30                           ` Stephen Smalley
2018-12-04 14:45                             ` Miklos Szeredi
2018-12-04 15:35                               ` Stephen Smalley
2018-12-04 15:39                                 ` Miklos Szeredi
2018-12-11 15:50                                   ` Paul Moore
2018-12-04 15:15                             ` Vivek Goyal
2018-12-04 15:22                               ` Vivek Goyal
2018-12-04 15:31                                 ` Miklos Szeredi
2018-12-04 15:42                                   ` Vivek Goyal
2018-12-04 16:05                                     ` Stephen Smalley
2018-12-04 16:17                                       ` Vivek Goyal
2018-12-04 16:49                                         ` Stephen Smalley
2018-12-05 13:43                                           ` Vivek Goyal
2018-12-06 20:26                                             ` Stephen Smalley
2018-12-11 21:48                                               ` Vivek Goyal
2018-12-12 14:51                                                 ` Stephen Smalley
2018-12-13 14:58                                                   ` Vivek Goyal
2018-12-13 16:12                                                     ` Stephen Smalley
2018-12-13 18:54                                                       ` Vivek Goyal
2018-12-13 20:09                                                         ` Stephen Smalley
2018-12-13 20:26                                                           ` Vivek Goyal
2018-12-04 15:42                               ` Stephen Smalley
2018-12-04 16:15                                 ` Vivek Goyal [this message]
2018-11-29 22:22                     ` Daniel Walsh
2018-12-03 23:27                       ` Paul Moore
2018-12-04 14:43                         ` Stephen Smalley
2018-12-04 23:01                           ` Paul Moore

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=20181204161506.GB16818@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=dwalsh@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=salyzyn@android.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).