[
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 can make early-out access denial if the user has no access at the table or
CF level configurable on a per table basis. Setting the default to "false",
with a release note and paragraph in the security guide explaining how to
reintroduce the old behavior, would address the above and not introduce another
surprising change among 0.98 releases. If the consensus is (presumably a
milder) surprise due to this change is fine, then the default could be "true"
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 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.
> [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 can make early-out access denial if the user has no access at the table or
> CF level configurable on a per table basis. Setting the default to "false",
> with a release note and paragraph in the security guide explaining how to
> reintroduce the old behavior, would address the above and not introduce
> another surprising change among 0.98 releases. If the consensus is
> (presumably a milder) surprise due to this change is fine, then the default
> could be "true"
--
This message was sent by Atlassian JIRA
(v6.2#6252)
