accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Allen <mich...@sqrrl.com>
Subject Re: "NOT" operator in visibility string
Date Mon, 10 Mar 2014 17:25:06 GMT
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 <josh.elser@gmail.com> 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 | www.sqrrl.com
-----------------------------------

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.

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