jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Security Concerns wrt Index Definitions
Date Wed, 13 Nov 2013 17:16:10 GMT
hi jukka

while i can see some benefit of having index definitions with
the content being index i am not happy with having the
built in index definitions underneath the root node. is is for
sure asking for troubles as the /jcr:system is generally protected
in some way while the root node is very often defined to be
readable to everyone (imagine our regular publish setup).

regarding restricting permissions:
we should have that in the default setup instead of relying on
some specific user of OAK to remember to setup it. experience
shows that this simply doesn't work; we have to make the repository
secure by default.

regarding david's model #1:
the longer i work on the repository and on security, the more i come
to believe that rule #1 does not apply for
1. special content that stores information internal to the repository
2. content that is particularly sensitive
3. content that has been generated by untrusted users

david's model has been created at a time when we just had a
simple content mgt system without caring too much about security,
with a simple read-only publish mode and any social collaboration
features that turn the publish into a writable for everyone repository.
IMO we should rewrite them to match the requirements and changes in
our products... not only but also wrt security.

kind regards
angela

On 11/13/13 5:58 PM, "Jukka Zitting" <jukka.zitting@gmail.com> wrote:

>Hi,
>
>On Wed, Nov 13, 2013 at 5:21 AM, Angela Schreiber <anchela@adobe.com>
>wrote:
>> currently the index definitions are located directly underneath
>> the root node and don't have any specific permission setup
>> associated with them.
>
>I guess we should restrict at least write permission to administrators.
>
>> IMO this is a very troublesome setup which may lead to serious
>> security issues.
>
>I'm not too worried about this, since the index definitions themselves
>seldom contain any confidential information, and if they do, it's
>always possible to read-protect them. The actual indexed content is
>always hidden.
>
>> - if the location of the index definitions is well chosen.
>>   have those that originally setup that structure thought about
>>   securit concerns? what was the result?
>>   for example: why are the index definitions not located underneath
>>   jcr:system? this was IMO more appropriate.
>
>The idea behind the oak:index child node for index definitions was
>that you could place them close to the content being indexed.
>
>For example, if you only want to index content within /foo/bar, you
>could add the relevant index definitions in /foo/bar/oak:index. A nice
>side-effect of this approach is that someone with write permission
>within /foo/bar would then also be able to define new indexes for that
>subtree.
>
>Putting the index definitions inside /jcr:system or some other such
>location would make the
>
>> - the node type of the oak:index parent node:
>>   it's currently nt:unstructured which will allow anyone with read
>>   access to create whatever additional content there. this doesn't
>>   make sense IMO.
>>   and: is the index related code prepared to deal with any kind of
>>   garbage content in the oak:index tree?
>
>We could add a more specific node type for this, but I don't see much
>benefit in doing so. See rule #1 in David's model.
>
>The index code in any case only looks at properly formatted index
>definitions, so having extra content there does no harm. It might even
>be useful, for example it would be possible to put a README.txt node
>there to document the index setup.
>
>> - the node type definition of the oak:queryIndexDefinition:
>>   it currently extends from nt:unstructured which also allows to
>>   place any kind of child nodes. is this really intended? and is
>>   the index code prepared to deal with *any* kind of content in
>>   the subtree of the definition?
>
>See my point above. The indexing code only looks at the relevant data
>in the index definition, and ignores whatever else the user might want
>to place there.
>
>>   and shouldn't the index definition be considered 'protected' from
>>   a JCR point of view?
>
>No, as otherwise we'd need to introduce a custom API for managing
>indexes. With the current approach you can use any JCR content editor
>or JCR client code to manage index definitions in Oak.
>
>> - the access rights defined on the index definition irrespective of
>>   their location:
>>   - who needs access to the index definitions?
>>   - must they be readable to everyone?
>>   - should read access be restricted?
>>   - who should/must be able to add/change/remove the index definitions?
>
>These are all questions that can be addressed with normal ACLs on the
>index definition nodes.
>
>It might make sense to adjust the permissions on the default indexes
>created by the initial repository content (for example make them
>writable by administrators only as mentioned above), but in general
>I'd leave it up to the administrator of a particular deployment to
>decide if and how index definitions need to be protected.
>
>BR,
>
>Jukka Zitting


Mime
View raw message