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

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

Hi.

[Finn]
> [Samuele]
....
> >In Sun doc it is stated that the use of doPrivileged should be very
limited
> >and also the amount of code executed inside
> >such a privileged context should be limited too. The patch does something
> >very different using doPrivileged for every "jython function call" and
> >having the privileged region encompass the whole "call".
>
> I think (I'm not sure) that the advice SUN is giving only covers the
> doPrivileged method without an explicit AccessControlContext. The
> example SUM is supplying is that of a worker thread, and I assume that
> the complete work that the worker thread is about to perform should be
> executed with a doPrivileged call *with* explicit AccessControlContext.
(Just for general interest)
I think they intend that at some very specific places the thread code
uses doPriviled passing the needed (somewhere else captured) context.

> >a) A bad news about the patch is the perfomance cost of it:
> >On my machine with the patch in place the pystones number (using 50000
> >iters ) goes down from ~4950 to ~2900.
> >I do know very little about how to read pystone results: but this seems
to
> >me a "big" performance cost that is paid
> >globally.
> >[In any case I continue to list the "problems" of the patch, maybe there
is
> >a solution that I do not see, and I think some
> >remarks are of more general interest]
>
> I'm sure some optimizing is possible. OTOH, even a high performance hit
> is acceptable as long as it is only incurred in very controlled
> situations:
> - Only when running under a seurity manager, and
> - Only if specificly enabled with a property / jythonc option or
> - Only when using dynamicly compiled code through exec.
In general I agree with this.
But if we cannot limit this penalty only to the case of the real use
of dynamicly loaded code, I think we need a different approach.
I imagine that offering the feature this way - to fully trusted applications
running under  the plug-in - but at the price of this global performance
loss make few sense.

> >e) Given that our support should work in a general setup:
> > - The patch solves the problem of reducing the permissions back to the
ones
> >of the context of the code that used exec.
> >   So if the created code is called from a context with more permissions
it
> >cannot exploit any of these. That was the issue
> >   showed by my example.
> >-  On the other hand if the exec-created code is called from a context
with
> >less permissions, given doPrivileged
> >   definition, it will anyway run with the permissions of its creation
> >context.
>
> Yes, unfortunate; but I don't think it is a security problem. The high
> permission code that made the exec could just run the code itself.
> Still, it is bad design to run any code with too high permission.
I do not understand your comment.
For me that's a security problem because the users then *must* understand
the issue and deal with it.
I repeat
 > >   In general java2 security design avoids this kind of situation (but
gives
> >through doPrivileged a way to obtain this)
> >   because then the user during coding should explicitly think about the
> >possible security holes that this behaviour opens.
The situation that I imagine is the use of exec to create/define a function.
Then this function will always be executed with the permissions
of the creation (exec) context.
From my viewpoint that's bad.
In general - with java2 security - code in a protection domain that do not
have
the permission to do something cannot achieve that, even calling code
in another protection domain. The patch as it is breaks that in a too
broad way.

...
> >The constructor logic will do the following:
> >- if there is no security manager in place just define the class.
> >- if there is a security manager in place: define the class inside a
> >protection domain,
> > the permissions to grant will be computed this way:
> >
> > Only the permissions from the global set PermsCands for which
> >acc.checkPermission do not throw an exception
> > will be granted.
>
> Would this create a new ProtectionDomain for each dynamicly loaded
> class? What CodeSource would be used for the ProtectionDomain?
Yes and that's ugly too.I imagine that we will need to produce some
kind of fake URL, I have not studied that yet.

The problem is clear: the security api as it is is not well suited
to support the dynamic creation/loading of code/classes at runtime.
So we are not using it, we are hacking with it.

> >Clearly all this checks have a performance cost, especially when the
> >negative result exc is thrown.
> >The code can test wheter already AllPermission is ok to gain some speed
in
> >this case.
> >The assumption is that the set will not be that big and in any case the
cost
> >is local to the dynamic
> >creation of code. And zero if there is no security manager in place.
>
> That is good enough. Don't worry about the performance if the hit is
> only incurred when actually used.
>
> >So the permissions granted are all actually in place for the code that
> >issued the creation request.
>
> Yes, I think this is a safe way to store and later recreate the
> permissions of the code that wants to create code dynamicly. And yes,
> it's ugly <wink>.
Yes, really ugly <wink>, but if we do not find a solution for the problems
above
we will have to try this too.
Further, given that adapters are created lazily I imagine they will need
some special treatment. I think just putting them in jython runtime prot-dom
should be ok.

> ---------------------------------
>
> Only slightly releated: what would happen if an evil applet could
> somehow get hold of a PyProxy or PyObject (perhaps through
> Applet.getAppletContext().getApplet("foo") ) and then started making
> modification to the applet with __setattr__ and __setitem__. The evil
> applet cannot introduce new code into the "foo" applet, but if foo it
> trusted and is a large application, the evil applet may find enough
> usefull methods and functions to build an attack. I haven't tried this
> yet, it's just a scary thought.
A "secure" applet context impl should allow mutual access only between
applets that comes
from  the same code-source.
It should be checked if that's the case of sun plug-in. Not tried yet.
But reading the doc it seems to be the case.
The fact that for implementation reasons and python philosophy all member of
a python class are "public"
from java side is somehow a general "security" issue.

regards, Samuele Pedroni.