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

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

On Wed, 27 Dec 2000 23:23:15 +0100, you wrote:

>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.

Ok. So by putting the "new BytecodeLoader" call in a privileged block we
ensure that only the jython domain needs createClassLoader permission.
The u-dom and t-dom does not.

Then we have to make damn sure that the created code is executed with
the permissions of the initial caller. Otherwise we have created a truck
sized security hole.

I now think the right place to put this restriction is at the PyCode
level, instead of the Class level. For a second, imagine that we have
yet another PyCode implementation which is doing a recusive
interpretation of the parse tree. Such a PyCode implementation should
also be covered by the access restriction of the code base which
compiled the PyCode instance.

In the patch, I now ensure that the execution of a PyTableCode is done
with the AccessControlContext of the code that created the PyTableCode.
The classloader is created in a privileged block, so the
createClassLoader permission no longer require for u-dom and t-dom. 

The assignment of co_context should really be done in a non-public
superclass of PyCode, so that PyCode subclasses can't assign a different
context. I'm sure other things are missing as well.

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

regards,
finn