See: Description
| Interface | Description |
|---|---|
| ProxyTrust | Deprecated |
| ProxyTrustIterator | Deprecated |
| ServerProxyTrust | Deprecated |
| TrustEquivalence |
Defines an interface for checking that an object (that is not yet known to
be trusted) is equivalent in trust, content, and function to a known
trusted object.
|
| UntrustedObjectSecurityContext |
A trust verifier context element that provides a security context
to use to restrict privileges when invoking methods on untrusted objects.
|
| Class | Description |
|---|---|
| BasicUntrustedObjectSecurityContext |
A basic trust verifier context element that provides a security
context to use to restrict privileges when invoking methods on untrusted
objects, based on a specified set of permissions.
|
| ProxyTrustExporter | Deprecated |
| ProxyTrustInvocationHandler | Deprecated |
| ProxyTrustVerifier | Deprecated |
| SingletonProxyTrustIterator | Deprecated |
Historically, proxy trust relied on the Java sandbox, however with the plethora of security problems relating to serialization. Now with the development of gadget attacks, where an attacker crafts a serialized stream to contain objects constructed in a way to create execution paths not intended by the original developers.
The constraint AtomicInputValidation,
and
DeSerializationPermission combined with
DownloadPermission, prevent downloading untrusted code,
limit classes that are allowed to perform deserialization and prevent the
objects from being assembled into a form required to perform gadget attacks,
by preventing object construction when invariants are not satisfied.
In addition to the above defenses, a new method net.jini.core.lookup.ServiceRegistrar#lookUp
has been provided to return bootstrap proxy's, that clients apply constraints to
and use to authenticate
a service, retrieve the service proxy and apply constraints, in this case
the proxy has been retrieved from a trusted and authenticated service.
New unicast discovery providers:
In light of these developments, the proxy trust mechanisms in this package are now obsolete.
Defines a trust verifier to support verification of proxies that use
dynamically downloaded code, implementation mechanisms to support the
verification of such proxies, and an exporter for remote objects that have
such proxies. The trust verifier is intended to be specified in a resource to
configure the operation of
Security.verifyObjectTrust.
The purpose of this package is to support verification of proxies that use dynamically downloaded code, in a way that limits the knowledge that must be pre-configured into the client. Specifically, the idea is to require the client to only know who the server must authenticate as (which is something the client presumably needs to know anyway), to avoid requiring the client to know anything else (such as where the code was downloaded from or who signed that code), and to avoid making assumptions about the authentication mechanism (such as requiring the server to have a public/private key pair that it has to use for signing the proxy code).
Rather than having the client directly determine if it trusts the proxy, the approach taken is to first determine that the client can trust the server (by requiring the server to authenticate itself), and then determine that the server trusts the proxy (by asking the server for a verifier and passing the proxy to that verifier). If the client trusts the server and the server trusts the proxy, then transitively the client is inferred to trust the proxy. However, there are questions to answer for both of these steps.
First, there is the question of how the client can reliably verify that the
server authenticates itself, when the client does not yet trust the
downloaded proxy. The
ProxyTrustVerifier
requires the proxy to support some bootstrap remote communication mechanism
that the client does trust. Specifically, the proxy must be able to provide a
bootstrap proxy, which must be an instance of both
ProxyTrust and
RemoteMethodControl. This
bootstrap proxy either must be trusted by the client, or it must be a
dynamic proxy which is trusted by the client after removing remote codebase
information from the dynamic proxy class. In the common case of a smart
proxy wrapped around a standard dynamic proxy (for example, a dynamic proxy
for a remote object exported to use Jini extensible remote invocation
(Jini ERI)), the dynamic proxy usually can serve as the bootstrap proxy if
its invocation handler does not depend on any downloaded code, on the
assumption that the client will have configured in a trust verifier for local
dynamic proxies and their invocation handlers (for example,
net.jini.jeri.BasicJeriTrustVerifier). However, there
is no requirement that normal communication with the server use the same
protocol used by the bootstrap proxy; the bootstrap proxy could be used
strictly for trust verification. The
ProxyTrustExporter
is provided for this purpose.
Second, there is the question of how to reliably obtain a verifier from the
server. (The proxy is not sent to the server because an untrusted proxy
could use a writeReplace serialization method to replace
itself on the wire with a trusted proxy; the proxy needs to be checked in
the client.) Authentication of the server should be required during the
remote call through the bootstrap proxy to obtain the verifier from the
server, as should object integrity, so that the remote call and the
verifier object received from it can be trusted. To accomplish this,
the client is responsible for specifying
ServerAuthentication.YES, an appropriate
ServerMinPrincipal instance,
and Integrity.YES
as requirements for the
ProxyTrust.getProxyVerifier method in a
MethodConstraints instance
included as an element of the context collection passed to
Security.verifyObjectTrust. Normally such constraints should be
obtained from a Configuration rather
than being explicitly constructed.
Copyright © 2016–2018 The Apache Software Foundation. All rights reserved.