[Jython-dev] Re: java2 security support: remarks

[Samuele P. <pe...@in...>]

Hi.

Just two things to be pointed out.

[Finn]
> 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.

No that's not the problem, as is it not a problem to give full permissions
to java runtime
used to run in the same application trusted and untrusted code.
The java2 security rules are there to deal with this: at any point the
intersection of the permissions
of all code on the stack counts (that means the min common subset). And in
case of thread
creation permissions are properly propagated. Up to privileged blocks.

> 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&grou
p_id=12867
>
This does not solve the bug, which is more a missing feature than a bug.
This is a possible solution to capture the applet permissions but I should
repeat this again:

The real point is that in order to allow an applet to use exec we should
grant to it createClassLoader permission.
Only if we can avoid this it make sense and it is worth to try to capture
the permissions of the applet code.

Because if there is a "security hole" around in applicative code, as in my
example the code that invokes a method of a class instance implementing an
interface obtained from "untrusted" code.
Instead of using jython runtime that creates code with the right
permissions,  the untrusted code can create its own class loader and load
things with permissions of its choice.
See:
http://www.java.sun.com/j2se/1.3/docs/guide/security/permissions.html#Runtim
ePermission

So for the moment it is simply dangerous to try to allow untrusted code to
use exec.

So to say AllPermission!=createClassLoader but to grant one of them to
untrusted code is quite the same: foolish.

regards, Samuele.

PS:
>>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?
This was a general idea, not related to exec and the "bug".