[
https://issues.apache.org/jira/browse/CASSANDRA-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14619968#comment-14619968
]
Robert Stupp commented on CASSANDRA-9402:
-----------------------------------------
bq. [restricted set of classes] necessary given that we're already restricting
the Permissions?
Unfortunately yes. One example is creating a new thread: Although there is a
permission to prevent a new thread being started, the actual check only works
from the root thread group (e.g. from thread {{main}}, see
{{java.lang.SecurityManager.checkAccess(ThreadGroup)}} and
{{checkAccess(Thread)}}, which say: {{if (g == rootGroup)
checkPermission(SecurityConstants.MODIFY_THREADGROUP_PERMISSION); else // just
return}}) - so you can create and start a new thread from any other thread
group - irrespectively how restrictive the actual permission set is (e.g. no
permissions). That's a quite annoying thing in Java and was a surprising
behavior (for me).
> Implement proper sandboxing for UDFs
> ------------------------------------
>
> Key: CASSANDRA-9402
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9402
> Project: Cassandra
> Issue Type: Task
> Reporter: T Jake Luciani
> Assignee: Robert Stupp
> Priority: Critical
> Labels: docs-impacting, security
> Fix For: 3.0 beta 1
>
> Attachments: 9402-warning.txt
>
>
> We want to avoid a security exploit for our users. We need to make sure we
> ship 2.2 UDFs with good defaults so someone exposing it to the internet
> accidentally doesn't open themselves up to having arbitrary code run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
