accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 18:07:05 GMT
After a lengthy IRC discussion that boiled down to "well, we need a minimum
authorization set" it became apparent that we need concrete use cases that
we can support. This will be a reasonably comprehensive attempt, with the
caveat that the first few we support already.

Use Case #1: A report generating program needs to read all available data,
but does not have an explicit enumeration of its roles.

Example: A client will read all the data that it can access for a generated
report. The system administrators recently split existing roles into finer
grained security roles, and have assigned a new subset roles to the report
generating user. The report generating software should still continue to
run, without modification to code or configuration files.

Use Case #2: A report generating program needs to read multiple, specific
subsets of the data for separate reports. The same aggregation is applied
to each data set, so the same program is used, but run with different
authorizations each time.

Example: A television show ratings company provides reports to various
content providers about the quality of their shows. Customers pay for
reports either by genre (sports channels, news channels) or by broadcasting
family (ABC, FOX, etc...) which are implemented as visibility labels:
Olympics == (sports | NBC).

Use Case #3: Users have general access to the system in line with their
overall authorization level, but are excluded from a few categories for
general reasons.

Example: There are records marked as { (secret | topsecret) & !probation }
which are available to all users with "secret" or "topsecret" access, but
not those on "probation." Once a user is removed from the probation role,
then her access should be granted to this data without further action.
(From the HBase docs).

Use Case #4: Users have general access, with specific exclusions that are
unique to each user.

Example: An employee review database where all employees have access to all
records of every team they have worked on, except for their own files.
Generalization: an employee has to everybody else's records at the company,
except their own. Intent is to create a system similar to the review system
at Valve.

If we were to support 'not' visibilities, I'd like to include these four
use cases as documented examples somewhere. I can be convinced that some
other use case is more appropriate or that my verbiage is a bit loose
somewhere, but I think they are a good first cut.


On Mon, Mar 10, 2014 at 1:25 PM, Michael Allen <> wrote:

> The problem I see with adding "write" visibilities along with "read" ones
> is that Accumulo writes "blind", without checking whether or not a cell of
> that type or set of labels exists. I've had it told to me in the past that
> this was a deliberate design decision taken to keep rates of ingest up.
> So, if that's true, I don't think you could easily have "write"
> visibilities on a cell-by-cell basis.  Having them per-table, though, seems
> very doable, and perhaps a lot more in-line with what people would be using
> such functionality for in the first place.
> Also, on the main topic of adding "NOT", consider my own small vote
> against. I think having all positive statements cuts down on the kind of
> reasoning a security person has to do with the overall system. I realize
> that there are some exclusive-OR type scenarios that are not easily
> accomplishable within the label language itself, but I think John's point
> that you could have logic in the Authorizor to cover those kinds of
> situations makes a lot of sense.
> From an instinctive level, I view getting a visibility label as expanding
> the view you have across the data.  Adding a NOT operator means that
> gaining a label for your user could be contracting your view, or could be
> not, depending on how the logic of the label expressions was constructed.
>  I'd rather reason in one direction.  Maybe that takes some education for
> users.
> On Mon, Mar 10, 2014 at 1:14 PM, Josh Elser <> wrote:
> > > >
> >>>> > >This seems very complicated and easy for users to get wrong.
> >>>> > >
> >>>> > >
> >>>>
> >>> >
> >>> >I agree that this is adding a significant amount of complexity. One
> >>> option
> >>> >would be to annotate NOT as advisory, or to specify in the docs that
> >>> it'd
> >>> >be up to the application layer to enforce the inclusion of the minimal
> >>> set.
> >>> >(then again, that leaves even more room for erroneous implementations)
> >>> >
> >>>
> >> If we are going to do it, I think we should try to come up with a design
> >> that solves end-to-end use cases. The not op seems useful but also
> >> dangerous, there is a real possibility of unintended data leakage.  A
> >> minimal authorization set is a solution.  Are there other solutions?
> Ones
> >> that better translate a users intent into constraints in the system.
> >>
> >>
> > Another snippet from HBase writeups that caught my eye was the idea of
> > supporting both read and write visibilities. What we have right now is
> > read, with a bit of write visibilities (using the VisibilityConstraint).
> > The downside is that you can't let someone read data without writing to
> it.
> >
> > That might be something else to consider as I can see it being a common
> > use-case. (although it might merit its own line of work completely)
> >
> --
> *Michael Allen*
> Security Architect | Sqrrl-----------------------------------130
> Prospect Street | Cambridge, MA 02139415.699.0106 |
> -----------------------------------
> The information contained in this communication may be confidential,
> subject to legal privilege, or otherwise protected from disclosure,
> and is intended solely for the use of the intended recipient(s). If
> you are not the intended recipient of this communication, please
> destroy all copies in your possession, notify the sender that you have
> received this communication in error, and note that any review or
> dissemination of, or the taking of any action in reliance on, this
> communication is expressly prohibited.  Please note that sqrrl data,
> INC. reserves the right to intercept, monitor, and retain e-mail
> messages to and from its systems as permitted by applicable law.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message