commit-classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch #3174] Default implementation of VMAccessController.getStack


From: Michael Koch
Subject: Re: [patch #3174] Default implementation of VMAccessController.getStack
Date: Wed, 30 Jun 2004 20:55:56 +0200
User-agent: KMail/1.6.2

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Mittwoch, 30. Juni 2004 19:20 schrieb Casey Marshall:
> >>>>> "Michael" == Michael Koch <address@hidden> writes:
>
> Michael> Am Mittwoch, 30. Juni 2004 12:19 schrieb Jeroen Frijters:
> >> > Summary: Default implementation of VMAccessController.getStack
> >> >
> >> > Original Submission: The attached patch provides a default >
> >>
> >> implementation of java.security.VMAccessController.getStack, >
> >> by calling Throwable.getStackTrace().
> >>
> >> > Note that this implementation will likely not work in >
> >> > general:
> >>
> >> this implementation needs to get classes by name, > and may not
> >> be able to. Also, since unresolvable stack frames > will be
> >> silently dropped, this can lead to code running with >
> >> privileges it should not have.
> >>
> >> This seems like a really bad idea to me. Why have a default
> >> implementation, if it's useless? Especially in the area of
> >> security, I wouldn't do this.
>
> Michael> At least a default implementation that is unpredicateable.
> In Michael> my opinion the default implementation should not allow
> "code Michael> running with privileges it should not have". This is
> okay as Michael> every JVM has to implement VMAccessController for
> themself Michael> anyway to get correct stack traces.
>
> I assumed that a reference implementation should illustrate what
> the method needs to do, not simply be empty. Besides, this method
> will succeed if the host VM can guarantee that Class.forName will
> reliably return already-loaded classes by name (I'm not sure how
> feasible this is. From my understanding of class loaders it should
> be possible to provide this guarantee, even if a pluggable loader
> is used).
>
> An alternative would be to return an empty (and therefore
> unprivileged) stack if one of the classes cannot be resolved.

If that is garanteed to be secure by default I'm find with it. I just 
want JVM developers to think about this and not just using the 
insecure default.


Michael
- -- 
Homepage: http://www.worldforge.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA4wy8WSOgCCdjSDsRAoCqAJ4iD/4MQxMVr8bt7xpJYo+YrbDKxACbBkW3
+OjaeBZe+G6PxjaK3abLyXA=
=rlX8
-----END PGP SIGNATURE-----




reply via email to

[Prev in Thread] Current Thread [Next in Thread]