hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vandana Ayyalasomayajula <avand...@yahoo-inc.com>
Subject Re: Behavior change in Access Controller between 0.94 and 0.98
Date Thu, 24 Apr 2014 18:12:15 GMT
From the users end,  I think its better to let them know that they don't have proper
authorizations ( when they actually don't have ), rather than returning empty result. 
I am in favor of having a setting which restores early access denial. 

On Apr 24, 2014, at 10:49 AM, Andrew Purtell <apurtell@apache.org> wrote:

> Thanks. The perspective is valuable.
> 
> Unfortunately we had to commit these changes to get them reviewed. But
> we've flagged HFileV3 as experimental through the 0.98 cycle in public
> comments about 0.98 (blog posts, presentations), and these features all
> depend on HFileV3, so I think allows us some freedom of movement. Someone
> speak up if you disagree.
> 
> 
>> 
> ​
> from the
> ​> ​
> "outsider" perspective, I would have guessed that the table-level ACLs
> ​> ​
> would have two different permissions:
> ​​
> READ (default VISIBLE) and READ
> ​> ​
> (default INVISIBLE). If a user has the former, then they can see all cells
> ​> ​
> that aren't explicitly made invisible to them, and if the user has the
> ​> ​
> latter, they can't see any cells unless made explicitly visible.
> 
> There is a per-operation attribute that lets the querying application flip
> between those two modes of evaluating cell permissions on a request by
> request basis. The motivation was performance optimization, avoiding a scan
> over the store where possible, and flexibility. Based on what Enis,
> ​
> Vandana, and you are saying that flexibility is a net negative. I will file
> a JIRA for a per-table setting that restores early-out access denial if the
> user has no access at the table or CF level since this looks like 3 votes
> in favor.
> 
>> ​
> This will also come into play once we do a better job of safeguarding META.
>> AFAIK today a user can scan META and see the row keys for region
> boundaries
>> regardless of their access to those tables.
> 
> That's a requirement of BigTable fundamentally.
> 
> Cell ACLs let you grant arbitrary permissions to users on the cluster. How
> would a user find those cells for which they are authorized of whole
> sections of the table, within which those cells granting access may be
> found, are invisible to their client library?
> 
> It's an interesting idea but a lot of thought and work without a real need
> for it. Don't encode sensitive information in row keys. That's been a
> consideration for HBase schema design forever.
> 
> 
> On Thu, Apr 24, 2014 at 10:21 AM, Todd Lipcon <todd@cloudera.com> wrote:
> 
>> On Thu, Apr 24, 2014 at 10:13 AM, Andrew Purtell <apurtell@apache.org
>>> wrote:
>> 
>>>> Does this leave us open to leaking row existence due to timing
>>> differences?
>>> 
>>> I think I have to answer yes because we've never considered a defense
>>> against this kind of attack against HBase data sources ever. As you say
>> it
>>> would depend on schema design. Do you think defending against timing
>>> attacks is something HBase should do?
>> 
>> 
>> In certain cases... (see below)
>> 
>> 
>>> Is this a feature offered by MySQL or
>>> Postgres or commercial RDBMSes?
>> 
>> 
>> AFAIK most commercial databases don't offer the "hidden visibility" access
>> control differently than "access denied". That is to say, you may deny
>> access to a table, but in that case you get an error with any access to the
>> table rather than an empty result.
>> 
>> In our case we're probably leaking table size as well -- a scan with no key
>> range attached should take time proportional to the amount of data in the
>> table, even if you have no access. In commercial DBs I would be surprised
>> if a user can get these types of estimates for a table they're disallowed
>> from.
>> 
>> 
>>> Or perhaps your point is more that the
>>> original behavior of the AccessController is better because the number of
>>> users able to perform this kind of attack would be limited to explicit
>>> grants at the table or CF level.
>>> 
>> 
>> Right. If I have a multitenant system and I deny you access, I wouldn't
>> except you to be able to perform these kinds of attacks.
>> 
>> I'm a bit of an outsider (haven't followed the implementation of the
>> security features or why the design choices were made), but
>> ​​
>> from the
>> "outsider" perspective, I would have guessed that the table-level ACLs
>> would have two different permissions:
>> ​​
>> READ (default VISIBLE) and READ
>> (default INVISIBLE). If a user has the former, then they can see all cells
>> that aren't explicitly made invisible to them, and if the user has the
>> latter, they can't see any cells unless made explicitly visible. But if
>> they have neither type of READ permission on the table level, then they
>> shouldn't be able to access the table at all.
>> 
>> ​​
>> This will also come into play once we do a better job of safeguarding META.
>> AFAIK today a user can scan META and see the row keys for region boundaries
>> regardless of their access to those tables. This seems like the kind of
>> thing that you'd need to allow for a user who has READ (even if they have
>> default invisible), but you wouldn't want to allow for an arbitrary user on
>> the cluster.
>> 
>> -Todd
>> 
>> 
>>> 
>>> 
>>> 
>>> On Thu, Apr 24, 2014 at 10:04 AM, Todd Lipcon <todd@cloudera.com> wrote:
>>> 
>>>> Does this leave us open to leaking row existence due to timing
>>> differences?
>>>> 
>>>> For example, imagine you had a table where I happened to know (eg from
>>>> reading your design docs on the wiki) that the key is made up of social
>>>> security numbers. If I wanted to come up with a list of valid SSNs, I
>>> could
>>>> issue GETs against your table. If I issue a GET for an invalid SSN, the
>>>> response will come back on average quite a bit faster than if I issued
>> a
>>>> GET for a valid SSN (since the invalid SSN would be filtered by blooms
>>>> where the valid one would not).
>>>> 
>>>> -Todd
>>>> 
>>>> 
>>>> On Thu, Apr 24, 2014 at 9:49 AM, Andrew Purtell <apurtell@apache.org>
>>>> wrote:
>>>> 
>>>>> This is an intended change that was done as part of introducing cell
>>>> ACLs.
>>>>> Otherwise we can't support use cases where the user has no
>>> authorization
>>>> on
>>>>> the table or CF level but cell ACLs grant exceptional access. It also
>>>>> brings the AccessController behavior in line with the new
>>>>> VisibilityController - cells which the user are not authorized to see
>>> are
>>>>> invisible in both settings.
>>>>> 
>>>>> Enis recently brought up the same issue, let me copy that here:
>>>>> 
>>>>>>>> 
>>>>> 
>>>>> Subject: Get / Scan without table ACLs no longer throws
>>>>> AccessDeniedException
>>>>> 
>>>>> I was a bit surprised to find out about the case where there is a
>>>>> behavioral change in trying to read from tables that the user do not
>>> have
>>>>> table/cf level permission.
>>>>> [...]
>>>>> Also this behavioral change is applicable to the audit log as well,
>> we
>>> no
>>>>> longer mark the access granted / denied requests for gets and scans
>> in
>>>> the
>>>>> audit log which is concerning.
>>>>> 
>>>>> From the lsat paragraph in
>>>>> https://blogs.apache.org/hbase/entry/hbase_cell_security, Andrew
>>> states
>>>>> that there are two modes now, check cell first or not
>>>>> (Query.setACLStrategy()).
>>>>> 
>>>>> However, my understanding was that the default behavior should check
>>>> table
>>>>> first, and then not do the scan at all if that is denied. From the
>> code
>>>>> TableAuthManager.authorize(), it does not look to be the case. My
>>>> questions
>>>>> are:
>>>>> 1) This is a behavioral change, and changes the default behavior as
>>> well
>>>>> regardless of whether cell level security is used or not. Should we
>>>> revert
>>>>> back to the original behavior?
>>>>> 2) Even if we do not revert, should we record get / scans in the
>> audit
>>>> log
>>>>> ?
>>>>> 3) Are we targeting two use cases (a) user do not have table level
>>> auth,
>>>>> but selectively have cell level access, and (b) user do have table
>>> level
>>>>> auth but selectively NOT have cell level access? For these two use
>>> cases,
>>>>> should the strategy be a table level property rather than an per-op
>>>>> property ?
>>>>> 
>>>>> <<<
>>>>> 
>>>>> To which I replied:
>>>>> 
>>>>>>>> 
>>>>> 
>>>>> The answer is #3.
>>>>> 
>>>>> It could be made a table level property.
>>>>> 
>>>>>> Also this behavioral change is applicable to the audit log as well,
>>> we
>>>> no
>>>>> longer mark the access granted / denied requests for gets and scans
>> in
>>>> the
>>>>> audit log which is concerning.
>>>>> 
>>>>> This is some kind of logic bug or oversight, please file a jira.
>>>>> 
>>>>> <<<
>>>>> 
>>>>> So if the consensus is this is too surprising or unwanted, then we
>> can
>>>>> without much difficulty make the new behavior configurable on a per
>>> table
>>>>> basis and have the default be the new behavior, with a release note
>> and
>>>>> paragraph in the security guide explaining how to reintroduce the old
>>>>> behavior. I think that covers the bases.
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Apr 24, 2014 at 12:35 AM, Vandana Ayyalasomayajula <
>>>>> avandana@yahoo-inc.com> wrote:
>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> We have seen a behavior change in the manner AccessController
>> blocks
>>>>>> unauthorized users between 0.94 and 0.98.
>>>>>> In 0.98, if an unauthorized user tried to perform GET, SCAN  empty
>>>>> results
>>>>>> are returned, whereas the same operations
>>>>>> in 0.94 used to throw access denied exceptions.
>>>>>> 
>>>>>> Is this a behavior change or a bug in 0.98 ? It would be of great
>>> help
>>>> if
>>>>>> someone could point me to any jira which has discussions related
to
>>>>>> these changes.
>>>>>> 
>>>>>> Thanks
>>>>>> 
>> ​​
>> Vandana
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Best regards,
>>>>> 
>>>>>   - Andy
>>>>> 
>>>>> Problems worthy of attack prove their worth by hitting back. - Piet
>>> Hein
>>>>> (via Tom White)
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Todd Lipcon
>>>> Software Engineer, Cloudera
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Best regards,
>>> 
>>>   - Andy
>>> 
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>>> (via Tom White)
>>> 
>> 
>> 
>> 
>> --
>> Todd Lipcon
>> Software Engineer, Cloudera
>> 
> 
> 
> 
> -- 
> Best regards,
> 
>   - Andy
> 
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)

Mime
View raw message