Updates and soft mode is an interesting conundrum
In my $dayjob system update operations are all resource centric i.e. you are
either creating a new resource or overwriting an existing one. So for update
we do use hard errors for non-permissible updates because it still doesn't let
you infer any data. There's no update operations in our system that are
conditional/calculated as in the SPARQL Update case. Aside, most of the
resources in this system are owned by a specific user and by default you can
only write to your own "space" within the system. If you try to write to
another users "space" the error is same whether that other user exists or not
because your default permissions are minimal. About the only obvious side
channel I can think of in our system is that you can infer the existence of
another user if the other user has modified their permissions from the system
defaults.
Whereas here we're talking about much more fine grained permissions. And I
think what you are alluding to here is that SPARQL is trickier because you can
do INSERT {} WHERE {} or DELETE {} WHERE {} (and of course the combined form).
A clever user could perhaps craft an update that takes advantage of soft errors
in the WHERE {} clause.
There's definitely a contention here between where the authentication (AuthC)
and authorization (AuthZ) pieces happen complicated by the fact you need to
solve both the in-memory case and the HTTP case. It may be that different
machinery is needed in different places.
Rob
On 02/03/2021, 11:53, "Andy Seaborne" <[email protected]> wrote:
On 02/03/2021 10:04, Rob Vesse wrote:
> No I like that approach
>
> In a system we're building currently in $dayjob we do much the same
thing. If a user doesn't have permission to see the data it just looks to that
user like that data does not exist so they get null, empty/truncated lists,
false etc. From an information security perspective soft errors are actually
more secure because they don't provide side channels. With a hard error users
can explicitly distinguish between data that isn't there and data that is there
but to which they don’t have access i.e. a clever user can infer the existence
of data under a hard error setup. With soft errors the two cases are
indistinguishable.
>
> Jena 4 is an opportunity to make breaking changes so even if you make the
soft vs hard error behaviour configurable I would suggest making the default be
soft error and document the change as part of whatever Jena 3 -> 4 migration
guide we end up writing. Then people who are using the permissions modules and
upgrading would be forced to understand the change, the reasoning behind it and
make a decision about how to migrate based on their own use cases. If you
leave the default as-is those users could carry on none the wiser without
realising they are missing out on potential security benefits.
>
> Rob
jena-fuseki-access might be interesting for that.
For TDB, it puts in a filter right in at the bottom as the quads come
off the database itself, filtering by NodeId of the graph. Works for
defaultUnionGraph as well.
TIM could do the same but doesn't.
It could filter on anything in the quad but per graph was the requirement.
Authentication is part of the HTTP request cycle.
It's for SPARQL operations and hooks into the operation processors.
The core dataset and QueryExecution work is not Fuseki dependent.
For other datasets, it builds a view datasets that only have the graphs
the request has access to. That makes it work with defaultUnionGraph
across a mix of graphs. Filtering quads is harder for a mixes dataset -
have to put back a quads view, filter and undo that work which at the
low level looked expensive and it wasn't the primary requirement for the
work.
Having it Fuseki means that application code isn't in the same JVM as
the security mechanisms.
I agree that soft/view mode is safer.
Does your work include controlling update in soft mode? I think that can
get into information leakage situations.
Andy
>
> On 01/03/2021, 22:44, "Claude Warren" <[email protected]> wrote:
>
> I started looking at the read permissions on graphs issue that was
raised
> today.
>
> It seems to me that if we change the functioning of graph.find()
then we
> need to change graph.contains() and graph.size() accordingly.
>
> This led me to look at the Model based classes, and there we find a
number
> of iterators, lists of properties, hasX() methods, etc. All of which
> currently throw the ReadDeniedException.
>
> Changing these methods will change the default operation in the wild.
> Something that is OK for v4 but in v3 I think it should stay the
same.
>
> So I am thinking that it might make sense to specify HardReadErrors
(the
> current throw the exception we have now) or SoftReadErrors (return
empty
> iterators, false for hasX() and so on). At first I thought of
putting this
> in a context, but it could be added to the SecurityEvaluator. Since
the
> SecurityEvaluator is an interface I would add it with a default of
> HardReadErrors and allow implementations to override that.
>
> I think this might be the best way forward, though there will be a
lot of
> change in the permissions code base. Does anyone see an issue with
this
> approach or a better approach?
>
> Claude
>
>
>
> --
> I like: Like Like - The likeliest place on the web
> <http://like-like.xenei.com>
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
>
>
>
