security.json "all" predefined permission

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

security.json "all" predefined permission

Jason Gerlowski
Hi all,

Diving into the RuleBasedAuthorizationPlugin for the first time in
awhile, and found that the predefined permission "all" isn't behaving
the way I'd expect it to.  I'm trying to figure out whether it doesn't
work the way I think, whether I'm just making a dumb mistake, or
whether it's currently broken on master (and some 7x versions)

My intent is to create two users, one with readonly access, and an
admin user with access to all APIs.  I'm trying to achieve this with
the security.json below:

{
  "authentication": {
    "blockUnknown": true,
    "class": "solr.BasicAuthPlugin",
    "credentials": {
      "readonly": "<pw>",
      "admin": "<pw>"}},
  "authorization": {
    "class": "solr.RuleBasedAuthorizationPlugin",
    "permissions": [
      {"name":"read","role": "*"},
      {"name":"schema-read", "role":"*"},
      {"name":"config-read", "role":"*"},
      {"name":"collection-admin-read", "role":"*"},
      {"name":"metrics-read", "role":"*"},
      {"name":"core-admin-read","role":"*"},
      {"name": "all", "role": "admin_role"}
    ],
    "user-role": {
      "readonly": "readonly_role",
      "admin": "admin_role"
    }}}

When I go to test this though, I'm surprised to find that the
"readonly" user is still able to access APIs that I would expect to be
locked down.  The "readonly" user can even update security permissions
with the curl command below!

curl -X POST -H 'Content-Type: application/json' -u
"readonly:readonlyPassword"
http://localhost:8983/solr/admin/authorization --d
@some_auth_json.json

My expectation was that the predefined "all" permission would act as a
catch all, and restrict all requests to "admin_role" that require
permissions I didn't explicitly give to my "readonly" user.  But it
doesn't seem to work that way.  Am I misunderstanding what the "all"
permission does, or is this a bug?

Thanks for any help or clarification.

Jason
Reply | Threaded
Open this post in threaded view
|

Re: security.json "all" predefined permission

Jan Høydahl / Cominvent
There was some other issues with the "all" permission as well lately, see https://issues.apache.org/jira/browse/SOLR-13344 <https://issues.apache.org/jira/browse/SOLR-13344>
Order matters in permissions, the first permission matching is used, but I don't know how that would change anything here.
One thing to try could be to start with an empty RuleBasedAuth and then use the REST API to add all the permissions and roles,
in that way you are sure that they are syntactically correct, and hopefully you get some errors if you do something wrong?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 28. mar. 2019 kl. 20:24 skrev Jason Gerlowski <[hidden email]>:
>
> Hi all,
>
> Diving into the RuleBasedAuthorizationPlugin for the first time in
> awhile, and found that the predefined permission "all" isn't behaving
> the way I'd expect it to.  I'm trying to figure out whether it doesn't
> work the way I think, whether I'm just making a dumb mistake, or
> whether it's currently broken on master (and some 7x versions)
>
> My intent is to create two users, one with readonly access, and an
> admin user with access to all APIs.  I'm trying to achieve this with
> the security.json below:
>
> {
>  "authentication": {
>    "blockUnknown": true,
>    "class": "solr.BasicAuthPlugin",
>    "credentials": {
>      "readonly": "<pw>",
>      "admin": "<pw>"}},
>  "authorization": {
>    "class": "solr.RuleBasedAuthorizationPlugin",
>    "permissions": [
>      {"name":"read","role": "*"},
>      {"name":"schema-read", "role":"*"},
>      {"name":"config-read", "role":"*"},
>      {"name":"collection-admin-read", "role":"*"},
>      {"name":"metrics-read", "role":"*"},
>      {"name":"core-admin-read","role":"*"},
>      {"name": "all", "role": "admin_role"}
>    ],
>    "user-role": {
>      "readonly": "readonly_role",
>      "admin": "admin_role"
>    }}}
>
> When I go to test this though, I'm surprised to find that the
> "readonly" user is still able to access APIs that I would expect to be
> locked down.  The "readonly" user can even update security permissions
> with the curl command below!
>
> curl -X POST -H 'Content-Type: application/json' -u
> "readonly:readonlyPassword"
> http://localhost:8983/solr/admin/authorization --d
> @some_auth_json.json
>
> My expectation was that the predefined "all" permission would act as a
> catch all, and restrict all requests to "admin_role" that require
> permissions I didn't explicitly give to my "readonly" user.  But it
> doesn't seem to work that way.  Am I misunderstanding what the "all"
> permission does, or is this a bug?
>
> Thanks for any help or clarification.
>
> Jason

