https://issues.apache.org/jira/browse/HBASE-11070
On Thu, Apr 24, 2014 at 11:12 AM, Vandana Ayyalasomayajula < avand...@yahoo-inc.com> wrote: > 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 <apurt...@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 <t...@cloudera.com> wrote: > > > >> On Thu, Apr 24, 2014 at 10:13 AM, Andrew Purtell <apurt...@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 <t...@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 <apurt...@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 < > >>>>> avand...@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) > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
