Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-11070

[AccessController] Restore early-out access denial if the user has no access at the table or CF level

    Details

    • Type: Task
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      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. Subsequent to the cell ACL changes if a user has no grant at the table or CF level, there is no exception, they simply won't see any cells except those granting exceptional access 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"

        Activity

        Hide
        apurtell Andrew Purtell added a comment -

        Todd Lipcon since I see you lurking on this issue, in your email on dev@ you mentioned two distinct read permissions, 'READ_VISIBLE' and 'READ_INVISIBLE' that could be granted at the table level. (Given how grants via the ACL table work though the same semantics would be available per column family.) We could add those options to the Permission enum and make the current 'READ' a synonym for one of them. The distinction would not be meaningful at the cell level but that could be fine. Having the extra bit would make every authorization decision a bit more complicated to implement and expensive. Do we also want WRITE_VISIBLE and WRITE_INVISIBLE? Write perms can be granted independent of read perms.

        Because that gets weird I think a table / CF attribute as mentioned in the description.

        But, soliciting implementation preference. Enis Soztutar? Vandana Ayyalasomayajula ?

        Show
        apurtell Andrew Purtell added a comment - Todd Lipcon since I see you lurking on this issue, in your email on dev@ you mentioned two distinct read permissions, 'READ_VISIBLE' and 'READ_INVISIBLE' that could be granted at the table level. (Given how grants via the ACL table work though the same semantics would be available per column family.) We could add those options to the Permission enum and make the current 'READ' a synonym for one of them. The distinction would not be meaningful at the cell level but that could be fine. Having the extra bit would make every authorization decision a bit more complicated to implement and expensive. Do we also want WRITE_VISIBLE and WRITE_INVISIBLE? Write perms can be granted independent of read perms. Because that gets weird I think a table / CF attribute as mentioned in the description. But, soliciting implementation preference. Enis Soztutar ? Vandana Ayyalasomayajula ?
        Hide
        enis Enis Soztutar added a comment -

        I think it makes sense to have a separate permission for "being able to read only granted cells". Also thinking more about this, we want the lack of default READ perm would prevent the users from launching scanners. If the admin wants to allow some users to read some cells than she can explicitly set it so.

        Show
        enis Enis Soztutar added a comment - I think it makes sense to have a separate permission for "being able to read only granted cells". Also thinking more about this, we want the lack of default READ perm would prevent the users from launching scanners. If the admin wants to allow some users to read some cells than she can explicitly set it so.
        Hide
        apurtell Andrew Purtell added a comment -

        I think it makes sense to have a separate permission for "being able to read only granted cells".

        We can tinker and see how this works out. See above comment about WRITE being granted independent of READ. Do we want the same kind of separate permission for "being able to write only granted cells"?

        Also thinking more about this, we want the lack of default READ perm would prevent the users from launching scanners.

        This could be done pretty easily by varying the permissions tests in preGet and preExists versus preScannerOpen.

        Show
        apurtell Andrew Purtell added a comment - I think it makes sense to have a separate permission for "being able to read only granted cells". We can tinker and see how this works out. See above comment about WRITE being granted independent of READ. Do we want the same kind of separate permission for "being able to write only granted cells"? Also thinking more about this, we want the lack of default READ perm would prevent the users from launching scanners. This could be done pretty easily by varying the permissions tests in preGet and preExists versus preScannerOpen.
        Hide
        apurtell Andrew Purtell added a comment -

        Opened subtasks

        Show
        apurtell Andrew Purtell added a comment - Opened subtasks

          People

          • Assignee:
            Unassigned
            Reporter:
            apurtell Andrew Purtell
          • Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

            • Created:
              Updated:

              Development