Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of andrew.purtell@gmail.com
 designates 209.85.210.41 as permitted sender)
Subject: Re: HBase security research
References: 
 <CABpiY+2GEFBew-za7=saSr20T_y=5UprO7u9PxmAR7QMAwAmig@mail.gmail.com>
 <CAAha9a37TJFAP6gmCijgVZEZx3HUsRRRD-OtP5peN0vxhFUGFg@mail.gmail.com>
From: Andrew Purtell <andrew.purtell@gmail.com>
Content-Type: text/plain;
	charset=us-ascii
In-Reply-To: 
 <CAAha9a37TJFAP6gmCijgVZEZx3HUsRRRD-OtP5peN0vxhFUGFg@mail.gmail.com>
Message-Id: <CEB3B2EB-667A-41FE-A67A-8F89F96AA773@gmail.com>
Date: Sun, 17 Jun 2012 10:28:49 -0700
To: "dev@hbase.apache.org" <dev@hbase.apache.org>
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)

I'd also encourage you to read HBASE-1637 and subtasks to see what has alrea=
dy gone in and how it was implemented basically as Joey had suggested. If yo=
u reimplement something the first question that will be asked is what part o=
f HBase code can be reused I.e incremental dev is preferred where possible.=20=


Your work sounds interesting and also challenging as it seems you may have t=
o substantially hack the DFSClient as well as HBase.=20

    - Andy

On Jun 17, 2012, at 8:40 AM, Jonathan Hsieh <jon@cloudera.com> wrote:

> Hi erwinx,
>=20
> Sounds interesting to me!
>=20
> If your purposes are to research/a paper,  I'm always a fan of spending
> some time to define the problem (something constrained to 2 pages would be=

> good) you are trying to solve.  I find it personally helpful to myself and=

> it would help us greatly if you ask us for implementation advice!  After
> that I'd following Joey's advice as an implementation avenue -- start
> hacking using the coprocessor interface.
>=20
> Does your goal also includes potential integration as part of HBase?
>=20
> The threat model sketch you are assuming sounds interesting.  Up to this
> point, our threat model is roughly gives the attacker only the ability to
> make arbitrary rpcs, the ability to sniff client traffic, but also someone=

> who does not have credentials to get to the underlying hdfs file system.
>=20
> There are a few related issues that may be related to what you  are lookin=
g
> into on the bug/feature tracker.  Here are some links to get started:  It
> would be nice to frame what you are trying to solve in relation to those.
> :)
>=20
> https://issues.apache.org/jira/browse/HBASE-6222 Key value visibility tags=
.
> https://issues.apache.org/jira/browse/HBASE-1697 DAC umbrella
>=20
> Jon.
>=20
> On Sun, Jun 17, 2012 at 5:29 AM, erwin x <erwinxdev2@gmail.com> wrote:
>=20
>> Hi all,
>>=20
>> I am investigating how HBase can be used to store sensitive/confidential
>> information.
>> This research is part of my master thesis for computing science at a
>> university.
>>=20
>> The research involves mostly confidentiality, for example:
>> - Describing the location of the data within the distributed system
>> - Role based access control
>> - Fine grained access control (at column/row level)
>> - Build-in encryption based on the role
>> - The impact on performance and validation of the above security.
>>=20
>> My questions are:
>>=20
>> 1) are the above features interesting for HBase?
>> 2) should I propose my changes and results in the Jira of HBase?
>>=20
>> This research assumes that the data is so sensitive that even
>> administrators, developers or other malicious accessors may not see
>> the data unless they have an authorized role.
>>=20
>> If I observed correctly (correct me if I am wrong), security in HBase
>> now focuses primarily on authentication and discretionary access
>> control and assumes that no malicious user has access to the
>> underlying system, for example HDFS, hard drive or shell access because
>> data can still be read in that way. My research focuses on extending
>> HBase security with more authorization and confidentiality features.
>>=20
>> Thanks in advance!
>>=20
>> Kind regards,
>> erwinx
>>=20
>=20
>=20
>=20
> --=20
> // Jonathan Hsieh (shay)
> // Software Engineer, Cloudera
> // jon@cloudera.com