On Sat, 18 Aug 2001 18:32, Costin Manolache wrote:
> > Thats no more secure or safe than current version. You could simply do
> > something like
> >
> > Thread.currentThread.
> > setContextClassLoader( mySecureObject.getClass().getClassLoader() );
>
> If you are not using a security manager, the untrusted code can do much
> worse - it can load native library ( for example ), access anything in
> memory ( via native or similar methods ). Or it can read/write any files
> it wants, so accessing the logger of another application is the least
> problem.
>
> 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 is
protecting against causing indirect doing evil stuff which in case of Log4j
would require setting guards on almost every mutator and against unsafe
methods (like that that passes caller class to log event, that to get/set
appenders/ layouts etc... ).
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.
Basically components should only have the privs to do the exact minimum
required to complete their job. Give them more and someone will stuff
something up in likelihood.
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.
> 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.
> > Category c = Category.getInstance( "auth" );
> > c.setAppenders( myEvilSubversiveAppenders );
> >
> > This will work when security is turned off or on any complex
> > webapps/applications.
>
> Again, with security off - it doesn't matter anyway. With security on,
> setting appenders is very tricky - you don't want it to set a
> FileAppender ("/etc/passwd" ). And you want some appenders to be
> priviledged so they can write to syslog or some log dir.
Same with calling appenders, setting additivity, getting appenders,
manipulating appenders, layouts ...
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.
> > In Avalon we came across much of these same problems a while back. The
> > only real solution was to change the paradigm. Instead of static access
> > you get access via an interface. SOmething like
>
> I know, but that has it's limitations as well - it works great if you
> have dumb components and a smart framework.
You mean if you program the "right way" you can be secure ? ;)
> So far all logging I've seen are based on the current paradigm, of user
> code controlling a hierarchy of loggers, and that seems to be the
> problem we have to resolve.
Then I would base it on caller class - that is soooo much harder to subvert
(I don't know of a way off hand).
--
Cheers,
Pete
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
