linux-kernel - Re: overlayfs access checks on underlying layers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJfpegujwNpWL5Eujrb+=EQF8OMOkO03yq8ZZSkfhFfwQvhGKQ@mail.gmail.com>
Date:   Tue, 4 Dec 2018 15:45:47 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     Stephen Smalley <sds@...ho.nsa.gov>
Cc:     Vivek Goyal <vgoyal@...hat.com>,
        Ondrej Mosnacek <omosnace@...hat.com>,
        "J. Bruce Fields" <bfields@...ldses.org>,
        Mark Salyzyn <salyzyn@...roid.com>,
        Paul Moore <paul@...l-moore.com>, linux-kernel@...r.kernel.org,
        overlayfs <linux-unionfs@...r.kernel.org>,
        linux-fsdevel@...r.kernel.org, selinux@...r.kernel.org,
        Daniel J Walsh <dwalsh@...hat.com>
Subject: Re: overlayfs access checks on underlying layers

On Tue, Dec 4, 2018 at 3:28 PM Stephen Smalley <sds@...ho.nsa.gov> wrote:
>
> On 12/4/18 8:32 AM, Miklos Szeredi wrote:

> > My proposed sequence would be
> >
> > a) check task's creds against overlay inode, fail -> return fail, otherwise:
> > b) check mounter's creds against lower inode, success -> return
> > success, otherwise:
> > c) copy up inode, fail -> return fail, otherwise
> > d) check mounter's creds against upper inode, return result.
> >
> > So, unlike write access to regular files, write access to special
> > files don't necessarily result in copy-up.
> >
> > You say this is an escalation of privilege, but I don't get it how.
> > As DWalsh points out downthread, if mounter cannot create device
> > files, then the copy-up will simply fail.  If mounter can create
> > device files, then this is not an escalation of privilege for the
> > mounter.
>
> 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?),

The mount flag "nodev" on lower or upper has no effect on the overlay,
and never had.

> - In the case of sockets or fifos, what useful result do you get from a
> copy-up? Accessing the copy isn't going to yield the same result as
> accessing the original.

This is a misconception.  Overlayfs is a filesystem (that uses other
filesystems as backing store), but it's more a filesystem and less a
vfs hack (and trying to completely get out of the vfs hack business),
and copy up has no effect on I/O being performed on a socket or FIFO:
it's the same object before and after the copy up, and it's a
different object from either the lower or upper nodes.   Same as NFS:
fifo on server is logically different object than fifo having the same
name on any number of clients.

> For executables, this copy-up behavior might trigger a lot of undesired
> copies of non-executable files from the lower dir into the upper, even
> if we ultimately end up denying the execute.

That would only happen if

  - task is allowed exec on overlay
  - mounter is denied exec on lower
  - copy up is allowed
  - mounter is denied exec on upper

In fact in the model where upper object inherits context from overlay
this is pretty much impossible, AFAICT.

Thanks,
Miklos