On 18 Aug 2001 19:28:49 +1000, Peter Donald wrote:
> > You can't protect anything - maybe just get a false ( and dangerous
> > illusion of security.
>
> Theres multiple types of security. One is protection against directly doing
> evil stuff (what Java2 platform security protects against).
>
> The other one is basically security/integrity of application. Java does not
> protect against DOS (yet) but for all other cases it is possible to engineer.
That's what I'm talking about with dangerous "illusions" :-) Doesn't
matter how you "engineer", without a sandbox evil code can do anything
it wants.
I guess the problem is ( as usually ) the english language. We can
debate as much as we want about "security", as long as we each refer to
a different thing by this.
I'm talking about malicious code ( and in too many cases ordinary code
we write is equivalent ! ) and how to protect against that. Without a
sandbox - you can't, and if you believe otherwise - sorry.
Unfortunately most of the code is written ignoring completely this use
case - it assumes it'll have all permissions and if someone doesn't want
to grant you all permissions - he can use something else, we don't care.
> I will be impressed if you can retroactively implement this without breaking
> backwards compat or grinding logging to a crawl via multitude of SM checks.
> Actually even adding CCL check breaks backwards compatability.
Why is that ? Each webapp will "see" a log4j that behaves like it did
before. If you run in the sandbox - yes, a lot of apps will stop
working, and log4j will certainly behave differently - but that'll
happen with most applications.
Keeping backward compat without SM - it's easy, just use the existing
code, adding few interfaces will not brake it. Keeping backward compat
if a SM is used - well, the current behavior is that it'll just not
work, so I think we can change this :-)
> > In a sandbox, however, you can't call setContextClassLoader() unless you
> > have the right permission, so untrusted code can't do any harm. And
> > that's the goal - to keep untrusted application isolated and not give
> > them any additional "tools".
>
> Many applications require access to set ContextClassLoader.
That means those applications will not run well in a sandbox. So people
running them will have to decide between "trusting" them ( because
they're written by wizards, they can't be unsecure ) or not.
> If not everything is secured then there is little point in securing anything.
> It doesn't matter if there is 1 hole or 10. As long as there is more than 1
> you can not trust results produced via logging un not able to be trusted, nor
> is integrity of whole system.
One problem at a time :-), I'm not saying one change can fix everything.
Costin
( sorry, I can't continue this discussion, I have a lot todo and this doesn't
seem to go anywhere )
