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 Tue, 26 May 2015 08:48:20 GMT


Robert Stupp commented on CASSANDRA-9402:

white/blacklisting works like this:
# The _whitelist_ is checked whether a class is allowed (either by its package name or its
class name). So unknown packages are rejected.
# When a matching entry in the _whitelist_ has been found, the _blacklist_ is checked whether
it’s a restricted package or class.

I think you mean that it’s possible to miss a new sub-package of for example {{java.util}}.
We could of course make the white/blacklist approach a bit more flexible by using regex instead
of {{String.startsWith}}. Honestly I think that even missing a new package in the {{java.}}
namespace is quite safe, if a security manager is in place. And using UDFs without a security-manager
is prevented.

We could of course mention all classes explicitly (basically only white-listing classes).
But we need to be very careful then to include every (static) inner class, too.

Unfortunately it’s not possible to setup a separate class loader just for UDFs. Otherwise
that separate class loader would have to load the relevant classes on its own - which leads
to duplicate classes in the VM and strange error messages like _AbstractType cannot be casted
AbstractType_. Sure, we could use a root class loader having {{apache-cassandra.jar}} and
{{cassandra-driver-core.jar}} as the base for both UDFs and ”the rest of C*”. But I’m
not sure whether this really solves the problem or introduces other strange behaviors.

> 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