Develop Reference

Is there a Java class I can override to inspect and modify all network requests as they go out?

I would like to implement custom retry logic for all failed HTTP requests in my Java applications without having to modify all the networking code. Is there a class or interface I can implement that would force all outgoing requests through a method that I could inspect the request and response?
A related example from another project is a custom TrustManager implementation I used to handle revocation status for our internal CA PKI. I'm wondering if there is anything related that could be used to centrally manage HTTP behavior.

You can't do that on the source code level.
You see, the corresponding "data" doesn't "travel" through a specific unique instance of any class. Depending on your protocol, all kinds of classes, such as java.net.Socket will be instantiated over time. You can of course look into what code you wrote is doing, but you have no chance changing the behavior of such existing standard classes on the source code side.
The only things that might help:
looking into debuggers, for example by identifying methods that matter to you, to then set breakpoints there
using instrumentation. Meaning: you hook into JVM startup, and add/manipulate classes at runtime

Can one break a secury manager with sun.misc.unsafe?

Following a conversation on another question, an interesting issue is being raised.
Classes loaded with a security manager are protected with the corresponding security. This security could disable reflection (for example).
The question is: is it possible to break a security manager with sun.misc.unsafe? If yes, how?
EDIT
Changed SecuredClassLoader to Security Manager in question.

No. The sun.misc.Unsafe class requires an access check just like any other privileged action. You can block it with a custom class loader or security manager. Here's a simple example with an empty security manager that shows it'll throw an AccessControlException:
System.setSecurityManager(new SecurityManager());
Unsafe unsafe = Unsafe.getUnsafe();

What is "secure class loader"? SecureClassLoader? It is not secure, despite its name. All it does is limits the class loading source to a specific code location.
Therefore you don't even need any unsafe operations to "break" that. Just, for instance, make sure a replacement hacked class is in the classpath before SecureClassLoader even got the control.
Someone in that thread told you already -- you cannot have a secured spot in unsecured environment. If your code is deployed to a user machine, user is God there, and no JVM security can help you simply because JVM is a tiny layer on top of much more powerful native things.

Outside classes accessing package-private methods

Suppose I have a class in my package org.jake and it has a method with default access (no modifier). Then the method is visible inside the package only.
However, when someone receives the jar of my framework, what is to stop them from writing a new class, declaring its package as org.jake, and using my supposedly invisible method?
In other words, is there anything I can do to prevent this?

You could seal the package in your jar file. It's not bullet-proof though.
The main thing is not to rely on access modifiers etc from a security point of view to start with, really. If someone is running the code with unrestricted permissions, they're going to have access to all kinds of things. Access modifiers really just help to stop people from accidentally shooting themselves in the foot.
If someone is willing to put classes in your package to circumvent your encapsulation, they're clearly ignoring your best intentions - I say let 'em get on with it, but don't provide support for that scenario.

There is nothing you can do to prevent this. Even private members can be accessed via reflection. You should consider the access modifiers in java to be merely suggestive.

