hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: Behavior change in Access Controller between 0.94 and 0.98
Date Thu, 24 Apr 2014 17:49:59 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message