It depends on what jena-permissions is "for". As a module to help users
build secure apps, the jena-permissions code works with the secure app
to present secure data. It itself has complete access to the data and by
implication so does everything in the JVM.
The secure app has higher level operations ("add to bank account") and
jena-permissions does part of the work needed to build the app. The app
still has to get it right to avoid information leakage.
Hence the change from "jena-security" to "jena-permissions".
The reason jena-fuseki-access exists is
(1) that it did not seem possible to layer a secure view over machinery
that is doing the deny case.
(2) Datasets and new graphs
(3) AuthC and AuthZ. Access rejection at start, not half-way-through.
It is not library code to help build a secure app.
It's read-only - updates happen via a different endpoint with
appropriate access control.
On 02/03/2021 16:00, Claude Warren wrote:
Since the flag would be in the SecurityEvaluator you could conceivably have
soft in one place and hard in another.
Does the above conversation mean that we should look at soft errors from
Writes? (e.g. not report an error if the user is not permitted)
And do we then consider soft errors for Updates separately? The only place
an update occurs is in the Model code, this is explained in the notes about
the difference between SecuredModel and Model on a SecuredGraph.
For now I think we should do the soft read error flag and leave the rest
for when it is requested.
Given the secure app still has to "get it right" anyway, that makes sense.
Andy
Claude
On Tue, Mar 2, 2021 at 3:11 PM Rob Vesse <[email protected]> wrote:
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
>
>
>
>
