HBASE-1697, apologies for that. 

On Jun 17, 2012, at 10:28 AM, Andrew Purtell <[email protected]> wrote:

> I'd also encourage you to read HBASE-1637 and subtasks to see what has 
> already gone in and how it was implemented basically as Joey had suggested. 
> If you reimplement something the first question that will be asked is what 
> part of HBase code can be reused I.e incremental dev is preferred where 
> possible. 
> 
> Your work sounds interesting and also challenging as it seems you may have to 
> substantially hack the DFSClient as well as HBase. 
> 
>   - Andy
> 
> On Jun 17, 2012, at 8:40 AM, Jonathan Hsieh <[email protected]> wrote:
> 
>> Hi erwinx,
>> 
>> Sounds interesting to me!
>> 
>> 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.
>> 
>> Does your goal also includes potential integration as part of HBase?
>> 
>> 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.
>> 
>> There are a few related issues that may be related to what you  are looking
>> 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.
>> :)
>> 
>> https://issues.apache.org/jira/browse/HBASE-6222 Key value visibility tags.
>> https://issues.apache.org/jira/browse/HBASE-1697 DAC umbrella
>> 
>> Jon.
>> 
>> On Sun, Jun 17, 2012 at 5:29 AM, erwin x <[email protected]> wrote:
>> 
>>> Hi all,
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> My questions are:
>>> 
>>> 1) are the above features interesting for HBase?
>>> 2) should I propose my changes and results in the Jira of HBase?
>>> 
>>> 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.
>>> 
>>> 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.
>>> 
>>> Thanks in advance!
>>> 
>>> Kind regards,
>>> erwinx
>>> 
>> 
>> 
>> 
>> -- 
>> // Jonathan Hsieh (shay)
>> // Software Engineer, Cloudera
>> // [email protected]

Reply via email to