Live data from Hacker News

Zanzibar: Google’s Consistent, Global Authorization System (2019)

research.google

61–70 of 99 posts

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#61
post #59
post #48

Earlier quoted context omitted.

Is it my impression or nowadays the emerging technology in this sense is OPA (Open Policy Agent)? It looks like a flexible system to build cross-language and cross-framework authorization systems.

I use OPA with terraform and kubernetes, but I’m looking for something for application ACLs, where I as a resource owner can assign permissions to arbitrary subjects for a resource. Does OPA support that? If so that would be very very cool.

I think Ory Keto would be a better choice because it's easier to manage individual resources on an ad-hoc basis.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#62
post #43

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 approa…

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?

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.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#64
post #43

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 approa…

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.

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.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#65
post #62

Earlier quoted context omitted.

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?

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…

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)

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#66
post #62

Earlier quoted context omitted.

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…

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)

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.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#67
post #6

I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso ( https://www.osohq.com/ ), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.

I think the other replies to you are probably correct, but I also can't help but think that a lot of the small/mid size businesses that use AD for Auth, have been on prem for years, and weren't really planning to make a move very soon until the Pandemic hit, have sort of run face first into the fact that they're really stuck with Microsoft now and when Azure AD goes down, their whole business tends to go with it. I d…

Fair, but even still AD only gives you a piece of the puzzle when it comes to authorization. You still have to do all the modeling and implementation inside your app and map it to however that's stored in AD.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#68
post #38
post #6

I'm curious what's driving the resurgence in interest authorization infrastructure, particularly the Zanzibar paper. As founder of Oso ( https://www.osohq.com/ ), I have my own opinions, and I think this is a good thing. But would love to hear others' points of view here.

Never heard of Oso til now. I’m eval’ing a few tools, I really like your policy syntax!

Thanks!

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#69
post #59
post #48

Earlier quoted context omitted.

Is it my impression or nowadays the emerging technology in this sense is OPA (Open Policy Agent)? It looks like a flexible system to build cross-language and cross-framework authorization systems.

I use OPA with terraform and kubernetes, but I’m looking for something for application ACLs, where I as a resource owner can assign permissions to arbitrary subjects for a resource. Does OPA support that? If so that would be very very cool.

Certainly! Application and microservice authorization is probably one of the more common use cases for OPA, and there's definitely benefits in having a unified policy engine in an organization or company.

Re: Zanzibar: Google’s Consistent, Global Authorization System (2019)

#70
I’m curious about what their approach is to handle consistency with object creation and deletion in the client service. ie how do clients guarantee that the relevant ACLs are created and destroyed in Zanzibar when clients create and destroy their objects.

Destroy can be done asynchronously with durable messaging but asynchronous creation of ACLs is annoying from an api consumer perspective.

Post reply on HN