selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Walsh <dwalsh@redhat.com>
To: Miklos Szeredi <miklos@szeredi.hu>, Stephen Smalley <sds@tycho.nsa.gov>
Cc: Vivek Goyal <vgoyal@redhat.com>,
	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
Subject: Re: overlayfs access checks on underlying layers
Date: Thu, 29 Nov 2018 17:22:47 -0500	[thread overview]
Message-ID: <f3a911a7-47eb-9922-a4be-25a834250e92@redhat.com> (raw)
In-Reply-To: <CAJfpegv6y56k1-Tewu-Pu3x1W75LL6qYB6Hb6=n+2BJoNfEigA@mail.gmail.com>

On 11/29/18 2:47 PM, Miklos Szeredi wrote:
> On Thu, Nov 29, 2018 at 5:14 PM Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
>> Possibly I misunderstood you, but I don't think we want to copy-up on
>> permission denial, as that would still allow the mounter to read/write
>> special files or execute regular files to which it would normally be
>> denied access, because the copy would inherit the context specified by
>> the mounter in the context mount case.  It still represents an
>> escalation of privilege for the mounter.  In contrast, the copy-up on
>> write behavior does not allow the mounter to do anything it could not do
>> already (i.e. read from the lower, write to the upper).
> Let's get this straight:  when file is copied up, it inherits label
> from context=, not from label of lower file?

Yes, in the case of context mount, it will get the context mount directory.

In the case of not context mount, it should maintain the label of  the
lower.

>
> Next question: permission to change metadata is tied to permission to
> open?  Is it possible that open is denied, but metadata can be
> changed?
Yes, SElinux handles open differently then setattr.  Although I am not
sure if any tools handle this.
> DAC model allows this: metadata change is tied to ownership, not mode
> bits.   And different capability flag.
>
> If the same is true for MAC, then the pre-v4.20-rc1 is already
> susceptible to the privilege escalation you describe, right?
>
> Thanks,
> Miklos

After talking to Vivek, I am not sure their is a privilege escallation.


For device nodes, the mounter has to have the ability to create the
devicenode with the context mount, if he can do this, then he can do it
with or without Overlay.  This might lead to users making mistakes on
security, but the model is sound. And I think this stands even in the
case of the lower is mounted NODEV and the upper is not.  If the mounter
can create a device on the upper with a particular label, then he does
not need the lower.


For sockets, I see the case where a process is listening on the lower
level socket, the mounter mounts the overlay over the directory with the
socket.  Then the mounter changes the attributes of the socket,
performing a copy up.  If the mounter can not talk to the socket and the
other end is still listening, then this could be an issue.  If the
socket is no longer connected to the listener on the lower, then this is
not an issue.


Similar for a FIFO.


With SELinux we are also always checking not only the file access to the
socker, but also checking whether the label of the client is able to
talk to the label of the server daemon.  So we are protected by a
secondary check.






  parent reply	other threads:[~2018-11-29 22:22 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
2018-11-29 22:22                     ` Daniel Walsh [this message]
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=f3a911a7-47eb-9922-a4be-25a834250e92@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=bfields@fieldses.org \
    --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 \
    --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;
as well as URLs for NNTP newsgroup(s).