Accumulo
  1. Accumulo
  2. ACCUMULO-2938

Investigate logging on KeyExtent to ensure no data leakage

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 1.8.0
    • Component/s: master, tserver
    • Labels:
      None

      Description

      The KeyExtent class identifies a Tablet in Accumulo. Of interest to this issue, KeyExtent may contain the endRow of the Tablet and/or the endRow of the previous Tablet (or neither).

      If we log the extent, we have the potential to be leaking some data that might need to be protected (visibilities, encryption) to a medium only protected by filesystem restrictions.

      This may be difficult since the extent is included in things like MinC and MajC log messages and can be helpful when diagnosing problems on the system. Can we abstract away what might be potentially sensitive data in some way that we still provide useful data for debugging purposes?

        Activity

        Hide
        Josh Elser added a comment -

        Setting to 1.7.0 for triage. It's been in the code for quite some time. We should get it cleaned up, but until someone steps up to do it, we'll let it cycle through our normal ticket-lifecycle process.

        Show
        Josh Elser added a comment - Setting to 1.7.0 for triage. It's been in the code for quite some time. We should get it cleaned up, but until someone steps up to do it, we'll let it cycle through our normal ticket-lifecycle process.
        Hide
        Christopher Tubbs added a comment -

        Despite this issue being labeled critical, I don't see any version information here, as to which versions are affected, or which ones are targeted for fixing.

        As for whether or not it should be considered critical, I just want to point out that logs should always be assumed to contain sensitive data, and be protected accordingly. So, I'm not sure this warrants being critical, but certainly it's a good idea.

        Show
        Christopher Tubbs added a comment - Despite this issue being labeled critical, I don't see any version information here, as to which versions are affected, or which ones are targeted for fixing. As for whether or not it should be considered critical, I just want to point out that logs should always be assumed to contain sensitive data, and be protected accordingly. So, I'm not sure this warrants being critical, but certainly it's a good idea.
        Hide
        Sean Busbey added a comment -

        increasing priority to Critical, because of potential for data leak

        Show
        Sean Busbey added a comment - increasing priority to Critical, because of potential for data leak
        Hide
        Josh Elser added a comment -

        That might be a nice middle ground. We could treat it like the audit log configuration we have presently.

        Show
        Josh Elser added a comment - That might be a nice middle ground. We could treat it like the audit log configuration we have presently.
        Hide
        Sean Busbey added a comment -

        alternatively, provide a configurable toggle that makes sure the operator is aware of the sensitivity. e.g. we could set a max log level that is allowed to have unmasked sensitive things (default to NONE). Then an operator could up this to TRACE or DEBUG and configure their logging mechanism to write those logs to a more protected space (like a disk volume with encryption and rights restricting access).

        Show
        Sean Busbey added a comment - alternatively, provide a configurable toggle that makes sure the operator is aware of the sensitivity. e.g. we could set a max log level that is allowed to have unmasked sensitive things (default to NONE). Then an operator could up this to TRACE or DEBUG and configure their logging mechanism to write those logs to a more protected space (like a disk volume with encryption and rights restricting access).

          People

          • Assignee:
            Unassigned
            Reporter:
            Josh Elser
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development