Reply | Threaded
Open this post in threaded view
|

Re: security.json "all" predefined permission

Jason Gerlowski
Thanks for the pointer Jan.

I spent much of yesterday experimenting with the ordering to make sure
that wasn't a factor and I was able to eventually rule it out with
some debug logging that showed that the requests were being allowed
because it couldn't find any governing permission rules. Apparently
RBAP fails "open"
(https://github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/security/RuleBasedAuthorizationPlugin.java#L208)

Anyway, I'm pretty convinced this is a bug.  Most handlers implement
the PermissionNameProvider interface, which has a method that spits
out the required permission for that request handler.  (e.g.
CoreAdminHandler.getPermissionName() returns either CORE_READ_PERM or
CORE_EDIT_PERM based on the request's query params).  When the
request-handler is-a PermissionNameProvider, we do string matching to
see whether we have permissions, but we don't check for the "all"
special case.  So RBAP checks for "all" if the handler wasn't a
PermissionNameProvider (causing SOLR-13344's Admin UI behavior), but
it doesn't check for all when the handler is a PermissionNameProvider
(causing the buggy behavior I described above).

We should definitely be checking for all when there is a
PermissionNameProvider, so I'll create a JIRA for this.

Best,

Jason

On Thu, Mar 28, 2019 at 6:11 PM Jan Høydahl <[hidden email]> wrote:

>
> There was some other issues with the "all" permission as well lately, see https://issues.apache.org/jira/browse/SOLR-13344 <https://issues.apache.org/jira/browse/SOLR-13344>
> Order matters in permissions, the first permission matching is used, but I don't know how that would change anything here.
> One thing to try could be to start with an empty RuleBasedAuth and then use the REST API to add all the permissions and roles,
> in that way you are sure that they are syntactically correct, and hopefully you get some errors if you do something wrong?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> > 28. mar. 2019 kl. 20:24 skrev Jason Gerlowski <[hidden email]>:
> >
> > Hi all,
> >
> > Diving into the RuleBasedAuthorizationPlugin for the first time in
> > awhile, and found that the predefined permission "all" isn't behaving
> > the way I'd expect it to.  I'm trying to figure out whether it doesn't
> > work the way I think, whether I'm just making a dumb mistake, or
> > whether it's currently broken on master (and some 7x versions)
> >
> > My intent is to create two users, one with readonly access, and an
> > admin user with access to all APIs.  I'm trying to achieve this with
> > the security.json below:
> >
> > {
> >  "authentication": {
> >    "blockUnknown": true,
> >    "class": "solr.BasicAuthPlugin",
> >    "credentials": {
> >      "readonly": "<pw>",
> >      "admin": "<pw>"}},
> >  "authorization": {
> >    "class": "solr.RuleBasedAuthorizationPlugin",
> >    "permissions": [
> >      {"name":"read","role": "*"},
> >      {"name":"schema-read", "role":"*"},
> >      {"name":"config-read", "role":"*"},
> >      {"name":"collection-admin-read", "role":"*"},
> >      {"name":"metrics-read", "role":"*"},
> >      {"name":"core-admin-read","role":"*"},
> >      {"name": "all", "role": "admin_role"}
> >    ],
> >    "user-role": {
> >      "readonly": "readonly_role",
> >      "admin": "admin_role"
> >    }}}
> >
> > When I go to test this though, I'm surprised to find that the
> > "readonly" user is still able to access APIs that I would expect to be
> > locked down.  The "readonly" user can even update security permissions
> > with the curl command below!
> >
> > curl -X POST -H 'Content-Type: application/json' -u
> > "readonly:readonlyPassword"
> > http://localhost:8983/solr/admin/authorization --d
> > @some_auth_json.json
> >
> > My expectation was that the predefined "all" permission would act as a
> > catch all, and restrict all requests to "admin_role" that require
> > permissions I didn't explicitly give to my "readonly" user.  But it
> > doesn't seem to work that way.  Am I misunderstanding what the "all"
> > permission does, or is this a bug?
> >
> > Thanks for any help or clarification.
> >
> > Jason
>