lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noble Paul <noble.p...@gmail.com>
Subject Re: Security Problems
Date Thu, 19 Nov 2015 17:40:22 GMT
What is the smallest possible security.json required currently to
protect all possible paths (except those served by Jetty)?



You would need 2 rules
1)
"name":"all-admin",
"collection": null,
"path":"/*"
"role:"somerole"

2) all core handlers
"name":"all-core-handlers",
"path":"/*"
"role":"somerole"


ideally we should have a simple permission name called "all" (which we
don't have)

so that one rule should be enough

"name":"all",
"role":"somerole"

Open a ticket and we should fix it for 5.4.0
It should also include  the admin paths as well


On Thu, Nov 19, 2015 at 6:02 PM, Jan Høydahl <jan.asf@cominvent.com> wrote:
> Would it not be less surprising if ALL requests to Solr required authentication once
an AuthenticationPlugin was enabled?
> Then, if no AuthorizationPlugin was active, all authenticated users could do anything.
> But if AuthorizationPlugin was configured, you could only do what your role allows you
to?
>
> As it is now it is super easy to forget a path, say you protect /select but not /browse
and /query, or someone creates a collection
> with some new endpoints and forgets to update security.json - then that endpoint would
be wide open!
>
> What is the smallest possible security.json required currently to protect all possible
paths (except those served by Jetty)?
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
>> 18. nov. 2015 kl. 20.31 skrev Upayavira <uv@odoko.co.uk>:
>>
>> I'm very happy for the admin UI to be served another way - i.e. not
>> direct from Jetty, if that makes the task of securing it easier.
>>
>> Perhaps a request handler specifically for UI resources which would make
>> it possible to secure it all in a more straight-forward way?
>>
>> Upayavira
>>
>> On Wed, Nov 18, 2015, at 01:54 PM, Noble Paul wrote:
>>> As of now the admin-ui calls are not protected. The static calls are
>>> served by jetty and it bypasses the authentication mechanism
>>> completely. If the admin UI relies on some API call which is served by
>>> Solr.
>>> The other option is to revamp the framework to take care of admin UI
>>> (static content) as well. This would be cleaner solution
>>>
>>>
>>> On Wed, Nov 18, 2015 at 2:32 PM, Upayavira <uv@odoko.co.uk> wrote:
>>>> Not sure I quite understand.
>>>>
>>>> You're saying that the cost for the UI is not large, but then suggesting
>>>> we protect just one resource (/admin/security-check)?
>>>>
>>>> Why couldn't we create the permission called 'admin-ui' and protect
>>>> everything under /admin/ui/ for example? Along with the root HTML link
>>>> too.
>>>>
>>>> Upayavira
>>>>
>>>> On Wed, Nov 18, 2015, at 07:46 AM, Noble Paul wrote:
>>>>> The authentication plugin is not expensive if you are talking in the
>>>>> context of admin UI. After all it is used not like 100s of requests
>>>>> per second.
>>>>>
>>>>> The simplest solution would be
>>>>>
>>>>> provide a well known permission name called "admin-ui"
>>>>>
>>>>> ensure that every admin page load makes a call to some resource say
>>>>> "/admin/security-check"
>>>>>
>>>>> Then we can just protect that .
>>>>>
>>>>> The only concern thatI have is the false sense of security it would
>>>>> give to the user
>>>>>
>>>>> But, that is a different point altogether
>>>>>
>>>>> On Wed, Nov 11, 2015 at 1:52 AM, Upayavira <uv@odoko.co.uk> wrote:
>>>>>> Is the authentication plugin that expensive?
>>>>>>
>>>>>> I can help by minifying the UI down to a smaller number of CSS/JS/etc
>>>>>> files :-)
>>>>>>
>>>>>> It may be overkill, but it would also give better experience. And
isn't
>>>>>> that what most applications do? Check authentication tokens on every
>>>>>> request?
>>>>>>
>>>>>> Upayavira
>>>>>>
>>>>>> On Tue, Nov 10, 2015, at 07:33 PM, Anshum Gupta wrote:
>>>>>>> The reason why we bypass that is so that we don't hit the authentication
>>>>>>> plugin for every request that comes in for static content. I
think we
>>>>>>> could
>>>>>>> call the authentication plugin for that but that'd be an overkill.
Better
>>>>>>> experience ? yes
>>>>>>>
>>>>>>> On Tue, Nov 10, 2015 at 11:24 AM, Upayavira <uv@odoko.co.uk>
wrote:
>>>>>>>
>>>>>>>> Noble,
>>>>>>>>
>>>>>>>> I get that a UI which is open source does not benefit from
ACL control -
>>>>>>>> we're not giving away anything that isn't public (other than
perhaps
>>>>>>>> info that could be used to identify the version of Solr,
or even the
>>>>>>>> fact that it *is* solr).
>>>>>>>>
>>>>>>>> However, from a user experience point of view, requiring
credentials to
>>>>>>>> see the UI would be more conventional, and therefore lead
to less
>>>>>>>> confusion. Is it possible for us to protect the UI static
files, only
>>>>>>>> for the sake of user experience, rather than security?
>>>>>>>>
>>>>>>>> Upayavira
>>>>>>>>
>>>>>>>> On Tue, Nov 10, 2015, at 12:01 PM, Noble Paul wrote:
>>>>>>>>> The admin UI is a bunch of static pages . We don't let
the ACL control
>>>>>>>>> static content
>>>>>>>>>
>>>>>>>>> you must blacklist all the core/collection apis and it
is pretty much
>>>>>>>>> useless for anyone to access the admin UI (w/o the credentials
, of
>>>>>>>>> course)
>>>>>>>>>
>>>>>>>>> On Tue, Nov 10, 2015 at 7:08 AM, 马柏樟 <mabaizhang@126.com>
wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> After I configure Authentication with Basic Authentication
Plugin and
>>>>>>>> Authorization with Rule-Based Authorization Plugin, How can
I prevent the
>>>>>>>> strangers from visiting my solr by browser? For example,
if the stranger
>>>>>>>> visit the http://(my host):8983, the browser will pop up
a window and
>>>>>>>> says "the server http://(my host):8983 requires a username
and
>>>>>>>> password...."
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> -----------------------------------------------------
>>>>>>>>> Noble Paul
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Anshum Gupta
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -----------------------------------------------------
>>>>> Noble Paul
>>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>



-- 
-----------------------------------------------------
Noble Paul

Mime
View raw message