hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] Plan to avoid backup/restore removal from 2.0
Date Mon, 13 Nov 2017 19:45:46 GMT
Sure, I don't think there are any issue with sharing this publicly, since
the code has only gone out in alpha releases.

The suspect lines in IncrementalTableBackupClient are 163 and 326. I'm
still working on validating the call path that leads to those getting
flagged.

The issues in MapReduceBackupCopyJob are on lines 386, 405, and 407.

All of them relate to un-sanitized inputs in one way or another.

On Mon, Nov 13, 2017 at 12:50 PM, Ted Yu <yuzhihong@gmail.com> wrote:

> Mike:
> Can you share your finding w.r.t. IncrementalTableBackupClient and
> MapReduceBackupCopyJob
> ?
>
> IncrementalTableBackupClient utilizes WALPlayer directly.
>
> I wonder what vulnerability there is.
>
> Thanks
>
> On Mon, Nov 13, 2017 at 9:02 AM, Mike Drob <mdrob@apache.org> wrote:
>
> > I know I'm late to the party here, but I've got another potential blocker
> > to add.
> >
> > We just ran an HP fortify scan internally and the results did not look
> > good, specifically on IncrementalTableBackupClient and
> > MapReduceBackupCopyJob. I'm still sorting through whether these are
> > actually exploitable, or whether it's a symptom of MapReduce being an
> > arbitrary code execution framework anyway but this does make me wonder
> > about the overall security posture.
> >
> > I see  "HBase Backup/Restore Phase 3: Security"[1] resolved as "Later"
> and
> > claims that it will be implemented in the client, both of which make me
> > uncomfortable. Security Later is a general bad practice, and it is very
> > rarely correct to rely on client-side security for anything.
> >
> > Is there another issue that covers security? Do we rely completely on
> HDFS
> > security here for more than just the DistCP? What kind of testing has
> been
> > done with security, do we have assurances that the backups aren't
> > accidentally exposing tables to the world?
> >
> > Thanks,
> > Mike
> >
> > [1]: https://issues.apache.org/jira/browse/HBASE-14138
> >
> > On Mon, Nov 13, 2017 at 10:38 AM, Josh Elser <elserj@apache.org> wrote:
> >
> > > On 11/11/17 5:31 PM, Stack wrote:
> > >
> > >> Don't want to make any assumptions, but I hope the lack of hard
> > objection
> > >>> can be interpreted as (begrudging, perhaps) acceptance of the plan.
> Let
> > >>> me/us know when possible, please!
> > >>>
> > >>>
> > >>> Plan seems fine.
> > >>
> > >> Are you the owner of this feature now Josh or just shepherding it in?
> > >>
> > >
> > > Thanks, Stack.
> > >
> > > Good question: should have included that out-right. Vlad, Ted, and
> myself
> > > had a chat on this last week.
> > >
> > > While Vlad is polishing HBASE-17852 and HBASE-17825, I told him I'll
> help
> > > out with the HBASE-18892 (testing) and the Book update. Was waiting for
> > > some consensus on the testing gdoc before picking that up.
> > >
> > > I think Vlad is still the owner, but you could certainly call me a
> > > shepherd. I also answer to "sherpa" ;)
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message