[dvdkon]

I'm currently building an abstracted authorization system for PostgreSQL, and one problem I ran into were timing attacks. Granted, I only had an unoptimised prototype, but querying a table and only checking if the user has permission to read the objects after the fact led to being able to differentiate "no matching object" and "one unavailable matching object". From skimming the paper, it seems Google use this approach, why are timing attacks not a problem for them? Is it because authorization checks are so fast? Or because they make sure only to query available objects, only using Zanzibar as a final "just in case" guard?

[bradstewart]

What exactly is the attack you're worried about here?

Why do attackers have direct query access to your database? What useful information can they extract from knowing there is an unauthorized object in the database?

[dvdkon]

My model attacker is a limited user that has access to an advanced search function with filtering on number inequality and/or string patterns akin to LIKE. Such an attacker could send a search query such as "id = 4829 AND cost > 1000" and measure the time that query took (over multiple executions). From the time data the attacker could then determine if object 4829 has a cost value of over 1000, gaining 1 bit of data. Through a binary search they could obtain the full value in logarithmic time.

If the authorization check was fast enough (which it probably is for performance reasons anyway), this would be reduced to the attacker obtaining statistical information (roughly how many objects have cost over 1000). That might be acceptable, my problem is that a benign-looking performane problem could become a serious security problem.

[joshuamorton]

Zanzibar doesn't actually contain any object data, only authorization metadata. So you can't do the complex queries you're suggesting against Zanzibar itself, and presumably the databases that store actual data have authz as a requirement prior to the actual query (which is fine bc Zanzibar is fast)

[dvdkon]

Could you elaborate on "prior to the actual query"? Do you mean taking some rough queryable subset and then calling Zanzibar for each object in that subset? That's how I'm handling it right now, I just hoped others had a more scalable solution.

[joshuamorton]

No I mean that a user either has access to the database or not. If they do, you check access prior to the query. I think you're doing something related to row level permissions within a database.

And ultimately "Implementing side-channel secure row level security in a database" is a completely independent problem from "abstract authz checker, which is what zanzibar is. You might build a row level security infra atop zanzibar, but you'd probably do that within your database engine, with zanzibar serving as some sort of authz primitive.

[dvdkon]

From what I can see, Zanzibar is also intended for "row-level" access checks.

I also don't think it's such a separate problem. If you've got a set of authorization primitives, you should have some simple and foolproof way of applying them to various usecases. You might have the best policy description language and very fast evaluation, but what good is it as a central authz service when you can't securely implement search on top of it?

[MrKristopher]

If your object IDs are 1, 2, 3... then attacker can check all the IDs. If instead each object ID is a 256-bit UUID, then the attacker can't make a query for every possible object ID.

[MrKristopher]

I'm not sure I understand the concern here. Typically there is a logged-in user, and server asks Zanzibar if the user can or cannot access some document. Whether a certain document exists or not isn't typically a secret i.e. you might get HTTP 403 (forbidden) or 404 depending on whether or not the document exists.

[dvdkon]

Please see my other comment: https://news.ycombinator.com/item?id=26983342

My concern isn't access to single objects, but rather filtering of complex search results.

[TechBro8615]

This very much depends. GitHub for example will return 404 for a private repository when you are logged out. The idea is balancing HTTP semantics with information leaking.

[sitkack]

Does the 404 a logged out repo return in the same amount of time as a repo that doesn't truly exist?

[comboy]

Maybe evening response time is some abstraction on top? It may be useful for protecting much more than just auth so it would make sense not to repeat that on every layer.

[dvdkon]

I considered that, but it seems way too fragile to trust, expecially if you want to test complex relationships for authorization.