Re: bind mount that lies to apps about st_uid?

[Dave Chinner <david@fromorbit.com>]

On Tue, Jul 14, 2015 at 05:41:01PM -0700, Andrew Lutomirski wrote:
> On Tue, Jul 14, 2015 at 5:35 PM, Kenton Varda <kenton@sandstorm.io> wrote:
> > Hi Eric,
> >
> > I'm curious to know if you think this the following is something that could
> > realistically be implemented, or if it's a totally outrageous idea. :)
> >
> > For Sandstorm, we've found a case where it would be useful if we could
> > create a bind-mount in which stat() calls lie and claim all files have UID
> > 65534 (as if their real owner wasn't mapped into the user namespace). All
> > actual security checks would behave normally; only the result of stat()
> > would be affected.
> >
> > Specifically, the problem is that some apps have checks of the form: "If
> > file is owned by my UID, then modify it, otherwise do something else
> > reasonable." These checks are wrong in the case of read-only bind mounts,
> > but legacy code rarely considers such a possibility.
> >
> > Making maters worse, it is the case currently that some configurations of
> > Sandstorm will have these read-only files owned by the UID running the app
> > while others will not. Thus this is an observable difference between servers
> > that can affect app behavior, causing them to work fine on some servers but
> > break on others, which is something we want to avoid at all costs. We can't
> > see any reasonable way to resolve the difference without kernel help,
> > unfortunately.
> >
> > So, it would be convenient if I could trick these apps into behaving
> > correctly by asking the kernel to lie to them about the UID. For our use
> > case, a boolean flag would work. It could simply say: "For stat() purposes
> > on this mount, act as if the uid_map and gid_map are empty, therefore return
> > st_uid and st_gid as 65534." Alternatively, I'd also be happy with a "uid="
> > setting that overrides all reported UIDs, which seems possibly more broadly
> > useful, but also possibly riskier(?). I'm also happy with restricting this
> > to only mounts with MS_RDONLY and MS_NOSUID, if that helps.
> >
> > It's a hack, but it's simple and would save a bunch of confusion for our
> > developers in the long run, I think.

Why wouldn't you just use an ld preload library to intercept stat()
calls in userspace and manipulate them there? No kernel changes
required, no app changes required....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com