hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-11070) [AccessController] Restore early-out access denial if the user has no access at the table or CF level
Date Thu, 24 Apr 2014 18:19:20 GMT

     [ https://issues.apache.org/jira/browse/HBASE-11070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Andrew Purtell updated HBASE-11070:
-----------------------------------

    Description: 
We want to support two different use cases for cell ACLs:
1. The user can see all cells in a table or CF unless a cell ACL denies access
2. The user cannot see any cells in a table or CF unless a cell ACL grants access
For the sake of flexibility we made it a toggle on an operation by operation basis. However
this changed the behavior of the AccessController with respect to how requests for which a
user has no grant at the table or CF level are handled. Prior to the cell ACL changes if a
user had no grant at the table or CF level, they would see an AccessDeniedException. We can't
do that if we want cell ACLs to provide exceptional access, so subsequent to the cell ACL
changes the user simply won't see any cells except those which have those exceptional grants
at the cell level. This also brings the AccessController semantics in line with those of the
new VisibilityController. 

Feedback on dev@ is this change is a bridge too far for at least three reasons. First, it
is surprising (Enis and Vandana). Second, the audit trail is affected or missing (Enis). Third,
it allows any user on the cluster to mount targeted queries against all tables looking for
timing differences, that depending on schema design could possibly leak the existence in row
keys of sensitive information, or leak the size of the table (Todd). Although we can't prevent
timing attacks in general we can limit the scope of what a user can explore by restoring early-out
access denial if the user has no access at the table or CF level.

We make early-out access denial if the user has no access at the table or CF level 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. This would address the
above and not introduce another surprising change among 0.98 releases.

  was:
We want to support two different use cases for cell ACLs:
1. The user can see all cells in a table or CF unless a cell ACL denies access
2. The user cannot see any cells in a table or CF unless a cell ACL grants access
For the sake of flexibility we made it a toggle on an operation by operation basis. However
this changed the behavior of the AccessController with respect to how requests for which a
user has no grant at the table or CF level. Prior to the cell ACL changes if a user had no
grant at the table or CF level, they would see an AccessDeniedException. We can't do that
if we want cell ACLs to provide exceptional access, so subsequent to the cell ACL changes
the user simply won't see any cells except those which have those exceptional grants at the
cell level. 

Feedback on dev@ is this change is undesirable for at least three reasons. First, it is surprising
(Enis and Vandana). Second, the audit trail is affected or missing (Enis). Third, it allows
any user on the cluster to mount targeted queries against all tables looking for timing differences,
that depending on schema design could possibly leak the existence in row keys of sensitive
information, or leak the size of the table (Todd). Although we can't prevent timing attacks
in general we can limit the scope of what a user can explore by restoring early-out access
denial if the user has no access at the table or CF level.

We make early-out access denial if the user has no access at the table or CF level 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. This would address the
above and not introduce another surprising change among 0.98 releases.


> [AccessController] Restore early-out access denial if the user has no access at the table
or CF level
> -----------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-11070
>                 URL: https://issues.apache.org/jira/browse/HBASE-11070
>             Project: HBase
>          Issue Type: Task
>            Reporter: Andrew Purtell
>             Fix For: 0.99.0, 0.98.3
>
>
> We want to support two different use cases for cell ACLs:
> 1. The user can see all cells in a table or CF unless a cell ACL denies access
> 2. The user cannot see any cells in a table or CF unless a cell ACL grants access
> For the sake of flexibility we made it a toggle on an operation by operation basis. However
this changed the behavior of the AccessController with respect to how requests for which a
user has no grant at the table or CF level are handled. Prior to the cell ACL changes if a
user had no grant at the table or CF level, they would see an AccessDeniedException. We can't
do that if we want cell ACLs to provide exceptional access, so subsequent to the cell ACL
changes the user simply won't see any cells except those which have those exceptional grants
at the cell level. This also brings the AccessController semantics in line with those of the
new VisibilityController. 
> Feedback on dev@ is this change is a bridge too far for at least three reasons. First,
it is surprising (Enis and Vandana). Second, the audit trail is affected or missing (Enis).
Third, it allows any user on the cluster to mount targeted queries against all tables looking
for timing differences, that depending on schema design could possibly leak the existence
in row keys of sensitive information, or leak the size of the table (Todd). Although we can't
prevent timing attacks in general we can limit the scope of what a user can explore by restoring
early-out access denial if the user has no access at the table or CF level.
> We make early-out access denial if the user has no access at the table or CF level 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. This would address the
above and not introduce another surprising change among 0.98 releases.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message