[
https://issues.apache.org/jira/browse/CASSANDRA-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14561895#comment-14561895
]
Robert Stupp edited comment on CASSANDRA-9402 at 5/27/15 10:44 PM:
-------------------------------------------------------------------
The pl/java SM is too lax. It only prevents {{System.exit}},
{{System.setProperty}} and {{setSecurityManager}} - and does not restrict
access to classes.
Further, it only checks for {{RuntimePermission}} and {{PropertyPermission}} -
that's not everything - a lot of permissions like {{ExecPermission}},
{{NetPermission}}, {{LinkPermission}}, {{SOcketPermission}},
{{SecurityPermission}} and {{ReflectPermission}} are missing. Sure, as of now,
we have a "very binary" permission model: either all permissions or no
permissions.
The methods {{SecurityManager.checkPackageAccess/checkPackageDefinition()}} are
not sufficient to prevent class access - we want people to be able to access
{{java.lang.Long}} but not {{java.lang.Runtime}}.
With static code blocks, it's easy to execute code with a simple
{{Class.forName()}} or by just assuming that you've managed to get that static
code block through the UDF compile process. To check access to specific
classes, you really have to implement a custom class loader. That's what the
UDF CL does - it does not know about any class itself - so it's able to check
all class names - even those in {{java.lang}}. To prevent duplicate classes
(e.g. {{UDFunction cannot be cast to UDFunction}} it delegates to the "main"
class loader.
EDIT: I would like to implement a custom SM - but mainly for performance
reasons since we do not need the flexible permission concept at the moment -
it's only "all perms" or "no perms". Well - except for Nashorn...
was (Author: snazy):
The pl/java SM is too lax. It only prevents {{System.exit}},
{{System.setProperty}} and {{setSecurityManager}} - and does not restrict
access to classes.
Further, it only checks for {{RuntimePermission}} and {{PropertyPermission}} -
that's not everything - a lot of permissions like {{ExecPermission}},
{{NetPermission}}, {{LinkPermission}}, {{SOcketPermission}},
{{SecurityPermission}} and {{ReflectPermission}} are missing. Sure, as of now,
we have a "very binary" permission model: either all permissions or no
permissions.
The methods {{SecurityManager.checkPackageAccess/checkPackageDefinition()}} are
not sufficient to prevent class access - we want people to be able to access
{{java.lang.Long}} but not {{java.lang.Runtime}}.
With static code blocks, it's easy to execute code with a simple
{{Class.forName()}} or by just assuming that you've managed to get that static
code block through the UDF compile process. To check access to specific
classes, you really have to implement a custom class loader. That's what the
UDF CL does - it does not know about any class itself - so it's able to check
all class names - even those in {{java.lang}}. To prevent duplicate classes
(e.g. {{UDFunction cannot be cast to UDFunction}} it delegates to the "main"
class loader.
> 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: doc-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)
