[
https://issues.apache.org/jira/browse/JCRVLT-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089346#comment-17089346
]
Angela Schreiber edited comment on JCRVLT-427 at 4/22/20, 8:15 AM:
-------------------------------------------------------------------
[~tripod], thanks for the insight... so the problem is that the hooks allow for
code execution, which is not covered by any privileges because the repository
is not aware of the subtleties of the layers above the repository that fail to
properly separate between application code and content. and since executing
code may lead to complete system takeover and thus was considered a privilege
escalation, which was prevented by making this feature available to those users
that anyway have full access.
[~henzlerg], as far as i know the list of paths that contain application code
is configurable as well and just assuming that it's just /libs and /apps might
not be true. also, you can test if a given session has the ability to write at
a given path but if i remember correctly it's not possible to know if the whole
subtree is writable. i am not sure from your suggestion, which of the two you
were envisioning.
to summarize:
unless we have some means in place to mitigate the potentially severe privilege
escalation that come with the hooks, i would leave some sort of extra check in
place that limits the execution of hooks to administrative principals even if
that means an additional configuration option. and a configuration option
naming principals feels more natural to me. the check for access to paths that
contain application content might work, but i wouldn't hard code it and we
might in fact miss other subtleties that could lead to vulnerabilities.
was (Author: anchela):
[~tripod], thanks for the insight... so the problem is that the hooks allow for
code execution, which is not covered by any privileges because the repository
is not aware of the subtleties of the layers above the repository that fail to
properly separate between application code and content. and since executing
code may lead to complete system takeover and thus was considered a privilege
escalation, which was prevented by making this feature available to those users
that anyway have full access.
[~henzlerg], as far as i know the list of paths that contain application code
is configurable as well and just assuming that it's just /libs and /apps might
not be true. also, you can test if a given session has the ability to write at
a given path but if i remember correctly it's not possible to know if the whole
subtree is writable. i am not sure from your suggestion, which of the two you
were envisioning.
> Allow installation of packages with hook for users without admin privileges
> ---------------------------------------------------------------------------
>
> Key: JCRVLT-427
> URL: https://issues.apache.org/jira/browse/JCRVLT-427
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: vlt
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Priority: Major
> Fix For: 3.4.6
>
>
> Currently due to the check in
> https://github.com/apache/jackrabbit-filevault/blob/e257001ec22ea06bcc987cbf79f0cc9b15c4e186/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/impl/ZipVaultPackage.java#L184
> packages containing a hook can only be installed by admins.
> Although I do understand the intent of that I think this is not flexible
> enough as currently that only gives the rights to users "admin", "system" or
> members of group "administrators". Instead there should be an OSGi
> configuration which allows to configure to grant the right to install
> packages with hooks to other groups as well!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