First off, this is the “DRM” scenario: ultimately, someone determined enough can defeat any protections you put in place by supplying a funky modified runtime or other such things. The reverse scenario – where the runtime is trusted but some of the packages are not – is tackled properly by Java through the use of suitable ClassLoader restrictions, but that can only work where there's something that can enforce the restrictions in a trusted fashion; that's why your scenario is basically doomed.
However, if we assume that the runtime itself is trustable then you could try, in your super-secret method, getting the stack trace of the currently executing stack (see stackoverflow.com/questions/1069066/… for how) and testing to see whether the caller of the current method is one that you trust to get access. A security manager would be even more suitable, but you can't trust the environment to have one of those installed that you like (it's much more clearly under the control of the attacker). Note that I have not tried the options in this paragraph!
The other alternative is to put your secrets on a service you control and only offer remote access to them. Or stop worrying about using technical mechanisms to deal with a problem that is fundamentally about business and legal issues (e.g., why are you dealing with people you can't trust?)

I'd say simply do not allow them to run code where it can call yours, i.e. in the same JVM. You could instead consider offering only a (web)service they can call externally. I'm not very up to date on the best ways to implement this though.

When should AccessController.doPrivileged() be used?

If I understand AccessController.doPrivileged correctly, it is saying that untrusted code should be able to invoke methods requiring permissions (such as System.getProperty()) through an intermediate method that does have permissions.
That brings up the question: when should AccessController.doPrivileged() be used? When should untrusted code be allowed to invoke privileged code through intermediate methods? When should it fail?
Following your reasoning, please explain why ClassLoader creation should always be allowed: http://findbugs.sourceforge.net/bugDescriptions.html#DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED

Agree with Suraj's answer, but thought I'd add a specific example where I've required the use of a privileged block.
Imagine you've built an application that provides a number of services to pluggable modules. So your app and its services are trusted code. The pluggable modules, however, are not necessarily trusted and are loaded in their own class loaders (and have their own protection domains).
When a pluggable module invokes a service, you are implementing custom security checks ("does pluggable module X have permission to use this service"). But the service itself might require some core Java permission (read a system property, write to a file, etc). The code that requires these permissions is wrapped in a doPrivileged() so that the insufficient permissions from the untrusted pluggable modules are effectively ignored - only the privileges of your trusted services module apply.

..through an intermediate method that does have permissions . No, the final effective permissions is the intersection of all permissions in the domain stack. So suppose an operation requires a permission B to execute, and say some intermediate LIB has two permissions B and A. Now when some untrusted code with only permission A calls through LIB, the effective permission set is (A intersect (A+B)) = A. Hence the untrusted code cannot exploit intermediate LIB to gain extra permissions.
When should doPriveleged be used?-> There are lot of operations in Java that require the caller domain to have certain permissions for successful execution of those operations. System.getProperty is one of those operations. All file related operations also need special permissions. When you use AccessController.doPrivileged to invoke those operations, the operation is executed with all the rights(permissions) of your protection domain. Hence if your code has enough rights only then it could execute those operations.

Essentially, AccessController.doPriviledged() is the equivalent of a set-user-id file. It is saying "I hereby request that this method be done with my privileges, even if I was invoked by a method that does not have them."

Check out these links and scroll down to using the doPrivileged API.
Java 6:
http://docs.oracle.com/javase/6/docs/technotes/guides/security/doprivileged.html
Java 7:
http://docs.oracle.com/javase/7/docs/technotes/guides/security/doprivileged.html
When the AccessController checkPermission method is invoked by the most recent caller, the basic algorithm for deciding whether to allow or deny the requested access is as follows:
If the code for any caller in the call chain does not have the requested permission, AccessControlException is thrown, unless the following is true - a caller whose code is granted the said permission has been marked as "privileged" (see below) and all parties subsequently called by this caller (directly or indirectly) all have the said permission

Disable Java reflection for the current thread

I need to call some semi-trustworthy Java code and want to disable the ability to use reflection for the duration of that code's execution.
try{
// disable reflection somehow
someObject.method();
}
finally{
// enable reflection again
}
Can this be done with a SecurityManager, and if so, how?
Clarification/Context: This is a follow-up to another question about restricting the packages that can be called from JavaScript/Rhino. The accepted answer references a blog entry on how to do that, and it requires two steps, the first one using a Rhino API (ClassShutter), the second one turning off reflection and Class.forName(). I was thinking I can do that second step more cleanly using a SecurityManager (learning about SecurityManager, which as has been pointed out, is a complex beast, along the way).
To sum up, I want (from code, not setting file) to turn off Class.forName() and any access to the whole reflection package.

It depends on what you are trying to restrict.
In general, publicly accessible API is not restricted. However, as long as you don't grant the untrustworthy code the ReflectPermission("suppressAccessChecks") permission, it won't be able to get access to non-public API in another package.
If you have a list of packages to which you want to restrict all access, there are two steps. First, in the Security properties, include the restricted package in the package.access list. Then give your trusted code RuntimePermission("accessClassInPackage." + pkg).
A common way to distinguish your untrusted code is to load it from a different location, and refer to the different codebases in your policy file when granting permissions.
The Java security architecture is very powerful, but I know it is also complicated; if you would like a more concrete example, please describe exactly what calls you want to restrict and I'll try to be more explicit.
To do what you want without modifying the java.policy file and/or the java.security file would be very difficult, maybe impossible. The java.security.Policy represents the information in java.policy, but it doesn't offer write access. You could create your own Policy implementation and install it at runtime as long as any existing SecurityManager permits it.
On the other hand, you can specify a custom java.policy file as a command-line option. If you are providing a complete application with some sort of launcher, that might be easily accomplished. It also provides some transparency to your users. A sophisticated user can review the permissions you'd like to have granted to the application.

Well, you can override SecurityManager.checkMemberAccess and give a stricter definition. However, it doesn't really work like that. What happens for instance if the code defines a finaliser?
On the clarification: Other APIs use reflection and other APIs. For instance, java.beans, LiveConnect and Rhino. An adversary could from within a script, say, create a new Rhino context without the shutter and thereby bootstrap into the full JRE. With an open system, a blacklist can never be finished.
In summary: to use the Java security model you need to work with it, not against it.

I wrote a replacement of ClassShutter that allows fine grained access control, per instance, per method, per field:
http://riven8192.blogspot.com/2010/07/java-rhino-fine-grained-classshutter.html