cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Stupp (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-9402) Implement proper sandboxing for UDFs
Date Mon, 25 May 2015 20:47:19 GMT


Robert Stupp commented on CASSANDRA-9402:

Updated the branch with working Java UDF sandboxing and class white/blacklisting.
Java UDFs have no permissions. Additionally it's necessary to restrict the classes that a
UDF can access (e.g. access internal C* code, create a Cluster instance from Java driver,
etc). Both are very restrictive. It is not even possible to access a harmless class (for example
in {{org.apache.commons.lang}}). Only "safe" classes in {{java.lang/math/text/util}} and the
Java Driver as defined in {{[UDFunction|]}}
can be accessed.

NB: Script stuff not checked thoroughly yet. But scripted UDFs make me sad. The test {{UFTest.testJavascriptTupleTypeCollection}}
fails without the permissions {{getProtectionDomain}}, {{nashorn.JavaReflection}}, {{}},
{{accessClassInPackage.jdk.nashorn.internal.runtime.linker}} with {{AccessControlException}}
in Nashorn. I have no idea what it does there. Rhino requires no additional permissions (I
doubt Rhino really knows about permissions).
Since JSR223 providers are loaded via our "root" class loader, they'd have full permissions
- therefore the policy file "grants" no permissions to optional JSR223 providers by default.

bq. CREATE FUNCTION permission that allows you to create sandboxed UDF, but you can only create
unsandboxed if you have CREATE UNTRUSTED

Have opened CASSANDRA-9476 for that.

NOTE: It would be a nice feature for OpsCenter best-practice service to check whether enable_user_defined_functions=false
if no security manager is present.

> Implement proper sandboxing for UDFs
> ------------------------------------
>                 Key: CASSANDRA-9402
>                 URL:
>             Project: Cassandra
>          Issue Type: Task
>            Reporter: T Jake Luciani
>            Assignee: Robert Stupp
>            Priority: Critical
>              Labels: doc-impacting, security
>             Fix For: 2.2.0 rc1
> 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

View raw message