Re: [Jython-dev] Notes on alpha2 SecureClassLoader/getProtectionDomain patch for BytecodeLoader (things to be aware of plus example)

[<bc...@wo...>]

[Samuele Pedroni]

>I start this with the conclusion (maybe this already clear to everybody =
>but it is better if it is stated somewhere):
>the patch in alpha2 to BytecodeLoader logic that enables to run jython =
>code - that uses
>exec, execfile ... - under java2 plugin, if one gives enough permissions =
>is really only intended to run=20
>fully trusted jython code that uses exec on python fragments fully =
>trusted too.

A good observation.

>On the other side if one gives no permissions, we fall back to the old =
>situation and everything is safe.

This is worth repeating. If no special permission is granted in the
policy file, jython 2.0 applets are as safe as any other applets.

>For anyone knowing java2 security architecture, already the fact that =
>createClassLoader permission
>should be granted to achieve this, should be a sufficient explanation to =
>the conclusion.
>This permission can safely be granted only to really trusted code ...
>
>Having jython runtime around only make it easier to eventually exploit =
>this.

I'll argue that because the jython runtime needs access to different
parts of the filesystem (registry & classes in python.home and
directories in the classpath), having the jython runtime around makes
the environment less safe.

Even when the bug exposed by your example is fixed, adding 

  grant codeBase "file:${python.home}/-" {
    permission java.security.AllPermission "","";
  };

to a policy file will never be safe. More discretion will always be
required. 

Regarding the bug, I think a solution is to store the protection domain
from the proxy in the system state during Py.initProxy, Py.jgetattr and
Py.jfindattr (and in the adapter calls, I think). BytecodeLoader2 will
then use this saved protection domain when loading code. 

[This may open for an attack where the evil applet gets executed on the
same thread as a trusted application and thus is able to create code
though the BytecodeLoader2 with the protection domain of the trusted
application. I'm unsure if it is possible to make the created code
execute without the evil applet being on the stack. More analysis is
needed]

I've uploaded a patch which attempt to save to protection domain in this
way. The patch isn't suitable for use because it assume java2 and does
not cover the adapters.


http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=103025&group_id=12867

>PS:
>To improve this (for the future: these are at least not little changes) =
>(just some ideas that possibly work):
>1) We should avoid to be obligated to grant createClassLoader permission =
>to
>  the code that uses exec: maybe this is possible using privileged =
>Blocks.
>  Then it becomes important that the code loaded by the exec
>  receives the same or less permissions than the "code that requested =
>the exec".

It should also cover the dynamically generated proxy classes which is
also loaded by BytecodeLoader2. Even with privileged blocks, the problem
as I see it, is to capture the permission of the originating applet and
use it for the created code. That have to be thread safe, secure and
efficient.

>2) We could provide something like the codebase based logic of the =
>SecureClassLoader
>  for jython code loading too.

You think that is possible while maintaining the same API to the "exec"
statement?


regards,
finn